3 Dec
2008

What It Takes To Be A Great Technical Lead

Category:General PostTag: :

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?

11 thoughts on “What It Takes To Be A Great Technical Lead

  1. All those points are bang-on, especially about involving the team.

    I’d probably add “diverse” in with strong technical skills. The two extremes are technical leads that are “gurus” in a particular realm of technology, and those that have more of a “street sense” around a variety of existing & emerging technologies. Both can work well, but “gurus” need to beware of becoming narrow-minded where every challenge becomes a nail to hit with a magic hammer. (SOA is one such magic hammer I’ve seen in practice.)

    Technical savy has it’s place, but the bottom line will always be budget & sales. A good technical lead ideally offers many options for solving business needs and can provide valuable and accurate input in early design stages to determine up front what is reasonable for a new or existing product.

    A balance between practical and theoretical expectation is a must. Technical leads that insist blindly on bleeding edge technologies to solve business requirements when more proven and cost effective solutions are available often end up turning “bleeding edge” into a very literal financial situation.

    My $0.02

  2. Scott Bellware had this magnificent post where he calls an agile architect a “PathFinder”. Alas, this was on his old blog so I can’t put out a link to it. Anyway, I personally like to live up to the term “PathFinder”.

  3. Very good post indeed, but I have a strange feeling on the overtime topic.
    On one side I am a strongly believer in no-overtime (and have been beaten by my beliefs :-p), but the “being the last one to leave the room” attitude can lead to all sorts of stupid competitions amongst coworkers or, even worse, people slacking off (or not being as productive as they can be) during normal work hours just to BE PART of the late pizza party.
    And this hurts everyone

    Corolary: do better than your best to align co-workers against overtime. After all, “God kills a kitten every time an engineer puts on overtime”

  4. Good post; technical leadership career paths should be discussed more.

    A lot of your points read like an agile scrum manifesto; is that by design or experience? The collaborative team notion almost goes against having a designated leader, though am unofficial one often emerges.

    Two dissenting points:
    1. If the team succeeds as a whole, it also fails as a whole.
    2. Hours != Productivity!! This is an outmoded industrial age concept that has no relevance in the information age.

  5. “First one in, last one to leave.” That’s a good philosophy for a project manager.

    Oh, and one thing that’s VERY important. (I missed thinking of this earlier.) A good lead developer HAS to be approachable! This means good communication skills with the rest of the team, and also doesn’t bog themselves down with work to the point that if anyone has any issue or problem they feel like they’re “bugging” the lead.

Comments are closed.