Tech Lead

Past three engineers, a state appears where nobody owns the technical decisions. Three people solving the same problem each their own way leaves three ways of doing one thing inside the codebase. The code for loading a list is written differently on every screen, and a new hire has nowhere to ask which one to follow. None of the three ways is wrong on its own, which is what makes the situation hard to fix.

Decisions that need making get two meetings. Everyone states an opinion in the first one and it ends without a conclusion; a week later the same conversation happens again. With nobody designated to decide, the discussion stays open while the code grows in two directions.

Attaching the work to a people-management seat didn't work well either. Fill a day with one-on-ones, reviews, and hiring and there's no time left to read a design document, which puts technical decisions back in nobody's hands. Reading a design document is unglamorous work that nothing else replaces. And in an organization with only a management track, the people best at building had to stop building in order to grow.

So a seat appeared that owns technical decisions without owning performance reviews — one that keeps writing code while setting the team's technical direction.

Writing code takes less than half the day. The other half goes to reading code other people wrote, deciding what gets built how, and answering questions from people who are stuck. Seven kinds of work move through a day.

1. Code review, usually the first thing, because a backlog of reviews stops the whole team. It isn't only a pass-or-fail gate; it's where things get aligned into one way of doing them. A review that waits a day costs the team a day, not the reviewer one.
2. Design decisions. Settle the structure of a new feature and write it down on one page: what was decided, why, and which alternatives were rejected. Leave out that last part and the same discussion reopens from scratch six months later.
3. Building the hardest piece. Clear the part others would get stuck on first, then divide the rest. A payment provider integration, with traps that aren't in the documentation, is the usual example.
4. Answering questions. This one isn't on the calendar and interrupts all day, which is why many people carve out a fixed block — two hours in the morning — for focused work.
5. Breaking work down and estimating. Turn what the product manager brings into pieces of a few days each and size them.
6. Managing debt. Structural cleanup never adds a visible screen, so it always slides; a fixed share of each cycle gets reserved for it in advance. Without the reservation it competes with features and loses every time.
7. Deciding during an incident. Roll back or fix forward, called in the moment.

What the seat doesn't hold is equally clear. Performance and compensation aren't its work, and while it joins technical interviews it doesn't make the final hiring call alone. It doesn't commit to dates alone either: the estimate comes from here, the commitment is made with the product side. Estimates are technical; dates are commercial.

Four people a day. Looking at Theo at Pagedeck, they split like this.

1. The product manager. With Mia, the work is what gets built and how long it takes. Not receiving a request and returning an estimate, but working out together what gets shorter if the scope narrows.
2. The team's engineers. When a frontend developer and a backend developer attach the same feature from both sides, the format they'll exchange gets settled first. With the format fixed, neither waits on the other.
3. The designer. Whether a screen Noa drew works with the current structure, and what to change if it doesn't, gets said at the mockup stage. Saying it after the screens are finished throws the drawing away.
4. Whoever owns deployment and operations. With a DevOps engineer, the work is how a new feature will look in production. Alert thresholds and the rollback procedure get decided here.

The decision boundary blurs easily. What gets built is the product manager's call; how it gets built is this seat's. The overlap is scheduling. Whether to pay down technical debt or ship a feature first is decided by both, because what deferring will cost later is better known on the building side. When the organization grows a separate people-management seat, conversations about people move there and only technical conversations stay here.

"I'll decide this structure and write it up, rejected options included."

One person owns the decision and records the reasoning.

"Reviews are two days behind. I'll clear them this morning."

Recognizing that review delay stops the whole team.

"I can give you an estimate, but the commitment has to be made together."

Separating an estimate from a promised date.

Pagedeck's new payment work went this way. Theo spent three days on the provider integration alone first and found two constraints that weren't documented. Only then did he break the rest into tasks and divide it, and he told Mia to drop one item from the scope because of what the first week turned up.

There was a collision in review. Another engineer wrote the list-loading code in a new way, and Theo asked for it to be reverted to keep two approaches from coexisting. The new way wasn't worse; having both in the codebase was worse than either. In exchange, moving everything to the new approach went onto the next quarter's list.

The most common reading is that this goes to whoever writes the best code. Owning technical decisions makes that a natural guess. But half of any day in this seat goes to explaining decisions and building agreement. Produce the best answer alone and, if the team doesn't adopt it, the code still holds two approaches. Agreement is slower than being right, and it is the part that holds. Fill the seat on skill alone and decisions arrive as announcements, and announced decisions get re-argued in every review.

The other frequent belief is that it's a promotion. The title sits above, so it reads that way. But it's a different track from people management, and returning to pure building is common. Treat it as a promotion and it becomes a station everyone must pass through, including people with no interest in leading.