Tips for managing technical people – Train technical leadership
21 September 2016, by Zoe Cunningham
The following is an excerpt from my new book, “Galvanizing the Geeks – Tips for Managing Technical People”. You can buy the full book on my website, here.
You need to ensure that there’s a technical career path as well as a management one open to your managees. Many companies nowadays ensure that there’s a path by which their technical people can reach the very top of the company, whether this is via a Technical Advisory Board (favoured by companies such as Thoughtworks and UBS) or by other means.
Creating the technical path and putting people on it isn’t enough. You also need to train people to fill the relevant roles. A common misunderstanding of the technical lead role is to see it as a sort of glorified developer, who gets to tell the other developers what to do. While a progression to project manager is seen as a move to a different role, the role of the technical lead can be seen as ‘more of the same’.
But in fact there are key differences between a developer role and a technical lead.
- A technical lead needs to take responsibility for the technical integrity of a piece of software. Although there will be a project manager who is responsible for delivery to the business, they may well be either non-technical or too busy elsewhere to personally ensure the quality of the deliverables. So the buck for technical quality stops with the tech lead. A developer needs only to code their own components well.
- The technical lead must know about all areas of the delivery, including testing and rollout strategy. Unless you stick with a single technology and are lucky enough to not have to take advantage of any new advances (which in my experience is hardly ever), the tech lead has to find time to learn on the job about new technology and how to implement it. A developer will often work on one particular area, usually one in which they have specific expertise.
- The technical lead needs to take responsibility for the output of each developer. They cannot say ‘But George coded that part’! If they’re going to be the tech lead for a long period of time with the same developers, they’ll also need to be able to train and develop them in order to get the best long-term output. A developer only needs to be responsible for their own code.
- Conflicts may arise around the best way to do something. Indeed, in a healthy environment, debate will be nurtured and encouraged. The technical lead needs to not only be able to calm down any heated tempers and reach a resolution but also to facilitate the participation of everyone in the team, hear the views of those who don’t shout as loud, and keep their own temper long enough to hear out any developers who are contributing in less constructive ways. An even-tempered developer can keep their head down and stay out of the way of any conflicts.
Luckily, it’s easy to train for a technical lead role, especially while working as a developer.
The first area to worry about is self-leadership. It’s easy to look to others for direction, but when you’re working on a piece of code and there’s a trade-off to be made, a training tech lead finds out the high-level parameters of the project and works out their own answer. You’ll become a much more valuable member of the team if you’re reporting in with solutions (for review, of course) rather than with problems.
Customer interaction can be a good way to step up and show your leadership (see Be nice to the customer). There will almost always be non-technical restrictions that you have to overcome in order to get to the right technical decision (of course, making sure you have a good relationship with your project manager can be a good way to get what you need approved without having to do the dirty work yourself).
Setting yourself up as an expert in a certain area can help you to train in enabling others and setting technical direction. It will also teach you how to ramp-up to the level of expert in a new technology in order to be able to take the right decisions for your team.
Taking responsibility is one of the easiest skills to practise – and you don’t need anyone’s permission to do it. It was one of my great ‘d’oh!’ moments when I realised that responsibility is taken, not given; you may not get credit for it, but making sure you get credit is a completely different skill, and one that you can learn later. Pick whichever area of the project has had least attention, and work out what needs fixing up. Once you’re confident that you can deliver (if you can’t, then this next step will be counterproductive), ask your tech lead if there’s anything that you can put your mind to. It’s likely that to start with they’ll want to double-check anything you do, but, as you show that you can pre-empt and prevent problems, they’ll come to trust you – and, ultimately, rely on you.
At this point, it’s helpful to ask ‘What is leadership?’ The talent leadership programme used by the technical department at UBS sums it up as follows:
- Notice that something needs doing
- Work out what to do about it
- Do it
I love this way of breaking the issue down – it both makes it seem easy (‘hey! I could do that!’) and gives you a clear structure for working out where you are going wrong. Is it that everything seems to be going swimmingly until you get to the end and someone points out the issues (i.e. that you’re not noticing what needs doing)? Is it that you know what needs fixing but you don’t know how to fix it? Or is it that you know both what is broken and what to do about it, but for some reason have never got around to doing it?
My problems were always at step number two. It amazed me how many times a problem would arise or be pointed out to me, and I’d realise that I had spotted it and yet let it drift away without sitting down to work out how to prevent it. On the other hand, some types of problem got dispatched swiftly. It was all to do with whether I knew what to do or not.
The fact that a person can demonstrate all the key skills of a technical lead while working as a developer makes it much easier for you, the person responsible for recruiting technical leads and ensuring that they’re performing well. You don’t need to take a plunge into the unknown when you appoint a new tech lead; you can simply look at how they’re getting on as a developer, give them the guidance they need, and see whether they can put it into practice.