# Camille Fournier's The Manager's Path: a book for FDEs about to step back from the keyboard > For anyone hoping to lead an FDE team, the hardest skill may be knowing when to stop coding, not getting better at it. Original: https://fdetimes.net/en/books-courses/managers-path-camille-fournier-fde/ Every FDE who wants to move up should tape one number to their monitor: 30%. In The Manager's Path, Camille Fournier cites Patrick Kua's definition of a tech lead as someone who spends **at least 30% of their time writing code with the team**. That is a minimum, not a maximum. Say you are the strongest developer on the team and have just been asked to lead three people on a customer deployment. The number does not stop you coding more than that. But Fournier is clear that a tech lead's real job is knowing when to step away from code and deal with what the whole team needs. That is why the book is worth reading early. ## A book arranged as a ladder The Manager's Path, subtitled *A Guide for Tech Leaders Navigating Growth and Change*, was published by O'Reilly Media in 2017 and runs to 244 pages (ISBN-13: 9781491973899). It is easy to use because of how it is organised. Each chapter covers one level of engineering management, from the simplest form, mentoring, up to the role of CTO. That structure means you can use the book as a map instead of reading it cover to cover. Work out which level you are on, read that chapter, then read the next one up to see what the following job will ask of you. For FDEs the map is especially useful, because the path to promotion is often unclear. Today you may be the only person writing integrations at one customer. Six months from now you could be leading a small group deploying to several customers at once. The book was not written for FDEs, but the levels it describes match that journey closely. ## Thirty per cent is a floor, not a ceiling Kua's benchmark keeps tech leads close to the code. For FDEs it matters more than in many other roles, because you are usually the first person a customer asks when they want to know whether something technical can be done. An FDE tech lead who has stopped coding entirely will struggle to answer "can this be done in two weeks?" with any confidence. Picture your first week leading three people at a logistics customer: 40 hours. One sensible split: 12 hours coding with the team, taking the hardest part of the data pipeline or pairing with whoever is stuck; 8 hours on code review and unblocking; 8 hours with the operators, learning their processes and running demos; 6 hours on architecture decisions and planning; 6 hours on 1-1s and mentoring. Twelve hours out of 40 is exactly 30%. Now flip it: you write 30 hours of pipeline yourself. On paper you are still above Kua's mark. But that leaves 10 hours for everything else, so reviews pile up, nobody talks to the operators, and two teammates sit waiting. This is the failure Fournier warns about: refusing to step away from code to balance your own technical commitments against what the team needs. ## The hardest skill is letting go of the code Fournier writes that an effective tech lead must be willing to step away from the code and find a way to balance their technical commitments with the needs of the team. This is the hardest change in mindset, because the skill that got you the job is the one you now have to use less. **Key point:** Leadership starts when you are willing to let go of the keyboard at the right moment. In FDE work the temptation is even stronger. The customer is in a hurry, the deadline is close, and you know you can fix the bug faster than anyone. But every time you dive in yourself, a teammate loses a chance to learn, and you lose an hour that should have gone on work only you can do: unblocking people who are stuck, and agreeing with the customer what gets done first and what waits. A practical tip: when writing your CV or preparing for interviews for an FDE lead role, do not just describe what you built. Have a story ready about a time you deliberately handed a hard task to someone else, how you supported them and how it turned out. That story shows you have started the shift Fournier describes. ## Which chapters deserve close reading depends on where you stand A practitioner's review from August 2017 called this a good book on the parts of leadership specific to software engineering. The same reviewer argued that its greatest value lies in the sections on managing a team and managing multiple teams, and suggested skimming the early chapters. That advice suits people who have already led teams. But if you have never formally been a tech lead, the early chapters on mentoring and tech leadership deal with exactly what you are about to do. Read them closely; do not skim. At the level of managing multiple teams, the book describes managers who no longer write production code regularly but keep their technical judgement sharp through code review. Imagine you are responsible for two FDE groups at two customers. Your job shifts to helping each tech lead below you keep pace, and to telling what matters apart from what is merely urgent. The CTO level at the end of the book is further off still, and is best reread once you are getting close. ## Who should open this book first The book suits three groups best: FDEs who have just been asked to lead a small group at a customer; senior engineers weighing the individual-contributor track against management; and people hiring or interviewing for FDE lead roles who want a shared vocabulary for assessing candidates. The most effective way to read it is alongside your actual calendar. For each chapter, compare what the book describes with your past week: how many hours you coded, how much work you handed off, whether anyone on the team learned something from you. A 244-page book will not turn you into a leader. But it shows you in advance what the next rung looks like, and that stepping up usually starts with letting go of some of the work you do best. **Try this week:** - Log your working hours for five days, work out what share you actually spent coding with the team, and compare it with the 30% mark. - Pick one technical task you still hold on to because 'I'm faster at it', hand it to a colleague and only review. - Read the tech lead chapter first, then write a one-sentence summary of each later chapter before moving on to the next. ## Sources - [The Manager’s Path by Camille Fournier](https://www.welcometothejungle.com/en-GB/articles/btc-manager-path-camille-fournier) - [Open Library record for ISBN 9781491973899 (The Manager's Path)](https://openlibrary.org/isbn/9781491973899.json) - [The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change](https://sirupsen.com/books/the-managers-path/)