Tech lead without a sense of productivity?
How to increase your subjective sense of productivity when you lead a tech team, but do less of the coding work yourself?
You probably have seen this problem many times: Once someone gets promoted to a more managing position as a software developer, the share of hours coded themselves may drop drastically. Yet, many senior developers are good at tech, because they did exactly that: spending countless hours with computer programming.
Under such circumstances, many developers have to face some tough questions:
- Can I still competently speak about the code base?
- Do I practice enough?
- Am I up to date with the newest tech trends?
By seeing yourself as a “passive developer”, you can shift the focus on producing through delegation and team feedback. As a passive builder you are still building. Albeit, you are not executing all the coding tasks yourself. The mindset of passive software development may help you to feel less disconnected from the development process.
How much should you code when leading a software team?
The question of the subjective sense of productivity is closely tied to another debate:
How much should you code when leading a software team respectively fulfilling leadership tasks in a project or bigger task?
Lizzie argues that you should accept to reduce net coding hours as a team lead. She believes that you can not perform in both active development, and leading the team. You simply have not enough time. The article differentiates between team lead and tech lead. If you do not want to give up coding, she suggest that you chose a career path as tech lead, instead of team lead. The tech lead role would imply more active development.
While the distinction between team lead and tech lead is of interest, in practice roles may be more fluent. In many companies it is not clearly defined, but rather even up to yourself, how to fulfil the role of a team or tech lead.
The challenge is to find the right balance between hands on coding and managing a team. Both tasks require significant time and are often in conflict with each other.
Other answers go in the same direction. The general experience is: the more people you have to manage, the less time you have to code yourself.
This can cause stress: More experienced developers climb up the career ladder into management, although they just want to code. If you code less, you probably have seen yourself missing the joy of coding. However, coding regularly is like training muscles. You regularly need to practice to stay in shape. Finally, there is a fear of missing out new tech trends and hands on experience, if you code less yourself.
Embrace the “passive developer” inside yourself
Whatever your personal share of active development may be – if you want to move into more management positions, you usually always have to increasingly get used to the fact that you code less yourself.
However, it can be avoided to get overly nostalgic about the good old hacker times when you spent hours and hours of actively coding.
As a remedy, one can differentiate between two activities:
Active Software Development means direct programming and creation of software yourself. You tend to own the engineering challenge. You implement the solution.
Whereas Passive Software Development means creating software through delegation. You still have to develop an engineering solution. But you are not doing the greater share of coding yourself. Instead, you rely on “passive” engineering tasks, such as:
- Creating proof-of-concepts
- Doing a lot of code reviews
- Helping other developers in pair programming
- Defining design patterns and engineering standards
- Debating architectural solutions
- Moderating in tech debates
- Helping other developers growing their careers
- Removing blockers from the team
Serving the team – this is what it all revolves around. Your productivity is measured no longer in coding output, but in the dev team’s performance.
Is this enough to stay up to date?
Yes, if you see the teams output as your own learning. From code reviews you can learn new patterns. When setting the standards you naturally have to research on better engineering practices.
All this makes you a better software developer, even though you would not write a lot of code yourself.
