What a tech lead does on a Tuesday now
The role used to be organised around interruptions: people waiting for you to unblock them. The queue has changed shape. What is waiting now is work that already merged and nobody has looked at, and a day run on interrupts will never reach it.
Ask a tech lead what they do and you will get a list of interruptions. Unblock people. Answer the question in the channel. Review the tricky change. Sit in the meeting where a decision needs someone with context. Write code in the gaps, badly, late.
That description was accurate for a long time, and it was organised around a single fact: the team’s throughput was limited by how fast people could produce working changes, and the lead’s job was to remove whatever was stopping them.
That fact has changed, and most leads’ calendars have not. My position is that the tech lead’s day now contains far less unblocking and far more pre-deciding, and that a lead still running on interrupts will be permanently behind, not because they are slow but because the queue they are servicing is no longer the one that matters.
The queue changed shape
The old queue was made of people. Someone is stuck, they ask, you answer, they proceed. It was visible, it announced itself, and it had a satisfying rhythm. You could tell you had a good day by whether the channel was quiet at six.
The new queue is made of merged changes nobody has looked at, decisions that were made by default because nobody was available to make them properly, and tickets whose acceptance criteria are vague enough that whatever gets built will be arguable.
The critical difference: the old queue interrupted you. The new one does not. Nothing merged unread will ping you. A criterion that says “improve the checkout flow” does not generate an alert. Silence used to mean the team was unblocked. Now it means nothing at all.
LinearB’s 2026 benchmarks describe the pressure from the other side. Pickup time on agentic pull requests is 5.3 times longer and median review duration is up 441.5 percent, while pull requests merged with zero review are up 31.3 percent. Work is arriving faster than anyone is deciding about it, and the excess is not queuing politely, it is going straight through.
The old Tuesday
- Servicing a queue of blocked people
- Success signal: the channel goes quiet
- The scarce thing is your time to unblock
- Decisions made when someone asks
- Code written in the gaps
The Tuesday that works now
- Servicing a queue of undecided and unread work
- Success signal: nothing merged this week that surprises you next month
- The scarce thing is your judgement, applied before work starts
- Decisions made in advance, written down
- Code read, not written, and read selectively
The four things worth a lead’s day
Here is what I would actually put on the calendar, in priority order.
Pre-deciding. Before a ticket is picked up, the decisions that would otherwise be made silently at implementation time need to be made explicitly. Not all of them: the ones where the wrong answer is expensive. Which of the three patterns. What happens in the edge case. Whether this needs a migration. Half an hour here is worth a day of review later, and it is the only intervention that reduces work rather than moving it.
Sampling. Some proportion of what merged this week was not read by anyone. Pick from it deliberately, weighted by blast radius rather than by what catches your eye, and read a few properly. The output is not a set of comments on old changes, which nobody wants. The output is a picture of where the generated work is systematically wrong, which is the input to the pre-deciding.
Arbitrating. The genuinely new activity. Two plausible implementations exist, both pass, both are defensible, and someone has to choose. This used to be rare because producing two implementations was expensive. It is now cheap, so the choice arrives regularly, and it is a judgement call about the system’s future that no test can settle.
Holding the line on what is not automated. Every quarter there is pressure to expand what runs without a human. Some of it is right. The lead is the person who knows which subsystem’s failure mode is silent and slow, and that knowledge is not written down anywhere it could be inferred from.
What this means for how leads are assessed
The uncomfortable consequence: most of the visible signals of a good tech lead now measure the wrong queue.
Responsiveness in the channel. Number of reviews. Being the person everyone asks. Those all measure interrupt-servicing, and a lead who optimises them will do it by spending less time on the four activities above, because those are invisible and produce no immediate gratitude.
If you manage tech leads, the question worth asking in a one-to-one is not “is the team unblocked”. It is: what merged this month that you would not have approved, and how did you find out?
A lead who cannot answer that has not failed. They have been rewarded, consistently, for watching the other queue.
Where this breaks down
“Pre-decide the important things” assumes you can tell which are important. In practice the ticket that causes the incident is usually the one that looked routine. Spending your best half hour on the two tickets that looked risky is a strategy with a known failure mode, and the honest alternative, pre-deciding everything, does not fit in a week. I do not have a clean answer to this beyond letting the sampling tell you where your judgement about risk has been wrong.
This describes a team that already has volume. If your team merges eleven changes a week and a human reads all of them, none of this applies and the interrupt-driven model is still correct. The advice inverts somewhere around the point where nobody can read everything, and where that point sits depends on your team more than on the technology.
Sampling is a weaker control than it sounds. Reading three merged changes a week from a population of two hundred tells you very little with any statistical confidence. I am recommending it because the alternative is reading none, not because it is rigorous. Anyone presenting sampling as coverage is overselling it, including me if I am not careful.
Leads who stop writing code lose the thing that made them useful. The failure mode of every “the senior role becomes judgement” argument is a lead who has not opened the codebase in eight months and whose pre-decisions are therefore fiction. Reading code closely is part of this. Writing some is probably necessary too, and the version of this article that says leads should stop implementing is a version I would push back on.
And the interrupt queue is not decoration. A team whose lead becomes unavailable in favour of deep work on invisible queues will route around them, make worse decisions faster, and be perfectly happy about it for about a quarter. Availability is a real part of the job and I have described it here as an alternative to the important work, which understates how much of the important work happens inside it.
The takeaway
The tech lead role did not get smaller and it did not become management. The queue changed from people waiting on you to work that already happened without you, and only one of those queues will interrupt you.
Spend the day on what does not announce itself: deciding in advance, sampling what merged unread, arbitrating the choices that are genuinely open, and defending the boundary of what stays human.
If you take one thing into next week: block the first hour of Monday, and use it to read three changes that merged without a human review, chosen by blast radius. Do it four weeks running before you decide whether it was worth the hour.