--- title: "From Best Engineer to First-Time Lead" author: "Harry" published: 2026-10-31T04:50:49.653Z updated: 2026-10-31T05:08:35.973Z category: "Career & Teams" tags: [] canonical: "https://fxblog.dev/posts/first-time-tech-lead-what-changes" --- # From Best Engineer to First-Time Lead ## Key takeaways - A lead is measured by what the team ships, not by the lead's own commits. - A common first-lead mistake is staying the best coder and becoming the bottleneck for reviews and decisions. - Answer code reviews within one business day; a team waiting on its lead is the most expensive kind of waiting. - Unblock first, build second: start each day with what others are waiting on. - Keep a small, protected slice of hands-on work, off the critical path, so your skills stay sharp without slowing the team. > **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? > **Note** > > **Pip:** ...Nobody, yet. > **Kit:** And who is waiting on _you_? > **Pip:** Everyone. Oh! 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. | Good as an engineer | Costly as a lead | Instead | | ------------------------------- | ------------------------------------ | -------------------------------------- | | Taking the hardest ticket | Critical work waits on your meetings | Hand it to someone who can own it | | Reviewing "when I have time" | Every open PR is a person waiting | Review within one business day | | Fixing it yourself, it's faster | Nobody else learns how | Explain once, let them fix it | | Coding at night to keep up | The team learns evenings are normal | Cut your own coding until the day fits | 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. > **Warning** > > Coding at night to "catch up" means your day is still built for the old job. More hours won't fix a calendar problem. ## 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. ![Pip's day as a lead: reviews and blockers first, then people and planning, her own code last; if her code is on the critical path, she hands the ticket over](https://fxblog.dev/media/01a1904b-631d-7415-ac30-917674abf591/1600) _A lead's day, unblocking first_ 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. > **Note** > > **Pip:** Brock would do it differently from me. > **Kit:** Better or worse? > **Pip:** ...Differently. > **Kit:** Then let him. If it's worse, you'll see it in review. If it's better, you learn something. 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 ```text 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. ``` > **Success** > > You know what changes when you become a lead, and how to stop being the bottleneck. Next: **Hire and Grow Your Crew**. ## FAQ ### Should a tech lead still write code? Usually yes, but less and in different places: small fixes, prototypes, tooling and reviews, not the feature everyone is waiting on. If your code is on the critical path, the team waits whenever you are in a meeting. ### What is the difference between a tech lead and an engineering manager? It varies by company. A tech lead usually owns technical direction and delivery for one team and still codes; an engineering manager owns people, hiring and careers. Many first leads do some of both, so ask your manager to write down which parts are yours.