From Best Engineer to First-Time Lead

TL;DR As a first time tech lead, keep taking the hardest ticket and you become the bottleneck: reviews and decisions wait on you, the team slows, and you code at night to catch up. Your output is now what the team ships. Start each day with who is waiting on you, review within one business day, and hand the work you love to someone who can own it.

Do this: Tomorrow morning, before any code, review every pull request older than one business day.

Series 2 ended in Kit's cabin, with a cup of tea going cold and an offer Pip didn't expect: senior, yes, and lead the checkout crew. Now it's week one as lead, 21:10. Six reviews are waiting. Pip is still coding.

I'll just finish the retry logic first.

Kit, passing with a plate of cake, stops at her desk. "Who's waiting on the retry logic?"

Dev Voyage: Uncharted Waters, in five parts:

1. From Best Engineer to First-Time Lead (you are here)
2. Hire and Grow Your Crew: a fair interview.
3. One-to-Ones That Matter, and Handling Conflict: when teammates clash.
4. Manage the Team: Goals, Trust and Delivery: goals and honest updates.
5. Build the Ship You Want to Sail On: Culture and Giving Back: what lasts.

Who is waiting on you?

Six reviews, Bun's unanswered question about test data, and Ollie's request for a release date.

That's the whole shift. As an engineer, Pip's output was her own code. As a lead, it's what the crew ships. Camille Fournier's The Manager's Path treats the tech lead as the first step on a path where your success depends more and more on other people's work.

The habits that made you good

First-time leads rarely fail by doing something new and wrong. They fail by continuing something old and right.

The review rule isn't Pip's taste. Google's engineering practices guide sets one business day as the maximum time to respond to a code review, because slow reviews slow the whole team.

Unblock first, code last

Pip and Kit drew her day as it should be. The rule is the order, not the percentages: other people's blockers before your own tickets.

Her own code didn't vanish. It moved off the critical path: tooling, small fixes, pairing. If it slips a week, no release slips with it.

Give away the ticket you want

The hard part wasn't handing over boring work. It was the payment retry logic, the best ticket on the board.

Pip agreed three things with Brock, then stepped back:

1. The outcome: "Failed payments retry twice, with backoff, and never charge twice."
2. The check-in: "Thursday standup, and the pull request."
3. The limits: "Ask me before touching the refund table."

When Google studied its best managers in Project Oxygen, "is a good coach" topped the list, and not micromanaging came second. Technical skill was on it too, further down.

Brock shipped the retry logic with a design Pip admitted was better than hers.

Try it

This week:

1. Write last week's calendar hour by hour, and circle every block where someone was waiting on you.
2. Review every open pull request older than one business day, first thing tomorrow.
3. Hand one ticket you'd love to do to someone else, with an outcome, a check-in and limits.

Pip's first month wasn't perfect, but no review waited more than a day. Then Kit came by: a seat on the checkout crew was empty, and the budget approved. "You're the lead. You hire." Pip has never interviewed anyone, and she knows how easy it is to hire whoever talks best. Part 2, Hire and Grow Your Crew, is how she runs a fair interview and chooses a junior called Quill.

Read this with your AI

Read the post "From Best Engineer to First-Time Lead".
1. I'll paste my calendar for last week. Mark every block where someone was waiting on me.
2. Suggest which of my current tickets I should hand to someone else, and draft the outcome, check-in and limits for it.
3. Turn my answers into a one-page lead checklist for my team.