A common question I hear is, “Is the Tech Lead role necessary?” People argue against the role, claiming a team of well functioning developers can make decisions and prioritise what is important to work on. I completely agree with this position in an ideal world. Sadly the ideal world rarely exists.
Even when perfect conditions exist during which team members talk to each openly, discussing pros and cons before arriving at an agreed solution, it doesn’t take much to upset this delicate balance. Sometimes all it takes is for a new person joining the team, a person leaving or some stressful critical situation that drives the team into a state where arguing continues without end. My friend Roy Osherove calls this the “Chaos state.” I agree with him that a different style of leadership may be required, similar to the Situational Leadership Model.
Technical debates occur frequently in development teams. There is nothing worse than when the team reaches a frozen state of disagreement.
Image take from Emacswiki
The Tech Lead has the responsibility to help the team move forwards. Sometimes that means using their authority. Sometimes it means working with the team to find a way forward. Facilitation and negotiation skills are invaluable assets to a Tech Lead. Understanding decision making models helps the Tech Lead decide when to step in, or when to step back. What is important is finding a way forward.
Tech Leads are also beneficial to people outside of the team, forming a single point of contact. Medium to large organisations start to hit communication barriers because there are too many relationships to effectively build and maintain. The Tech Lead role simplifies the communication path, although simultaneously adds a single point of failure. The balance between these two trade-offs should be carefully managed and monitored.
When played well, the Tech Lead provides countless other benefits, however the Tech Lead role does not have to played by a single person. I admire teams who say they don’t have a Tech Lead and software is still effectively delivered. They have successfully distributed the Tech Lead responsibilities or established processes to mitigate the need for the role. It does not necessarily mean the role itself is useless. The Tech Lead role is just that – just a role. Instead of focusing on whether or not the role should or should not exist, it is better to focus on ensuring all Tech Lead responsibilities are met.
If you liked this article exploring the Tech Lead role, you will be interested in “Talking with Tech Leads,” a book that shares real life experiences from over 35 Tech Leads around the world. Now available on Leanpub.
My team has 3 tech leads. There’s the overall lead and two ‘sub-leads’ who are responsible for significant projects.
All three are pretty hands off when it comes to day to day work. Their main aim is to keep the project focussed from the technical side (whilst our project manager keeps an overall eye on things).
.
They are the final arbiter on technical decisions, but they rarely exercise that power. It’s only used when there’s some sort of breakdown in the team and we really cannot agree.
I have also seen very poor tech leads – dictatorial, planning consisted of them telling you how it should be implemented.
They did all code review and if they didn’t like something told you how ‘wrong’ you were.
This leads to totally disfunctional teams with not trust at all – if that is the ‘tech lead’ people see then I’m not surprisedthey don’t want them…
Not having a tech lead is fine as long as you don’t mind using coder time on these things:
* Interact with other tech leads on architecture & interoperability issues
* Interact with PM on schedule and deliverables
* Negotiate with BA on feature scheduling
* Line up other teams’ deliverables that your team depends on
* Provide technical feedback to PM & BA when prioritizing the backlog
* Be the single point of tech responsibility to upper management
* Coordinate response to production issues
AND if the tech lead is also the reporting-line manager for the team:
* Interview new team members
* Approve timesheets / time off
* Deal with the visa process
* Appraisals
* Budgeting
AND if you have an offshore team…
* Interact at odd-hours with the offshore folks
* Prepare work to be sent to the offshore team
* Be available to answer offshore portion of team’s questions at odd hours or suffer time consequences
* Code review offshore’s deliverables before committing
… and more.
I’m not complaining. I love my job and my organization’s mission. I just think the article missed parts of a tech lead’s job.
—–
5 million kids attend high schools where graduating isn’t the norm. Don’t settle for statistics. Teach For America. http://bit.ly/1r83xXZ
@Tristan – You give some good examples of different styles of Tech Leads, and it sounds like although your Tech Leads don’t use their authority everyday, they still might if a decision comes to a standstill. I agree with you about the “dictatorial” Tech Lead. They are certainly trouble!
@Ely – Thanks for listing out some of the Tech Lead activities. My intention for this post was not to cover them all as it would have been far too long!
Thank you both for your contribution.
To me, the most crucial part of the text is: “The Tech Lead role is just that – just a role. Instead of focusing on whether or not the role should or should not exist, it is better to focus on ensuring all Tech Lead responsibilities are met.”
I completely agree on that. 🙂