The Inquisitive Coder – Davy Brion's Blog

Most teams have some kind of technical lead in place. They’re often referred to as the ‘dev lead’, or the ‘lead developer’ or the ‘lead programmer’ or whatever. Some people are great fits for this role, and some simply aren’t. Below is my list of what i think makes for a great technical lead. Note: i’m not claiming that i live up to all of this, although i do try to.

• You obviously need strong technical skills. You are responsible for the final result, so you better make sure that there is a solid technical foundation for the team to build upon. This doesn’t mean that you should build this foundation entirely yourself. Preferably, you involve your teammates into this as much as possible. You’re also responsible for fixing technical issues that your teammates can’t solve. You either fix it, or when that’s not possible you should figure out an acceptable workaround. Be sure that your teammates are fully aware of the details of the solution or the workaround.

• You have to be able to teach your teammates. As a technical lead it is your duty to improve the skills of your teammates. No matter how good you may be, if you can’t transfer that knowledge and those skills, you’re not doing a good job as a technical lead. If there are some core principles or practices that you want them to apply to their work, you need to make sure that each and every one of them really ‘gets’ it. You need to be willing to invest the time and effort it takes to achieve that.

• You need to trust your teammates. This isn’t always easy, especially when it’s about someone who hasn’t progressed as far or as fast as you would’ve liked him to. But it is definitely necessary. If a teammate realizes that you trust him, he will usually respond with improved output. It might not always be everything you hoped for… but either his effort, or the quality of the work will improve. Keep trusting the teammate, and eventually both will improve. Which actually happens a lot sooner than most people would think.

• Stimulate self-organization. I know a lot of people don’t believe in self organizing teams. And to an extent, that disbelief is somewhat valid. There always has to be one or a couple of people who have some kind of leadership role (be it officially or not). Those leadership roles do not prevent self organizing teams though, in fact, i’d say they enable them. Do not simply assign tasks to your teammates all the time. Organize planning meetings where members can choose the tasks they will do. Make sure there is always some kind of balance though. You really need to prevent that person A always gets the shitty tasks or that person B always get the funnest tasks. Mix it around it a little and try to make sure that the fun/shit ratio is never out of whack.

• Don’t keep the coolest technical tasks for yourself. If the project requires some kind of technical research to use a new library or to figure out an approach to a new problem or whatever, make sure all of the teammates get the chance to do these kind of things once in a while. It’s not always possible to do so, but when you can, it really pays off. Morale goes up, trust goes up in both directions, and everybody improves.

• Try to prevent overtime as much as possible. If you’ve been given an impossible deadline, try to convince management that it’s simply not doable. Fight for it if you must. But realistically speaking, you can’t extend every deadline they throw at you, and sooner or later you’re gonna be in a situation where you and your teammates are going to have to put in some overtime to get everything done on time. Don’t tell your teammates they have to do it. Ask them if they want to do it. For some people, this doesn’t always make a difference but for others, it makes a huge difference. And this one is very important when you’re doing overtime: do not go home early while your teammates are still working, because it will come back to bite you in the ass eventually.

• Remember that you are responsible for the final result. If something goes wrong, it really is your fault. Never put the blame on one of your teammates. Not within the team, and definitely not when managers are present. If a teammate screwed up and the problem made it into the production version, then that is your responsibility and your fault.

• Give credit where credit is due. If a teammate did a great job with something, give them that credit and make sure everyone else knows about it too, especially management. Never take credit for the work of a teammate because that is simply one of the lowest possible things you could do.

• Finally, you need to realize that your teammates are not your developers. I’ve often heard technical leads say things like “yeah, my developers…” or “my guys … “. No. They are your teammates, no matter what your role in the team is. Having a leadership role does not mean you are the boss of your teammates or that you can boss them around. If anything, it destroys morale and the results of your team will suffer tremendously from it.

And that’s my list… did i miss anything?