Recently I was re-reading one of my favorite engineering articles The Trident Model of Career Development by Patrick Kua. The sentence that caught my eye this time was a note about the role of a Tech Lead:
They should have good but not necessarily the best [tech] skills in the team they are leading.
‘How does this apply to an Engineering Manager?’ came to my mind instantly. And my initial response was that it's the same. Yet, after some more thought and thinking about the Engineering Managers I've met, I was not sure. Then I made my mind: no, it's not the same. Now, I think that it is actually dangerous when an Engineering Manager has the best tech skills in the team.
Let me show you why.
1. They cannot utilize it
Becoming a manager is a big lateral step for an engineer. While they can draw from their tech experience, being a manager requires a very different set of skills, and–what makes it even more challenging–many of these will be completely new for them. There are so many activities that are not coding, reviewing, or architecting. The new manager simply doesn't have the time to use their tech skills as they did before. That means that the team and the company now lost a significant portion of tech contributions.
The team is not the only one who is unhappy about it; in fact, and I'll bet on this, the manager is even more unhappy about it themself. In my previous experience, I saw many brilliant senior engineers who wanted to grow and become an Engineering Manager seemed so natural. Often they were told that the new responsibility will only mandate 10 or 20 % of their time. What a lie that was, as they soon found out.
There were three outcomes I've witnessed: not many of the managers accommodated and let the tech go (at least partially); some felt guilty and coded in overtime; and quite a few decided that management was not for them and went back to senior engineers. (A side note for the last case: since becoming an Engineering Manager is often seen as a promotion, most of them rather left the company and applied to a senior engineering position elsewhere.)
2. They will be a bottleneck
Connected closely to the previous point, the team might be waiting for code contributions, PR reviews, or comments on RFCs longer.
The number one comment I hear from new managers is about the number of meetings they are expected to attend. This not only deducts from their hours in a day directly but because of the workday fragmentation and constant context switching it is more difficult to find a longer time for uninterrupted work in between the meetings.
This will become a big issue when the task is extremely time-sensitive, like when there is an incident and the best person available should lead the detailed debugging. While avoiding huge losses for the company, the manager will build up a personal debt of materials they need to read, meeting recordings they need to watch, and postponed decisions they need to make.
3. They will cause sub-optimal decisions
Speaking of decisions, there is a significant risk that the team will make some bad tech decisions. Or at least not as good decisions.
Why? In simple words, it's difficult to disagree with the person who evaluates your performance and decides on your salary, bonuses, and promotions. This whole desire to please one's superior might very well be subconscious. Yet, it creates a disbalance that might result in worse tech decisions made.
There are some great stories about preconceptions the managers had to fight in Kim Scott's Radical Candor.
I'm not saying that it is not possible to avoid it, but it requires that the manager is aware and puts some compensation processes in place. They also have to work on increasing the level of psychological safety among the team members.
What should I do when this is my case?
Are you a manager that has the best tech skills in the team? Do you wonder what to do next?
First, this is a fairly common scenario and I know many teams like that that work just fine. The key is to acknowledge that there are some potential risks and be vigilant about their signs.
The best, however, is to stop being the tech go-to expert in the team. Of course, that doesn't mean you should become worse or leave your manager post. It means actively working on growing your report's skills. It means extensive knowledge sharing. It means grooming your successor (or successors).
Lastly, you should become comfortable in your position. Accepting and embracing that there will be people better than you in technology, in skills you've been so proud to possess. Knowing that the value you bring has shifted from individual strengths to multiplying strengths of others.
Are you an engineering manager that balances tech and people skills? Who do you think should be best at tech in a team? Tweet a reply
Related articles
- People, Product, and Technology: A Beginner’s Guide to Engineering Management at Toptal blog
- The Trident Model of Career Development by Patrick Kua
- 5 Engineering Manager Archetypes by Patrick Kua
Top comments (1)
Like this @robinpokorny Definitely two tracks - Management (look after the people doing the tech) and Individual Contributor (look after the tech being done by the people). Initially you may not have the budget/size for a split, but as soon as you do follow SOLID's Single Responsibility- haha - and optimise for outcomes (vs cost).