No Tech Lead
I’ve had many discussions about the notion of a ‘tech lead’ in a team of developers. It’s something I feel passionate about as it affects both me personally and the entire software development industry.
Yesterday, I read the blog post Good Tech Lead, Bad Tech Lead by Jason Liszka. Jason’s post offers me an ideal reference to argue my views and has prompted me to write this post, for which I’m grateful. This post is at least partially formed as a reaction to Jason’s post, which I think is very good and highlights some very important points for a tech lead, assuming a tech lead exists.
I challenge the ‘tech lead’ model and propose that a ‘no tech lead’ model with a complete focus on teams opposed to individuals is way more productive and a lot more rewarding not just for team members who would otherwise be followers, but for the team member who would otherwise be leading.
I was a tech lead for a number of years. During that time I believed that the model of a more qualified individual leading with less qualified developers following was a natural method of organisation and I felt qualified to be the tech lead. It was an informal position since I had no official ‘lead’ title nor subordinates in the org chart but it felt productive and I certainly used it when it came to compensation negotiation.
For the last few years, I’ve been involved in a far more productive and rewarding model of team organisation. In my current team, we have no tech lead. We have team members with substantially different levels of experience but we have not used this as a means to ‘grade’ team members and identify a tech lead. Instead, we’ve used the differences to improve the team as a whole by spreading knowledge by use of various practices, gradually smoothing out differences in skills and experience whilst recognising that individuals will always differ in certain ways and using those lasting differences in positive ways.
This has been far more rewarding for me since I now work in a team which has better levels of experience as a whole. I have far more trust in my team mates. When I am on leave, I have absolute confidence that the team can functionally equally well in my absence (with an according reduction in capacity due to a missing team member). I learn way more since two way communication and learning is continuous throughout the entire team.
One of the motivations for the ‘tech lead’ model is career progression. Career progression may be important for an individual but it has nothing to do with maximising the productivity of a development team. Skewing the organisation of a development team to meet career progression aspirations of an individual can only be negative for a team.
Compensation justification can often be a major factor and indeed I used my tech lead position to drive my compensation upward in the past. In my view compensation should be something considered outside the organisation of a team. Individuals should be compensated according to the value they provide to the team and can also be affected by their relative level of experience and their individual desirability to other companies. Indeed a ‘no tech lead’ team will evolve to smooth out differences in individuals and should therefore smooth out differences in compensation.
One of the major obstacles is the traditional company hierarchy. Most companies are still formed as vertically oriented hierarchies and people have to be seen to be progressing up org charts in order to justify better compensation. Some companies, such as GitHub, have demonstrated that there is no need for this. However, in most companies, there is still a need for line managers but that is a separate discussion and the reasons are highly removed from anything technical. When this notion of hierarchy leaks down to the technical level, the practices of a team are skewed inappropriately and the effect is counter-productive.
I will now criticise each section of Jason’s post from my ‘no tech lead’ view.
Teamwork
Good tech leads act as a member of the team, and consider themselves successful when the team is successful. They take their share of unsexy grungy work and clear roadblocks so their team can operate at 100%. They work to broaden the technical capabilities of their team, making sure knowledge of critical systems is not concentrated in one or two minds.
Bad tech leads take the high-profile tasks for themselves and are motivated by being able to take credit for doing the work. They optimize locally, keeping team members working on projects that benefit the team at the expense of the engineering organization at large.
Everything listed in ‘good’ is what every member of the team should be doing.
Everything listed in ‘bad’ outlines some typical problems of having a tech lead.
Technical vision
Good tech leads have an overall vision for the technical direction of the product and make sure the team understands it. They delegate feature areas to other team members and let them own their decisions. They recognize that their team members are smart, trust them, and rely on them to handle significant pieces of the project.
Bad tech leads resist explaining or clarifying the technical direction and dictate decisions instead. They keep critical institutional knowledge in their heads, failing to multiply their effectiveness by creating and disseminating helpful documentation.
If the team understand the technical vision then they share it. Why should one person be responsible for it rather than the whole team?
Why delegate? Why does one person know best? The team can self organise. Command and control does not work for software development.
The recognition that team members are smart, trusting them and relying on them is a relationship all team members should have with each other.
Everything listed in ‘bad’ outlines some typical problems of having a tech lead.
Technical direction and institutional knowledge are things that the team needs to share through appropriate activities, e.g. whiteboard sessions, backlog grooming. If these things are shared assets of the team then there is rarely a need to produce documentation describing them. Documentation which is regularly produced for this purpose is usually never read.
Discussion and debate
Good tech leads listen and encourage debate. When the team is unable to resolve a debate, they describe a process or framework of thinking that would help them resolve it. They don’t enter discussions with foregone conclusions, and always allow themselves to be persuaded by great ideas.
Bad tech leads allow debates to go on for too long without resolution, hampering the productivity of the team. Others cut off debate prematurely, dismissing new discussions by saying the matter is “already settled.” Bad tech leads believe it is more important that they win the argument than that the team reaches the right decision.
All members of the team need to be doing the things in ‘good’.
In my team we have heated debates and we always manage to settle them somehow. Sometimes, a team member takes the position of mediator and suggests a resolution to a particularly difficult conflict of views. This role emerges organically during the debate and is usually the best person to have taken that role for that given debate. This is better than appointing one person to always mediate regardless and avoids the problems listed in ‘bad’.
Project management
Good tech leads are proactive. They make sure technical progress is on track. They work with team members to come up with estimates and to establish intermediate milestones. They anticipate areas of concern and make sure they are addressed before they become a problem. They identify technical roadblocks and help the team get around them. They identify areas of overlap where work can be shared, and conversely, find areas that are not getting enough attention and direct resources toward it.
Bad tech leads are reactive. They may delegate, but do not follow up to make sure progress is being made. They don’t set intermediate goals and hope that everything just comes together in the end. They wait until just before launch to do end-to-end tests of complex systems. They allow team members to waste time on interesting but unimportant work.
The team should be addressing the things listed in ‘good’ together.
There should be a shared vision of where the project is heading and this should be reinforced with activities such as whiteboard sessions with domain experts and product owners, and story mapping.
The team should overcome technical roadblocks together.
The team should have continuous knowledge of what everyone is working on making it easy to avoid duplicated effort.
Backlog prioritisation and grooming will highlight areas which are not getting enough attention and the team can self organise to address them.
Pragmatism
Good tech leads are pragmatic and find a balance between doing it right and getting it done. They cut corners when it’s expedient but never out of laziness. They encourage their team to find temporary shortcuts or workarounds to problems that are blocking overall progress, and to build minimum viable infrastructure for launch. To good tech leads, details matter. Code quality, code reviews, and testing are just as important as shipping on time.
Bad tech leads take shortcuts that save time in the short term but cost more in the long term, and let technical debt pile up. They cannot distinguish between situations that call for expediency and those that call for perfection.
The team should be collectively pragmatic.
The team should identify and agree pragmatic paths to progress during backlog grooming and whilst work is being done through continuous communication, reinforced with code reviews.
Code quality, code reviews and testing are baked into the ‘definition of done’ agreed by the team.
Management of technical debt and the balance between expediency and perfection are team exercises.
Communication
Good tech leads know that their role is much more than writing code, that effective communication is a vital part of their job, and that time spent making their team more efficient is time well spent. They acknowledge that some communication overhead is necessary when working on a team, and they sacrifice some personal productivity for overall team productivity.
Bad tech leads believe that they are most productive when they are writing code, and think communication is a distraction. They do not optimize for overall team productivity, but rather for what works best for themselves. They get frustrated when they have to take time to lead.
Communication is not an overhead. It is the lifeblood of a team.
A team which does not have enough communication is dysfunctional. The things listed in ‘good’ and ‘bad’ apply to a team, not an individual.
Relationship with Product
Good tech leads are in a conversation with product managers and designers about how the product should work. They are not afraid to push back on decisions they disagree with, but keep the product goals in mind and know when to accommodate them. They find creative workarounds to technical constraints by suggesting alternative product formulations that are less technically demanding, and help PMs and designers understand technical challenges so that they make informed trade-offs themselves.
Bad tech leads throw product decisions “over the wall” and do not take ownership of the product. They push back due to technical constraints but do not offer alternatives or explanations.
I would simply replace the term ‘tech lead’ with ‘team’ in this entire section.
The team, and not an individual, should have a good relationship with the product manager and domain experts.
During backlog grooming, when a story is identified as requiring more in depth conversation with the product owner or a domain expert, the team can self organise and assign the task to the most effective subset of the team for the given story.
Resiliency
Good tech leads are resilient to changes to the product specification and react calmly to surprises. They anticipate where changes might take place and design their code to handle them.
Bad tech leads are upset when the specification changes, or prematurely generalize their design in areas where changes are unlikely to occur.
The team should be displaying all the qualities listed.
Software architecture is not an up-front exercise but is an evolution. The team should own the architecture collectively and evolve it together during backlog grooming, whiteboards sessions, spikes and continuous communication.
Personality
Good tech leads are easy-going but assertive. Bad tech leads are confrontational and aggressive. Good tech leads emerge naturally and earn respect through technical competence and experience. Bad tech leads think their title confers respect and authority. Good tech leads are always looking for ways to improve.
Bad tech leads get defensive when given feedback. Good tech leads are humble and boost the confidence of everyone else on the team. Bad tech leads are arrogant and take pleasure in making their teammates feel inferior.
The ‘good’ and ‘bad’ personality traits apply to all team members.
Every team has members with (sometimes wildly) varying skills and levels of experience and these should be embraced as the team self organises rather than elevating an individual to a special status.
Team members earn respect from one another through technical competence and experience.
The team should always be searching for ways to share the knowledge of more experienced team members with those less experienced. Practices such as pair programming and gated commits spread knowledge through the team, avoid single person dependencies and accelerate the development of less experienced team members. This avoids inappropriate expectations of respect and authority, and feelings of arrogance.
Tweet