The problem: the best coder becomes the bottleneck

A senior engineer is promoted to tech lead of a team of six. For the first month they do what worked before: they take the hardest tickets, review every Pull Request themselves and answer every question in chat. The team ships, but slowly. Two colleagues wait for approvals, nobody else understands the payment module, and the lead's own tasks slip every sprint. Nothing is wrong with the engineer. The job changed, and the habits did not.

The core shift is simple to state and hard to live: as an individual contributor you are measured by what you build, as a tech lead by what the team builds and how well it can keep building without you. Your output is now decisions, clarity and other people's growth. Code is still part of the job, but it is no longer the main lever.

The first weeks: listen before you change anything

Resist the urge to announce a new process. Spend the first weeks collecting facts.

  • Hold a one-to-one with every engineer. Ask what slows them down, what they are proud of, what they would not touch, and what they want to learn.
  • Read the last few months of incidents, rollbacks and long-running Pull Requests. They show where the real pain is.
  • Draw the system. If no diagram exists, sketch a context and container view yourself (see the C4 model guide) and ask the team to correct it. Corrections are the valuable part.
  • Meet the people who depend on your team: product, support, operations, other teams. Ask what they expect and what surprises them.

Write down what you learn in a short document: the system, the pains, the open questions. Share it. This single page earns more trust than any new rule.

Setting technical direction without dictating it

A tech lead owns the direction, not every decision. A useful split:

  • You decide when the choice is cross-cutting, hard to reverse, or the team is stuck.
  • The team decides local choices inside agreed boundaries.
  • You ask for input and then decide when it is unclear which category applies.

Whatever you decide, make it visible. A decision that lives only in a meeting is forgotten within a few sprints and re-argued by every newcomer. Write short Architecture Decision Records, kept next to the code (see writing ADRs). A good record states the context, the options considered, the decision and the consequences, including the downside you accepted.

ADR-007: Keep order and payment in one deployable for now
Status: accepted
Context: team of six, one database, shared release cycle.
Options: (a) split services now, (b) modular monolith, (c) status quo.
Decision: (b) with separate packages and no cross-package table access.
Consequences: simpler operations; we must enforce module
boundaries in review; revisit when team count grows.

Boundary questions like this are covered in microservices boundaries.

Delegation that actually works

Delegation fails when it is either dumping ("handle this") or hovering ("I will just check every hour"). Delegate outcomes, not steps, and agree on four things: the goal, the constraints, how you will know it is done, and when you want to hear about problems.

Give people tasks slightly above their comfort zone, and pair the risky ones with a reviewer instead of taking the work back. Taking it back is faster today and costs you every day afterwards, because the team learns that difficult work flows to you.

A quick self-test: if you were unavailable for two weeks, which areas would stop? Each answer is a delegation or knowledge-sharing task for the next quarter.

Review culture and how much to code

Code review is the cheapest lever you have for quality and shared knowledge. Spread it: rotate reviewers, keep Pull Requests small, and agree on comment kinds so that blocking issues and style preferences are not mixed. The details are in code review culture. Your own reviews should model the tone you want.

On coding: stay close to the code, but off the critical path. Good lead tasks are spikes, prototypes, tooling, test infrastructure, and pairing sessions. A bad lead task is the feature everyone is waiting for, because any interruption blocks the team. Plan your calendar honestly; many leads find that a half-day block of focused work a few times a week is realistic, and meetings fill the rest.

Communicating with stakeholders

Stakeholders rarely want technical detail. They want to know what is coming, what is at risk and what you need from them. A short regular update works well:

  1. What was delivered since the last update.
  2. What is next, with a confidence level (high, medium, low) instead of a false date.
  3. Risks and the decision or help you need.

Say "no" with an alternative: what can be done with the available time, or what must be dropped to fit the new request. Report bad news early and with a proposed path. Surprises damage trust far more than delays.

The biggest risk in the new role is becoming invisible in the wrong way: either a micromanager who touches everything, or a leader who disappears into meetings. At the end of each week, ask yourself which obstacle I removed for the team this week and whose work became easier because of me. If there is no answer, rebuild your calendar. The question protects you from both extremes and brings the focus back to the team's flow.

Common mistakes

  • Changing many things at once, before understanding why the current way exists.
  • Remaining the best developer and the main reviewer simultaneously.
  • Making decisions silently, then being surprised when they are ignored.
  • Avoiding hard conversations about performance until they become emergencies.
  • Treating technical debt as a moral issue instead of a prioritised, explained trade-off.
  • Optimising for being needed instead of for the team's independence.

Trade-offs

Delegating more means accepting solutions that differ from yours. Accept them when they meet the agreed outcome, and save objections for correctness, security and reversibility. Writing decisions down costs time, so reserve ADRs for choices that are expensive to change. Staying hands-on keeps your credibility but can starve the leadership work, so adjust the balance each quarter.

A 30-60-90 outline

The numbers are a rhythm, not a promise.

  • First 30: one-to-ones, read incidents, draw the system, meet stakeholders, share the findings document.
  • Next 30: pick two or three improvements the team agrees on, start ADRs, rotate reviewers, delegate one meaningful area.
  • Last 30: review what changed with the team, set quarterly goals, agree on the update format with stakeholders, plan growth conversations.

Checklist

  • Every engineer has had a one-to-one with you.
  • A current system diagram exists and was corrected by the team.
  • Significant decisions are written down with consequences.
  • At least one area has moved from you to someone else.
  • Reviews are spread across the team and comment kinds are agreed.
  • Stakeholders receive a regular, short update.

Where to go next