Tech Lead: Not the Best Developer, the Owner of the Decision

From the field: 11 PRs, one approver

At the start of March the order team needed a tech lead. I managed two teams and could not keep up with technical decisions. The choice looked easy: the best developer on the team. They found the hardest bugs, they had written half of the order routing code, and everyone already asked them anyway.

When I gave them the role, I said one sentence: “The technical side is yours now.” I did not say what the technical side was or where it ended. Then I added two things. Every PR in the critical modules would need their approval. And they would write the performance notes for two junior developers, because “you know the technical side better”.

Three months later, at the end of May, this was the picture:

• Median wait for a first review was 0.6 days in February. In May it was 2.3 days.
• They spent 19 hours a week on reviews and 9 hours in meetings. That left 12 hours for their own story.
• Two other people’s work depended on that story. It rolled over for three sprints in a row.
• The team committed to 34 points and delivered 21.

They told me themselves in a one-on-one: “For three months I have not known what my job is. When I write code, the reviews wait. When I review, my code waits. I commit at 22:00 so I can approve things during the day.”

The mistake was not theirs. I had given them a title, but not a role. And I had filled the empty space from two places: some of the people work that was my job, and all of the coding they did before.

Two roles, two questions

A tech lead and an engineering manager look at the same team, but they answer different questions. Some teams put both roles in one person. That is not the problem. The problem is never talking about where the line is.

Asking the tech lead to write performance notes breaks this line in the most expensive place. The tech lead’s job in a review is to say “this approach is risky, here is why”. If the same person is also grading you that week, the comment no longer reads as a technical opinion. It reads as an assessment. A month later one of the juniors said in a one-on-one: “I cannot talk about code with them any more. Every comment feels like a grade.”

The decision rights table

In the first week of June we sat down and wrote a one-page table. The goal was not to split power between two people. The goal was that anyone on the team could answer “who do I ask about this?” at a glance.

The most useful part of the table is not the bold text. It is the “is informed” cells. The day I read “is informed” next to architecture decisions, I saw my own habit. I joined technical discussions and said the last sentence myself. When I made the tech lead’s decision, the team came to me next time, not to them.

Grey areas still come up. When the tech lead and I disagree, we use the reversibility test from the conflict post: if the decision is easy to undo, its owner decides and we move on.

The first grey area came in the table’s second week. One developer wrote error handling outside the standard in three PRs in a row. Was that a technical issue or a people issue? We agreed on this split. In review, the tech lead points to the standard, once, twice. If the same thing happens a third time, it is no longer about code. It is about behaviour, and it moves to me. When I raised it in a one-on-one, the reason was simple: they had never read the written standard, because nobody had shared the link.

How much code does a tech lead write?

Both extremes are wrong here. A tech lead who writes no code stops feeling the cost of their decisions. They set the standard but never live with it for a week. A tech lead who writes code like before lives what we lived: decisions and reviews wait for their code, and their code waits for decisions.

Whether a manager should write code is a separate question; for a manager, code is optional. For a tech lead, code is required, but its place is different. On our team it is about 40% of the week. The real rule is not the ratio. It is the position:

The test is simple: if the tech lead is off sick for a week, which story stops? If the answer is not “none”, the tech lead is on the critical path. In May the answer was “the order routing story and the two pieces of work that depend on it”. We handed that story to a mid-level developer on the team, and they paired for the first two days. How to hand work over is in the delegation post; I will not repeat it here.

We measure the ratio from the calendar, not from a guess. Every two weeks we put the tech lead’s calendar and commit history side by side and look for five minutes. In the first two weeks of June the ratio stayed at 22%, because the review load did not drop right away. It only reached 40% after the CODEOWNERS change.

A standard, not an approval gate

I was the one who set the rule “every PR in the critical modules needs the tech lead’s approval”. The intent was to protect quality. The result was two things. The first was waiting: the 11 PRs from that Tuesday morning. The second was sneakier: the team learned the tech lead’s taste, not the standard. “How should I write it so they approve?” replaced “what is the right way?”.

What we changed was one file. We wrote the standard down in two pages and gave each module its own owners. The tech lead stayed only at the boundaries. (CODEOWNERS is a file in the repository that says who must approve changes to which folder.)

# BEFORE: everything goes through one person
*                          @tech-lead

# AFTER: module owners; tech lead only at the boundaries
/order-routing/            @order-owner-1 @order-owner-2
/positions/                @positions-owner
/reporting/                @reporting-owner

# contracts between services and schema: expensive to undo
/shared/contracts/         @tech-lead
/db/migrations/            @tech-lead @order-owner-1

The logic of the last two lines: the tech lead’s approval is valuable where a change is expensive to undo. If a function name is wrong, you fix it the next day. If a contract between services is wrong, three teams feel it. We moved the approval right to the expensive places and took it away from the cheap ones.

In the first week, two module owners were hesitant to approve and still tagged the tech lead on their PRs. And the tech lead approved them; the habit was on both sides. In the second week we added a rule: the tech lead does not approve in a module they do not own, they only comment. That small rule changed more than the CODEOWNERS file.

Why not the best developer?

The best developer is the person who solves a problem best. A tech lead is the person who decides how a problem will be solved, writes that decision down and has someone else carry it out. Both can live in the same person, but they are not the same skill.

When I choose now, I look at three things:

1. Do they write their decisions down? One paragraph: what was decided, why, and why the other option was dropped. A decision that is not written down gets asked again every time.
2. Can someone else carry out their decisions? If a design works well when they write it and falls apart when someone else does, it is not a design. It is one person’s skill.
3. Can they say they were wrong? A tech lead reversing a wrong decision is rarer, and worth more, than a tech lead defending a right one.

Our tech lead was good at all three. The problem was not the person. It was that the role I gave them had no definition. Once we wrote the role on one page, they saw it too.

DECIDES        : architecture direction, service boundaries,
                 coding standards, library choice,
                 technical call during an incident
GIVES OPINION  : hiring, performance (with examples), sprint scope
STAYS OUT OF   : career conversations, pay, conflict between people

CODE           : ~40% of the week
                 NO story on the critical path
REVIEW         : contract + schema PRs required, the rest optional
WRITES         : 1 paragraph per decision (what, why, option dropped)

REVIEW OF ROLE : once a quarter, 30 min with the manager

What to track

What did not work for me

• Having the tech lead write performance notes. I said “they know the technical side better”. They do, but people do not talk about code with the person who grades them. Now the tech lead gives concrete examples, I write the review, and it carries my name.
• The rule “every PR needs the tech lead’s approval”. It did not protect quality. It tied quality to one person’s calendar.
• Saying “we will decide together”. Before the table, that was our answer for grey areas. For two weeks nobody decided how to order technical debt, because each of us waited for the other. A joint decision is often nobody’s decision.
• Taking the tech lead out of all meetings. To reduce their load, I removed them from product meetings. Two weeks later a feature was promised with a technical limit they would have known about. I needed to reduce their role in meetings, not the number of meetings.

Checklist

Conclusion

Six weeks after that Tuesday, the wait for a first review had dropped from 2.3 days to 0.7 days. The tech lead’s weekly review time fell from 19 hours to 7. The team delivered 30 of 34 committed points. The story that had rolled over for three sprints closed in the sprint it was handed over — with code they did not write, but code that followed their decision.

None of this came from a new skill. Same person, same team. The only change was that it was now written down where the role started and where it ended. In our last one-on-one they summed it up: “Now I know what my job is. I decide, I write it down, someone else builds it.”

My mistake was not choosing them. It was giving them a title and leaving the role to define itself. A tech lead’s best code is code someone else wrote that follows their decision.