When a software engineer shows management potential, they usually start by supervising others in their team. Then they become a team leader, still managing people who use technologies they understand. They can have a detailed discussion, offer advice, challenge proposals and mentor junior members. They learn lots of new soft skills in management, but technically they are still well within their comfort zone.
Moving into strange territory
The next jump is a surprisingly difficult one. They are promoted to manage a technical team using technologies that they don’t know themselves. This can cause a big loss of confidence. The person who relies on being the expert in the room has to adjust to knowing less than other people.
At first, that doesn’t feel okay. They can’t always follow the discussion. They can’t offer advice or mentor juniors. And they are hesitant to challenge those who are specialists in the field. So they question their own value, and long to return to their comfort zone. Getting back the expert label by learning the technology is a big temptation, but a mistake.
It takes support from senior leaders to help new managers through this transition. When I first moved to lead a team using SAP, all my hard-won experience seemed useless, but I wasn’t allowed to train in SAP myself. It took time to realise that I had a lot of transferable skills that could add value to the new team.
Using what you know
Coding skills are only one part of the package. Many other skills are necessary to a development team, such as analysis, communicating with users, estimating etc. For instance, expertise in analysis develops over many years, then applies in any situation:
- fully grasping the business problem
- asking questions to tease out different scenarios and edge cases
- analysing data
- comparing input from multiple sources to spot hidden nuances
- judging the relative importance of different aspects
- playing it back to confirm understanding
- drawing out assumptions and checking them
- paying attention to the unspoken requirements for usability, performance etc
Other skills are just as important, for instance being able to assess a potential solution that the team recommend. While managers need to respect the team’s technical expertise, they should never just rubber-stamp proposals. Key questions include:
- Have the team done this before, or is it new for them?
- Will it definitely work in this technology, or do elements need research?
- Does it actually solve the whole problem, or just part of it?
- Will it be intuitive for the end user to learn and to use?
- What happens when the user does something stupid? What happens when a server crashes or something else goes wrong?
- Will it be easy to implement and to support long term?
- Were any other solutions considered? Why were they discarded?
- What are the risks in this approach?
- Can they simplify anything without losing value?
- Does the estimate seem reasonable, comparing the cost and the likely benefit, and also comparing it to similar problems met before.
Getting more comfortable
If the team use planning poker, it is helpful to be an observer sometimes. When I was a product manager, I attended SCRUM meetings to explain business issues and answer questions. The team came up with solutions and voted until they reached consensus. I never voted. But I learned a lot from the discussions and became able to predict estimates fairly accurately.
Over time, you get to know your team and their inclinations. A common tendency is the desire to re-engineer code constantly. While it comes with all sorts of justifications, it generally distracts from more profitable work.
Another common trait is the impulse to gold-plate solutions. A drive for quality is essential, but it can go too far. Watch out for solutions where the estimate is far higher than expected. Do they have too much future-proofing or make false assumptions? I once refused to approve a proposal with a 3 month estimate. The developer threw up his hands in frustration and sulked for a bit. Then he came back with a different solution that would only take a week but wouldn’t do X. It didn’t need to do X anyway, so I happily approved the second proposal.
Offering support
Promoting technical people to management roles is a natural path for a growing business. There are huge advantages. Once the new manager appreciates their own expertise, they will become comfortable around specialists in unfamiliar technologies and begin to add real value in the new team.
But be aware of the transition required. New managers need encouragement to prevent a loss of confidence. If your managers are under-performing, they need you to support them. But they don’t need to become expert in the technology. They have other valuable skills that the team needs more.
If your management team is struggling to step up, get in touch for a free, no-obligation chat. I’ve made the jump myself, and trained numerous other technical experts to become effective as managers.