Roadmaps · L4

Tech Lead

A tech lead is responsible for the team's technical direction and the quality of delivery. They may keep writing code, but their main impact comes through decisions, review culture and the way the team works together.

← Roadmaps

How it differs from the previous level

A senior is responsible for the quality of their own work and nearby surroundings. A tech lead is responsible for the result of the whole team: how work is split, priorities, technical debt, risks and communication with stakeholders. Success is no longer measured by personal code volume but by what the team delivers.

Expected knowledge

Setting technical direction: strategy, principles and shared standards for the team
Documenting decisions: ADRs, design documents and C4 diagrams
Review culture: small PRs, blocking vs nit comments, tone
Delivery health: CI/CD, release strategy, feature flags, rollback
A quality system: testing strategy, static checks, Definition of Done
Operations: observability, incident management, postmortems
Making technical debt visible and balancing it against business demands
Planning work: splitting tasks, dependencies, managing uncertainty

Practical skills

Split a vague requirement into clear technical tasks for the team
Lead a design discussion and record the outcome as an ADR
Delegate work: state the outcome, the context and the acceptance criteria
Explain risks and options to stakeholders in non-technical language
Give feedback in one-to-one conversations and resolve tension inside the team
Balance coding with lead work and avoid putting yourself on the critical path

Common mistakes

Taking all the hard tasks personally and blocking the team's growth
Agreeing decisions verbally and leaving no written trace
Keeping technical debt apart from requirements so it never gets prioritised
Turning review into a control tool instead of a learning mechanism
Reporting a risk late, or softening it
Standardising everything according to personal taste

Learning priorities

1Shape technical direction and principlesExpress in simple written form what the team does and why; ADRs and C4 are the main tools.
2Make decisions visibleFor every significant choice, keep the context, options, decision and consequences.
3Build a quality cultureSmall PRs, explicit review rules, automated checks and an agreed Definition of Done.
4Keep delivery steadyCI/CD health, the release process, monitoring and learning after incidents.
5Grow the team and work with stakeholdersDelegate, give feedback, and communicate risks clearly and on time.

Architecture maturity

A tech lead keeps architecture alive in the team's everyday decisions. They make boundaries, dependencies and quality attributes clear to the whole team and make sure changes are carried out consistently. They see architecture not as an abstract diagram but as a practical frame fitted to the team's skills, time and risks.

Example questions

What do you do when two seniors disagree on a design?
How would you explain technical debt to the business and prioritise it?
How would you set up Pull Request review rules in a team?
How would you document a significant architecture decision?
An incident happened after a release; what are the next steps?
How do you balance delegating with staying in control?
What should a new team member know in their first month?

Exercises you can do on your own

Write an ADR for one real technical decision: context, at least three options, decision and consequences.
Draw C4 context and container diagrams for your system in ASCII or with a tool.
Write the team's Pull Request rules on one page: size, blocking vs nit, response time.
Compile a technical debt list: the risk, cost and proposed timing of each item.
Build a blameless postmortem template and fill it in for the last incident.

Articles for this level

Programs that fit

How close are you to this level?

The skills assessment builds a personal gap report from your answers. It is a recommendation, not a certificate.

Start the skills assessment Build your path to architect