The Tech Lead Role

While Tech Leads are present in almost every tech company, the ambiguity in their role can lead to misunderstanding and waste. I think Tech Leads provide the most value when they have a clear vision of their role and its responsibilities.

The Tech Lead (TL) role is widely and loosely defined. It can mean everything from "most senior dev on the team" to "HR People Manager over developers". I'd define it as "person with final say on technical decisions and responsible for all technical output of a team". In my definition, the TL works with and oversees the developers on their team, even though those devs usually report to a separate people manager.

Junior developers start their career by pulling singular cards and understanding the system just enough to complete that block of work. They don't decide what card to play or why it's more valuable than other cards, though they should be learning the answer to those questions. As developers grow, they become more involved with the planning and design side of software: they attend grooming sessions, break down features into cards, and eventually move to decomposing user needs into those features. As a developer moves towards a TL or architect role, they continue to take on more tasks that require self (and team) direction, instead of fulfilling pre-designed tasks. This parallels business in general, as a foot soldier, you don't question orders, but as a CEO (though you may get many suggestions) there is no one to tell you what to do; you have to decide the path for your team.

A developer is responsible for completing their card. A tech lead is responsible for a team's technology holistically. There are many factors and compromises to be made, and the sphere of responsibility and the sphere of influence don't always fully overlap, but that doesn't change the goal of the job. As a TL, you have more insight into the team than any of the bosses in the chain above you, and the competent leaders above you are counting on you to be able to assess and redirect the team as needed to achieve its goals.

I love being a tech lead. In part that's because it's about as close as you can get to being a CTO without having to be far up the career ladder or take on as much personal risk. My job isn't to work a specific card, or to develop a specific feature, it's (along with my other team leads) to tend and grow a mature software building team. My role specifically is to guide, develop, and oversee the team from a software development practices side. I expect to share prioritization work with my product owner (though they have final say) and to assist my team's people manager, generally by giving insight into their people's technical skill level. In my domains, I don't expect to be told to make a different technical decision, nor what style or practices to focus on. I'm actively seeking advice in all these areas, but I have a responsibility and an expectation that making those decisions is my contribution to the company. This is a broad scope and naturally entails a level of ambiguity.

I believe the best tech leads are constantly context switching between translating business desires into features, working with the product owner and delivery manager/scrum master to estimate and prioritize work, collaborating with other areas and teams (security, architecture, integrations), working with the devs (coaching, reviews), and doing technical work (card, proof of concepts etc). A good TL isn't waiting to be told which area to focus on, but is constantly evaluating the best use of their focus. They know they can't possibly get done everything that would be valuable for them to do, so they're constantly making priority calls on what to focus on. I think TLs styles can and should vary, and I think that the same TL may operate very differently on different teams and even on the same team at different times, as they adjust to fit what the team needs. These choices are subjective and messy.

In the course of my career, the average TL I see does card or sprint work about 20% of the time. Because I love coding, I've often been able to find ways (even if it means working more hours) to code closer to 60% of my TL time. I wouldn't recommend this to the average TL, and I believe I've been able to do it because I've ruthlessly pushed back against busywork. I fight against low value meetings, I've regularly invested time in tooling to eliminate tedious administrative tasks, and I've really focused on empowering devs to take over parts of my job (eventually helping them to become tech leads themselves). While sometimes a TL needs to shield a team by participating themselves in really low value busy work, it's even better to fight against having that low value work in the first place. I believe a necessary part of the TL's job is to identify time sinks, whether they are coming from an overly ambitious dev, a product owner that misunderstands time and effort for a feature, or even a boss or exec who is disconnected from the tech.

I do not believe that a TL's time should be factored into any kind of capacity estimation as it's essential that a TL has freedom to pivot to whatever is most needed for the team, at any time. That may be coaching a struggling dev one day and calming a concerned stake holder the next. If the TL does not have this flexibility, it means that he's been reduced to a 'senior dev' position, and that essential role of a TL is not being fulfilled. This is in line with how a product owner or people manager's time is not tracked as part of team capacity, even though they are necessary for the functioning of the team; they, like the TL, are a different role from a developer.

The TL position is not for everyone, it requires a self drive as well as an ability to feel comfortable in ambiguity. It's a challenging role, but that very challenge makes it more interesting.