Problematic archetypes of a tech lead
How do you know when having a tech lead may be taking your organisation in the wrong direction? Let’s take a look at some of the archetypical tech leads, their pitfalls and ways to go about and deal with them.
During my career I’ve filled roles like lead developer, software architect and tech lead. It generally meant that I carried responsibility for something like 'technical quality' of the delivered products and for somehow safeguarding that the capability of the team to deliver that quality was sufficient.
At its best, this role entails coaching and setting out guidelines to help developers be more effective or efficient, and leading by example as a developer. At its worst though, there have been moments where it worked out so poorly that I considered the role of tech lead to be detrimental - an antipattern for the software development process it was meant to improve! Commonly the tech lead role is in relation to a single team, but as work scaled and teams split into focus areas, I’ve played the part for 2 or 3 teams.
Here are some archetypes you might encounter that you may want to deal with to avoid their pitfalls.
At the end of the article, I’ve added a list of references I use throughout the article. Recommended reading!
The Beacon
In any team there may be people who will avoid taking on responsibility or even shirk off the one they have, when they notice there’s someone who is inclined to step forward. It may not be problematic as long as things get done and people are happy with their share of the work. When a company explicitly makes one person a 'first among equals', you risk making the rest of the team complacent as they feel they have no skin in the game, having the tech lead as a shiny Beacon to defer to. The resulting lack of involvement is not a good way to put the brilliant minds of your team to good use.
How to spot
-
When a decision needs to be made or an opinion is asked, developers defer to the Beacon rather than stepping forward and taking initiative.
What to keep
-
The Beacon can set an example in chasing ambition, taking responsibility for successes and learning from failures.
How to improve
-
Have the tech lead assign responsibility to others over particular matters or problem areas.
The Stranger
Tech leads tend to gather with stakeholders outside the team to fetch and bring information. I’ve sat and aligned with HR, enterprise architects, other tech leads, program managers, etc frequently. The Stranger is a tech lead who is away so often, that they risk becoming detached from the team. Given that the tech lead is in many ways treated as a representant of their team, this may be cause for misunderstandings and misalignment.
How to spot
-
People less familiar with a team can interact with a team for days and not realize the Stranger belongs with them.
-
A meeting with the Stranger needs to be planned well ahead of time and they tend to not show up at regular meetings like retrospectives and refinements.
-
The reasons leading a tech lead to become a Stranger may also lead to them being overworked and stressed.
What to keep
-
The Stranger is often someone who chooses to be called away so that the rest of the team can focus. Be careful that this doesn’t lead to the pitfalls of the Hollow (see below).
How to improve
-
Double check whether any of the existing information radiators that the team has put in place are sufficient for informing stakeholders outside the team. And if not, the tech lead can spend their time on making them sufficient.
-
The team can agree on a reasonable minimum amount of time to spend together to keep the bonds healthy.
-
If you’re in a Scrum team, you can typically expect to spend around 25% of your time on Scrum Events, which may not be as much as it sounds as I’ve described in my previous article on Time spent on Scrum Events. You need to wonder what other meetings a tech lead is uniquely required to attend that aren’t covered by the Scrum events.
-
Just because the tech lead is responsible, that doesn’t mean they cannot delegate alignment sessions to other team members occasionally. See the Irreplaceable archetype.
The Irreplaceable
A very vocal colleague of mine once said: "When there’s an expert in your team, it’s often just someone who cannot communicate".
Something to be wary of.
This applies to the tech lead as much as any T-shaped team member when they’re left to pick up something by themselves that is in their field of expertise. We consider pair programming part of the software craftsmanship toolbox (which borrows a great deal from the XP toolbox) as it ensures nobody carries the sole responsibility or expertise to do things that the team should be able to do (among many other things).
Yet for the non-coding activities of the Irreplaceable tech lead, this idea is often dropped as they enter into the realm of ad hoc management and alignment. And as they roam in that realm outside the view of their team, decisions and alignment tend to be put on hold when the Irreplaceable is temporarily unavailable - or worse: they’re made by others, without involving the team at all.
How to spot
-
Comparable to the Beacon, the team defers to the Irreplaceable. But in this case, it is not complacency but rather dependency or even ignorance that motivates that behavior. The team generally cannot answer questions pertaining to matters such as performance, quality, velocity, architecture, way of working and tech stack without the Irreplaceable and aligning with other teams on such matters is an ordeal without the Irreplaceable present.
What to keep
-
The Irreplaceable has a way of finding hidden concerns and invests in understanding matters that others may find tedious or difficult.
How to improve
-
As the things a tech lead does are vital for the team (why else bother in the first place), a case can be made for the tech lead having to pair up on execution like any other task performed by developers.
-
The deliverables of a tech lead might not always be as concretely sharable as the code in a repository or a working deployed artifact, but it is still very much a team deliverable worth sharing and reviewing with the team.
The Hollow
The Hollow is a tech lead who is involved in so many matters surrounding the team that they become detached from technology. Developers who can become tech leads generally have a wide field in which they are senior, including but not limited to technology.
Sometimes it may be a case of (developer) Imposter Syndrome when the Hollow fears they’ve lost touch with the technical subject matter, but it is an actual risk. If the team is learning how to use Kafka, or Angular, or Micronaut, or CQRS, or Kotlin, or New Relic, there is a learning curve that requires focus. Such periods are a test of concentration for any tech lead who is called away more than others, and of their ability to switch from bird’s eye view to low level detail and back, which is one of the key qualities a tech lead should have.
How to spot
-
The Hollow avoids technical decisions and lets things run their course. There is a risk that developers think there is agreement and direction on the choices made and the course followed, when there is in fact not.
-
The Hollow chooses to not touch code at all anymore, and spends time on other affairs such as architecture, alignment with other teams and supporting the product owner with requirements gathering. It may be that this is good use of the unique capabilities of the tech lead (be careful not to become the Irreplaceable though), but sometimes what the team needs is simply extra hands on deck. A tech lead should be able to chip in.
What to keep
-
I’ve learned that developers are rare who can dig into a problem quickly, grasp the essence of a problem at a glance, weigh technical solutions sufficiently to know where to start, do all that while keeping the higher level stakes outside the team in mind, and communicate with all those involved.
How to improve
-
The tech lead should plan for lower availability for other responsibilities while investing in technological focus.
-
Now might be an excellent time to consider pairing & sharing those other responsibilities with someone else. (Note that a mentor - student relationship is different than a pair programming relationship)
-
There is no shame in a tech lead deferring to a subject matter expert if a situation calls for it. Many tech leads typically become jack of all trades, but they should be the master of at least one: the ability to appreciate and cultivate expertise in others.
-
It is better to know that expertise is missing than to think it is present when it’s not. People can learn to work with their shortcomings if they are aware of them.
-
In fact, in the abovementioned blog there’s an additional list of recommendations on how to deal with developer imposter syndrome.
The Shotcaller
Comparable to the Beacon, a tech lead that hoards all responsibility and insists on being the decisionmaker may turn into the Shotcaller archetype when developers actually are not complacent. Instead, they long to have a say in matters and find the tech lead to be an obstacle.
How to spot
-
The team becomes cynical of the Shotcaller and second-guesses decisions.
-
Team members go behind the Shotcaller’s back to start their own initiatives.
-
When team members are confronted with things not working well, they blame the Shotcaller.
What to keep
-
When subject matter experts or senior developers cannot convince each other, the Shotcaller can force a decision so everyone can proceed.
How to improve
-
Take a look at something called the Advice Process. Any developer can take responsibility after asking the experts and affected people, which will include the tech lead.
-
Looking at the Hersey-Blanchard model for Situational Leadership, you’ll notice a leader should be aware of the competence and willingness ('commitment') of the developers in their team and involve and empower them accordingly.
The Stooge
When a tech lead is responsible for technical quality of deliverables and capability of team members, the question presents itself whether the organization really enables a tech lead to do their job. In the case of the Stooge, the power needed is placed outside the team instead of in the hands of the tech lead.
How to spot
-
Especially when the tech lead is an external hire, the Stooge tends to be confronted with a fait-accompli of internal employees being hired and moved around between teams like resources.
-
Similarly, decisions on architecture and tech stack may be imposed on the team. The Stooge is left with the thankless job of selling it to the team and implementing a target architecture rather than solving business problems and coaching the team on maneuvering within architectural guidelines.
-
The Stooge regularly partakes in time consuming struggles either sneaking in violations of directives under the radar or going through the hoops to get an audience with the architects for a chance to challenge them.
What to keep
-
It may not be the two way street you want initially, but the Stooge is still a door between worlds. When you consider the importance of empirical learning, it’s better to have a Stooge working on an earlier feedback loop than having no feedback loop at all.
How to improve
-
The tech lead should (be allowed to) be involved explicitly in the hiring, firing and evolving of team members, as explained in Tuckman’s 5 Stages of Group Development: forming, storming, norming, performing and adjourning.
-
The technical solution is the 'how' of solving a business problem, and unless the problem domain is simple or complicated (see the Cynefin Model on Complexity and Problemsolving), big up front design in the form of predetermined tech stack and architecture will hamper the team in performing their task. Teams should spend most of their effort on figuring out solutions to problems unique to their business domain, and that requires the freedom to come up with appropriate technical solutions.
