Performance evaluation
Should a Tech Lead code? The dilemma of leading while still being held accountable for delivery
In this article
Every Tech Lead has faced two demands in the same week: deliver what is assigned to them and take care of the team. The usual answer, “it depends”, rarely helps. This article explains where the dilemma comes from, what each side costs, and which criteria help decide how much code makes sense to take on.
In short
- A Tech Lead should code part of the time, and the more useful question is how much and what kind of code.
- The dilemma comes from two demands measured by different yardsticks: code has numbers, leadership barely does.
- The role has no single definition, and team size changes how much code fits in the schedule.
- Three criteria guide the decision: critical path, team size and product stage.
- An explicit agreement with the team and with management replaces guilt with a conscious choice.
A Thursday at the end of the sprint
Illustrative scenario, composed for this article. It does not describe a real person or company.
Rafael is the Tech Lead of a squad of six. The sprint closes on Friday. He has a critical PR to finish, three code reviews waiting for him and a 1:1 he has already rescheduled twice. By 6 p.m., the PR is done and the reviews are finished, but the 1:1 slips to the following week.
On Friday, management asks about delivery and he answers with what went to production. Nobody asks about the dev who spent two days blocked waiting for an architecture decision, or about the feedback he did not give. Rafael ends the week feeling like he did the work of two people and failed at one of them.
Two demands that do not fit in the same schedule
The dilemma exists because each demand uses a different yardstick. Delivering code has a ready-made one: PR opened, PR approved, task live. Leadership does not. Reviewing carefully, unblocking an architecture decision or running a good 1:1 are work that leaves almost no trace in sprint numbers.
This creates a predictable bias: what gets measured gets prioritized. A Tech Lead who wants to show results tends to take on more code, precisely because code is what shows. In that position, it is common to feel less time coding, more time in meetings and guilt for not “getting things done”.
What is left out is invisible work: architecture, mentoring and code review, which sustain the team’s quality but never show up on any dashboard. When only one of the two demands has a yardstick, the decision about how much to code stops being technical and becomes a reaction to what is being demanded.
Why the dilemma exists: the role has no single definition
Tech Lead does not mean the same thing everywhere. One line of thought separates three leadership responsibilities in a product team: product, technical and people. In practice, companies tend to combine these functions in two people, or even in one. In some, the Tech Lead follows a technical track with no direct reports. In others, they also look after people.
Two factors pull the Tech Lead toward code. The first is origin: many people reach the role through technical excellence, and not always with management training. The second is expectation: one line of reasoning holds that the tech lead codes much more than the engineering manager and tends to take on the longest and most complex projects in the backlog.
The two sides, each with a cost
Neither extreme is neutral. The table summarizes what each choice usually gives and costs.
| Aspect | Codes a lot | Codes little |
|---|---|---|
| What it gains | Technical credibility, code context and extra capacity in the sprint | Time for review, mentoring, alignment and architecture decisions |
| What it costs | Review and mentoring are postponed, and the team waits for decisions | Distance from the real code, with the risk of deciding about something no longer known |
| Main risk | Becoming a bottleneck: the lead’s PR and the pending decision compete for the same time | Losing the team’s technical read and credibility with it |
Some argue that the Tech Lead’s greatest value lies in technical judgment, not typing speed. Others describe the role as splitting time between coding and leading the rest of the team, without fixing the proportion. Both readings coexist: the balance changes with context.
The turn: the useful question is how much and what kind of code
“Should they code?” hides two better questions: what kind of code and how much. Three criteria help answer them.
- Critical path. Code on the sprint’s critical path is the worst candidate for the Tech Lead, because any interruption (a review, a question, a meeting) delays the whole delivery. Spikes, prototypes and tasks that can wait work better: the work stays useful even when the Tech Lead is interrupted.
- Team size. The more people depend on reviews and decisions, the more expensive the time spent on your own code. In a small team, coding more can be reasonable. As the team grows, each hour of the lead’s code is an hour less of support for several people.
- Product stage. In discovery or early architecture, the context that comes from coding is valuable. In the scale and maintenance stage, the lead’s value tends to shift toward aligning, reviewing and anticipating problems.
Delegating is part of the answer: technical tasks handed to more experienced engineers also build experience for them.
Back to Rafael’s Thursday
Continuation of the illustrative scenario.
The following week, Rafael changes one thing: before the sprint starts, he picks a technical task outside the critical path and hands the urgent tasks to other people on the squad. He sets aside two fixed blocks for review and one for 1:1s. And he tells the team and management the agreement: this cycle, he codes little and decides fast.
His PR ships more slowly. In exchange, nobody is stuck waiting for a decision, and the 1:1 happens. The demand for delivery does not go away, but now he can answer it with an explicit agreement, not with guilt.
How Devint helps take technical leadership out of guesswork
Part of the Tech Lead’s dilemma comes from a yardstick that only sees code. Devint combines Git signals, hours, AI usage and the leadership’s structured evaluation into a DevScore with an open composition, including the Technical competence and Behavior dimensions, so that the performance conversation has criteria beyond the amount of code. See how Devint supports evaluating technology teams with criteria.
Frequently asked questions
Should a Tech Lead code?
Generally yes, but only part of the time. A common line of reasoning describes the Tech Lead as someone who splits time between coding and leading the team. The proportion depends on three factors: whether the task is on the critical path, team size and product stage. The larger the team, the less personal code tends to make sense.
What is the difference between a Tech Lead and an Engineering Manager?
The Tech Lead looks after the team’s technical direction, such as code quality and design decisions, and codes much more. The Engineering Manager focuses on people: 1:1s, hiring, careers and communication with the company. In small companies, one person may combine both roles, which becomes hard to sustain as the team grows.
How much time should a Tech Lead spend on code?
There is no established percentage, and the answer changes with the team and the product stage. A practical rule is to code outside the critical path and set fixed blocks for review, architecture decisions and 1:1s, agreeing with the team and with management on how much code the lead takes on in each cycle.
How can leadership work that does not show up in PRs be made visible?
With explicit agreements and evaluation criteria that include review, mentoring and technical decisions, instead of measuring only code delivery. Recording what was decided and unblocked in each cycle helps the conversation with management. What has no yardstick tends to lose priority to what does.