Tech Lead or no Tech Lead, that is the question
Even if i see value in a Tech lead, I value a tech organisation with no Tech lead more
The context
In my experience, what I expect from a tech organisation is engineers with seniority, proactivity and autonomy.
I see a Tech lead as a reference in some tech area (backend, frontend, devops, etc. ) that take architecture and key decisions about this area but he is not acting as a Manager (personal growth, empowerment, etc. ) even if she can help.
After going through a collective dismissal process , we were left with a high seniority tech team and decided to switch from strong hierarchy to almost 0 hierarchy, so that any engineer could take the tech decisions they want on the projects they are working on
Why no Tech Lead ?
I think it was a great idea and I would not go back to the Tech lead days and I will share my reasons why.
Accountability
With Tech Leads, even if you encourage people to be accountable for their decisions, engineers end up just asking their Leads what to do, and if any problem appears they just follow orders. They do not feel like decisions are their own if they don’t have the power to make the final call
With no Tech Leads, managers need to encourage consensus and taking advice from others, but the choice is clearly owned by each engineer.
Low voice vs Strong voice profiles
Even if we have a team with high seniority, every dev has different personalities. What happens with the figure of Tech Leadsis that for introverted engineers with a “low voice” finding space to express their opinion is harder.
Most of the time, only devs with a strong voice are able to question the Tech Lead’s suggestions.
With no Tech Leads, it is easier for them to be more proactive and autonomous, and it’s also easier for them to define their own solutions to problems.
Dynamic Tech Stack
Tech Leads are perfect for a static tech stack, but what to do with a PHP tech lead if you switch to NodeJS, for example?
Technology changes constantly and I think it’s easier for a Tech Lead to recommend a solution that he knows than to try something new.
Also it’s easier for everyone to explore new technologies or career paths without the weight of a Tech Lead title. We have people that act as an“informal” PHP reference that had explored NodeJS, later Devop, only to finally go back to PHP. Because there is no Tech lead on the team, everyone can act as a reference when it’s needed.
Career Path
For any software engineer the class path will be something like (Junior SE -> SE -> Senior SE -> Tech Lead )
To make it in the long run, you need to start adding levels and tests for accessing these levels and creating new ways of growing.
I believe in seniority (junior-senior), speciality (BE, FE,UXI, etc.)and impact (team, department, company). With these 3 concepts combined, you can define a career path for any engineer. Tech Lead is a short-term solution, but adds a lot of hidden complexity into the organisation (tests to advance, how many, definition of responsibilities, …)
But it’s not easy
Even if I believe this approach with no Tech lead is better, I cannot say it’s easy, or that it has no downsides.
Communication
We have a biweekly alignment meeting for each Tech area (BE, FE, UXUI, etc. ) and also a Monthly Tech meeting so everyone knows what solutions each team is implementing.
It requires a lot of managers’ effort to make it work, as the daily work makes the engineers forget about the importance of this communication or you can end up with teams reinventing the wheel.
Transversal arc decisions and maintenance
Once you have your transversal Architecture up and running, someone will need to take care about the solution agreed for each area, but because there is no Tech Lead, so there is no one with the explicit responsibility of defining the evolution for Frontend arc, to use an example.
Managers need to ensure that this happens. The devs’ motivation to grow on impact can lead the manager to find space for this transversal work. Finding ownership for transversal work when responsibility is shared is the main challenge for this no-Tech Lead approach.
Recognition
When someone doesn’t have a title like Tech lead but is acting as an “informal” reference for some technology, how can other engineers know and how can the engineer feel recognized?
We use our tech meetings to give them space to explain what they are working on, but sometimes it is not enough. We want to try new dynamic labels or badges. An engineer can be something like “Senior SE, ElasticSearch mentor” for one year and later change to a new project where he becomes “Senior SE, Laravel mentor”.
The label is temporary while they have contact and provided maintenance of the technology, and also gives visibility to the rest of the team.
Conclusion
The Tech Lead role solves some organisation problems, but in the long term you will have a healthier and more resilient tech team with no Tech Leads, because it puts you closer to the african proverb
“Alone we go faster, together we go further”.
Distributed decisions are slower and more complicated sometimes, but in my experience it is where the “magic” comes from.
