The case for spreading technical leadership in engineering teams
There are so many ways to think about organizing engineering leadership on teams, and a lot of the terms for technical leadership get overloaded. Do you have “tech leads”? Do you have a “lead dev”? Where does “seniority” fit into leadership? Surely you need a “staff engineer”? It’s a lot of noise, and hard to reason about. What’s one more blog post? Maybe you’ll just read the first paragraph. Fine by me, if you take nothing else away, take this: you must either practice pushing out leadership responsibility or recognize that your whole team isn’t practicing leadership.
In the article I will break down just a microcosm of this problem around the idea of ownership on teams of high autonomy. To do that I’ll talk about three types of technical leadership, all at the single level team:
Service Lead: an engineering role of someone responsible for the holistic view and support of a service (one or more apps).
Initiative Lead: an engineering role someone responsible for the holistic view and support of an initiative (like an epic).
Tech Lead: an engineering role OR job title for someone responsible for the holistic view and support of a collection of engineers and their work*
*sometimes this gets conflated with staff engineer; I don’t really want to debate that here.
Why we need them
An engineer can be a good engineer by writing quality software and completing cards in a reasonable volume and timeliness. There’s no shaming anyone who is contributing this way. A good engineer will often notice something immediately adjacent to their card and address that while they are doing their work. But there’s a lot of space between that and what an organization needs to run a healthy tech stack.
On any team, it’s easy to lose the forest (epic) for all the trees (stories). Agile-style cards are intentionally small/independent to let a developer laser-focus on a specific outcome. Some are written in big blocks at the start of an initiative, others may come along halfway through. But that means it’s also easy to lose track of the bigger story if you aren’t regularly checking in on frequent user delivery or some other stakeholder involvement (e.g. a very heavy hand in product/project management).
On Small Teams the problem is (almost) solved
On small teams, the three Leadership roles (and others) are often filled by the Engineering Manager. A dedicated manager with small enough scope (2–3 engineers, 1–4 microservices) may be able to track application performance, keep track of changes made on day-to-day basis to each of the 1–3 different initiatives, update technical documentation and guidance. But on top of people management and strategic planning or whatever other responsibilities this is too much.
Enter the Tech Lead, a senior engineer given the role/title to help balance the load. They can be proactive about all of the areas the team manages for a while, but they preserve centralized technical leadership while they do it. In addition to being Tech Lead, they also are serving as Initiative Lead on most new projects and Service Lead for the team’s domain. And when they get promoted or find a new job, you have conversations about “Who could possibly fill the role?” and “is that developer ready for leadership? It’s a big step.” Because that Tech Lead was juggling all the lead responsibility and other engineers were churning out cards.
On Large Teams the problem changes shapes
There’s a natural inclination to hire more tech leads. Surely that will solve the problem! But you still centralize the skills. You either have generalized ownership (nobody really owns anything) or you have silos where tech leads manage their fiefdoms and don’t venture out. The latter tends to lead to team splits and the former tends to miss solving the original problem: how do I get proactive, thoughtful engineering between the seams.
You must either practice pushing out leadership responsibility or recognize that your whole team isn’t practicing leadership.
Pushing Leadership Out
What we need is a way to spread out the leadership functions of each role to different members of the team, encouraging all team members to be proactive. If you want that junior or mid or senior to take a lead someday, don’t they need to be practicing the necessary skills? Think about the nuanced responsibilities of a good Lead Dev:
- Think about systems holistically
- Make tradeoffs between buying and building products
- Understanding industry standards or even cutting edge techniques and when to apply them
- Planning technical work to improve a platform without a product/user story given
- Recognizing outage/disaster situations before they happen and finding ways to proactively improve platforms
- Make tradeoffs to decide when to advocate or perform work beyond the backlog and when to focus on card velocity
- …and many more
With good role models and coaching and the right opportunities, a developer may pick up some good patterns for how to do this, but they need to practice. They need to have a sense of ownership and feel like they will be the ones who know what’s right, not that what’s right will always come to them on a story card.
What a Good Lead Is
Hopefully, you’re on board and can start thinking of ways to split up leadership roles. So let’s dig into teach type with some examples.
Service Lead
A Service Lead will work proactively to examine performance of systems and write work to improve system performance. They regularly review service documentation and ensure architecture documents related to a system are correct. They try to minimize the overhead other developers will absorb when beginning work in their service area, and can serve as the primary point of contact for technical questions.
Example: Anna is the Service Lead for User Checkout, which involves the Address and Inventory services. Anna notices that the Address service is performing unusually slowly. They look through metrics and discover a recent deploy increased latency by 15%. While investigating it they discover some docs are out of date and the architecture hasn’t been updated to account for a few of the new containers. She cuts new stories for the latency bug and the docs changes on the backlog to address each one and brings it up with the team.
Initiative Lead
An Initiative Lead review and updates a plan when design decisions occur, look for gaps in technical plans and update work accordingly. They ensure architecture documents related to an initiative are cohesive and tell a consistent story, and can serve as the primary point of contact for technical questions. They act as the technical fact checker to help the project manager know that the project is on track.
Example: Andy is the Initiative Lead for our migration from the old Widget API to the new Widget API. During a team conversation about the cutover, it’s realized that a recent change to the new API might complicate the migration. Andy follows up by cutting cards for the new work. Andy reviews the backlog to make sure that these new cards make sense in context and notifies the product manager if it affects the overall product.
Tech Lead
A Tech Lead is someone who is able to guide an engineering team in best practices, workflow/tooling improvements, facilitating architecture discussions, and generally serving as a guide for where the team should be going in practice and architecture. Likely, a Tech Lead is also very comfortable serving as a Service or Initiative lead in multiple areas.
Example: Ari is one of two Tech Leads on the Widget Team. They notice that a lot of the developers are having issues with the CI/CD pipelines and spend some time looking into it. After identifying two separate problems they cut a card for the team to make changes and reach out to the CI/CD platform team to ask for help on another issue they can’t fix. They share the information with the team and recommend a standard way to configure CI/CD for all the team projects.
What a Lead Isn’t
There’s a danger of saying “yes we’re all in, let’s have 5 leads on our 5 person team” and suddenly finding yourself in a situation where developers don’t cross-pollinate or put up walls on their gardens. It’s important to orient strongly away from that. Here are a few guides to explain
- No siloing of work — The lead should be a big source of new or changed work, not the primary person through which work gets done. The sign of a well done lead role is that others can work in your domain easily, or even that you do a minority of the work there because it’s so easy for others to contribute.
- No prideful leaders — Just because you have a responsibility doesn’t mean you look bad if others notice things that could improve. Welcome input, welcome different ideas. It’s yours to help/inspire, not control.
- No forced leads— 3 engineers doesn’t need to divide 3 lead roles evenly. Some junior folks need to work on just contributing and building up skills. Some mid-level folks aren’t interested or skilled in holistic thinking. And some seniors have too many other things to worry about to do these roles well. And everything in between. “Whole team practice” means that you all do this thoughtfully and work on leading and following together. Decide who can lead today and who can stretch to have new responsibilities.
- No permanent posts — It will be necessary to hand off leads when employees leave or even go on vacation, especially for initiatives. This should be normal and you should try to rotate ownership regularly just to keep
- No forgotten leads — If you don’t care enough to check in on it, you shouldn’t assign a lead to it. Asking an engineer “hey, how do you feel the Widget project is going” should never get a “oh, I haven’t thought about it in a long time, nobody cares about that thing”.
Tech Lead
I hope you agree with the case for spreading out leadership roles. If not, maybe you took away see why it’s so important to decouple Tech Leads — especially when it’s a title — from Initiative Leads and Service Leads.
And remember, these are all roles first. Just because it’s not a formal title or a granted position doesn’t mean you can’t exercise these skills at any time. Take responsibility for a bigger part of your engineering domain and see where that takes you, even if you are the only one who knows you are doing it.
More Reading on this Topic: