The Tech Lead Handbook · The Tech Lead Role
Setting Technical Direction
Turn a pile of opinions into two or three written technical priorities that the team, product and management all understand and actually follow.
Scenario
Example team: the platform team (five engineers) supports twelve product teams. Everybody has opinions: move to Kubernetes, rewrite the deploy tool, add a service mesh, migrate logs. Each quarter the team starts several of them and finishes none.
What you see on the team
- Five half-finished initiatives, each with one champion.
- Product teams ask "what's your roadmap?" and get different answers from different people.
- Planning meetings re-argue the same debates every quarter.
- The team's most painful problem — slow, flaky deploys — is nobody's priority.
The common mistake
Treating technical direction as a list of technologies to adopt, decided by whoever argues hardest, and never written down.
Why it happens
Engineers are rewarded for interesting work, and new technology is interesting. Without an explicit link to problems and outcomes, every proposal looks equally valid. Unwritten direction can't be checked, so it drifts with each conversation.
The playbook
1. Start from problems, not solutions. List the team's top pains and risks with evidence: incident counts, deploy times, support tickets, cost.
2. Choose two or three priorities. Each is a problem to solve with a measurable outcome, not a technology:
| Priority | Why now | Outcome we expect | Not doing |
|---|---|---|---|
| Deploys are safe and fast | 6 failed deploys last quarter, median 45 min | Median deploy < 15 min, rollback in < 5 | Service mesh this half |
| Logs cost is under control | Logging bill +60% in a year | Cost per request back to last year's level | New log vendor evaluation |
3. Write it as a one-page strategy: context, the priorities, what you are not doing and why, how you'll know it's working. Will Larson's Work on what matters is a good reminder that leverage comes from picking the few things that matter.
4. Review it with product and your manager before publishing. Direction that ignores the roadmap will be overridden.
5. Revisit quarterly. Mark priorities done, changed or dropped, with reasons.
What to say
When proposing the direction:
"I looked at the last two quarters: six failed deploys, 45-minute median deploy time, and logging cost up 60%. I'm proposing we focus on those two problems this half and explicitly pause the mesh and the log-vendor work. Here's what we'd expect to see by the end of Q2. What am I missing?"
When someone pushes a pet project:
"It might be the right move later. Which of our two priorities does it help? If neither, let's put it in the 'later' list with your reasoning so it isn't lost."
Trade-offs
- Saying no to good ideas disappoints people; keeping a visible "later" list with the reasoning softens it.
- Too vague ("improve reliability") can't guide decisions; too specific ("adopt tool X") skips the problem.
- Fixed for a quarter may feel rigid; allow a change when evidence changes, and write down why.
Signals it's working
- Anyone on the team gives the same answer to "what are we focused on?".
- Proposals in design reviews reference the priorities.
- At quarter end, at least one priority is visibly done.
- Product teams stop asking for the platform roadmap — they read it.
Key points
- Direction is two or three problems with measurable outcomes, not a list of technologies.
- Write it on one page, including what you are not doing.
- Agree it with product and your manager before publishing; review quarterly.
- Keep a visible "later" list so good ideas are parked, not lost.
Practice questions
Your team has five half-finished technical initiatives. How do you get to a direction?
Answer
List the team's top problems with evidence, pick two or three as priorities with measurable outcomes, explicitly pause the rest in a visible 'later' list, agree it with product and your manager, and publish a one-page strategy reviewed quarterly.
Why should technical priorities be phrased as problems rather than technologies?
Answer
Problems with outcomes can be measured and compared; technologies can't. 'Median deploy under 15 minutes' guides many decisions and allows different solutions, while 'adopt Kubernetes' skips the question of whether it solves the most important problem.
An engineer keeps pushing a service mesh that isn't in the priorities. What do you say?
Answer
Ask which current priority it helps. If none, add it to the 'later' list with their reasoning and a trigger for revisiting (e.g. when cross-service auth becomes a priority), so the idea is parked visibly rather than dismissed.
Open in the app to mark lessons complete, take notes and track your progress.