👋 Hey, it’s Stephane. I help engineers become great engineering managers - whether you want to become one or are already leading a team.
Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive.
A software engineer I mentor got recently offered the Tech Lead role for his team. He’s been in that team for a couple of years and the previous Tech Lead decided to leave.
He’s working in a team that owns a legacy service that nobody really wants to touch. Proposals he’s put forward, all kept getting rejected.
When he got the offer he asked me: if I become TL, will I finally have enough authority to actually modernise this service? Being the team’s Tech Lead surely will mean that people will have to listen to what I say.
I was not convinced.
Coasting
A team that’s coasting is hard to change.
People just do what they’re told within the boundaries of a comfort zone they have set for themselves and are used to.
Becoming tech lead for such a team will probably also come with responsibilities around setting technical direction, pushing for technical changes, and suggesting who’s best placed to work on what.
You can present a novel project, assign an owner & contributors to it, and expect it’ll get done. That’s only fair to expect. You can’t really expect that people will care about the project though if it’s within a coasting team in an area that they don’t feel comfortable about.
Will Larson describes a Tech Lead’s authority as proxied, which is an interesting way to look at it. You’re essentially borrowing authority from your manager, but you still have to remain trusted and aligned with the team and the manager.
The usual advice is to aim to “influence without authority”. Influence works really well when people already want to get to the same end-goal you have in mind.
The business case
There’s a pattern with engineers working on systems with lots of technical debt. They try to persuade everyone that X service needs to be completely refactored because it’s bad.
Any sensible manager then asks questions like:
Why? What’t the problem with it?
How long will the refactor take?
What happens if we do nothing about it?
And the answers to these questions are… underwhelming.
Don’t justify spending that much time on it.
You need to be able to create a compelling business case if you’re pushing so hard for such a big time investment.
And that’s only the first problem.
Even if you get the business to agree that something needs to change, you still need to decide what to actually change. A full rewrite of a service is very rarely the option you should advocate for.
You also need the team to want to do it btw. That’s the bit I think gets underestimated. On a team that has been coasting around the same legacy service for years, getting leadership to agree you getting time to work on something might actually be easier than getting people excited about doing it.
So, there are really three problems to solve:
Prove where the technical debt is hurting the business
Find the smallest modernisation work that can prove the investment is worth it
Find the engineers who will want to work on it
Below is what I’d do if I took a Tech Lead role for a team and situation like that 👇👇👇 (access with a paid subscription)