The First Step: Interaction
To influence the development team, the Technical Lead needs to find and understand the current key areas in need of skill development. This happens by interaction with developers.
First step in the strategy is to gain an understanding of a developer's skill set.
Together with our Chief Technological Group at the end of last year, we discussed how we could better help our developers. One of the ideas that came up was to create a technology skill radar to use as a self-evaluation tool and a way to visualize each person's skill set. In our case, we listed the company's core technologies and asked the developers to rate their individual skills in each on a scale from 0 to 6. Each point on the scale had an example description for the developer to help them understand their own skill level. The results were gathered with Google Forms and with an add-on we created we then rendered spider charts to display the current skill set of each developer, according to their own assessment. By looking at the charts one can easily get a clear picture of the individual strengths of each developer and identify areas and skills to be improved on.
These charts are just one of many tools used to interact and collect information. In general, interaction needs to be an ongoing process. The Technical Lead needs to be in continuous interaction with his or her team members to understand their situation.
The Second Step: Analyze the Interaction
In the analysis phase, you need to define the situation of each of your developers and the influence each requires. A few things are important.
Firstly, individual situations in terms of developer skills are never binaries. There simply aren't just 'skilled people' and 'unskilled people'. It is for this reason that we use the scale of 0 to 6 for the self-evaluation exercise. This is one of the most important principles when analyzing the situation and even more important when planning the actions required to answer the needs of each particular situation.
Secondly, you need to be critical about the skill set and how the developers see themselves and their skill level. Some might be over optimistic and others too self-critical. So the results on the chart should be balanced against the personality of the developer and your experience and observations of their previous work.
Thirdly, developing a skill level on a technical dimension is not the only key to success. Motivation is also an important factor and cannot be clearly read from the charts. So you'll need to have conversations with your developers. Ask the following questions. What motivates you? What are your passions in development? Why are or aren't you motivated to learn certain skills? You can also use tools such as Moving Motivators to identify what motivates your team and its members.
Finally, understanding the role of the developer is important. Not everyone is required to master every skill. Identify what skills are essential in order for each developer to successfully fulfill their role and complete their tasks.
After the analysis, it is time for action. The guiding principle for a Technical Lead is that your actions should always influence the developers you work with. But how to do so? The answer is simple, by adjusting your actions based on the situation. My plan is to use the following 7 levels of influence in my work which I believe will apply to most common situations. I use code reviews as an example, but the same 7 levels could be applied to other tasks as well.
So let's say you do a code review. With a first level situation, it might be for a junior developer who is new to the company and has low-level experience with the technologies your company is using. The kind of feedback you give will need to be directive and should explain (tell) the best practices. You could give a sample code of a better way to solve the issue and explain exactly why it's better.
At the second level, the developer might be more skillful but lacking motivation or understanding. Maybe low-quality spaghetti code is delivered or a hot fix made without giving enough attention to the depth of the problem. Now you need to sell your idea to the developer and encourage (motivate) them to go the extra mile. In other cases, you might need to explain more abstract code patterns and give a reason for using them and what the advantage could be in the long run.
When you have a third level situation, your role starts to fade but still, you need to participate. Your consultation on the code review could be providing a skeleton for a refactoring but not a full working code as you would have done at the first level. Show them ways to increase their skills and challenge them to get to the next level.
Then with a fourth level situation, your role continues to fade but you should now help the team members to help each other. If you see a need for improvement in the code review, you could advise the developer to get guidance from their peers or a senior developer and simply ask them to report back to you with the solution they came up with. And then like a team coach you prompt the team to agree and reach a consensus on what is the best solution. For this example you should try to avoid coding on this level.
When you have a fifth level situation, your presence and role as an influencer transforms into something else. While doing a code review and reading the code you may encounter multiple things you like. Although there might still be room for growth you only give advice on where to look for solutions or improvements and what might be a right direction. Provide keywords but no answers. It's only if the developer cannot solve the issue or see how to refactor and improve their code, that you step in and support them.
Now you might start wondering why there is even a need for the sixth level. Many Technical Leads might say their job is done when there is no need for improvement in the code. But to create an atmosphere where continuous growth keeps happening, we need to be consistently and actively aware of the different situations in our team and identify the level of influence needed. At this level, you can set up code reviews as an inquiry to see how things are going. When you see an excellent piece of code, don't just stay silent. Give kudos. Affirm that they are doing a good job.
After this, there is still one more level. This is the situation where you realize that the apprentice has become a Jedi. It is time for you to relax and see that you can delegate the code reviews to other developers. In the best possible scenario you will be learning from the very developers you were coaching earlier.
My inspiration for this strategy
The strategy I have created here is something that has been growing in my mind over the last month. Most of my ideas come from the Situational Leadership model created by Dr. Paul Hersey. The idea to split the situations into 7 different levels is inspired by the Management 3.0 practice of 7 levels of delegation.
So excited to see how it will work out with my team!
This article was initially posted by Lauri on his LinkedIn.
Our teams are ready for your projects. Find out how we can support you:
Talk to us today!
