# The staff engineer book that doubles as an FDE field manual > Tanya Reilly writes about leading large, ambiguous work across teams without authority, which is daily life for an FDE inside a customer. Original: https://fdetimes.net/en/books-courses/staff-engineers-path-tanya-reilly-review/ For years, companies have rewarded their best engineers with a seat in management. Tanya Reilly opens *The Staff Engineer's Path* with exactly that observation, then spends the rest of the book mapping out an alternative. That alternative is the staff engineer path. As the book describes it, this route lets engineers contribute at a senior level, for instance by serving as a role model for others, without having to move into management. The title says nothing about FDEs. But if you think of FDE work as leading large, ambiguous efforts that cut across several teams on the customer side, with no authority to give orders, the book is close to a handbook for precisely that situation. This review reads it through that lens. ## Who is behind the book? According to the page of the distributor Ingram Academic, the book is published by O'Reilly Media, with a print date of 25 October 2022. Reilly was already known for her essay "Being Glue", in which she gave a name to glue work: the connecting and supporting tasks that help teammates and make a whole project succeed. In Reilly's view, glue work is what separates successful projects from failed ones. She does not write about the subject as an outsider. On the book's introduction page, Reilly notes that she wrote the foreword to Will Larson's *Staff Engineer* and hosted LeadDev's first Staff Engineering conference. ## Three parts, one question: how do you lead when nobody reports to you? Reilly summarises the book in three parts: big-picture thinking, executing projects and levelling up. Part one teaches you to understand your company's big picture, then to redraw that picture for others through vision and strategy. It also covers having the nerve to make the big decisions that are blocking other people. Part two deals with the large, ambiguous, cross-organisational projects that Staff+ engineers have to carry over the line, however hard they are. It shows how to get through the difficult stretches and how to manage time, energy and social capital across a project's life. Part three treats the Staff+ engineer as a force multiplier, someone who makes the whole team stronger. Direct influence comes from mentorship, sponsorship and coaching; indirect influence comes from setting an example. This part also covers improving yourself and "handing over" your own work to others. ## Applying it to a stalled decision The idea most worth taking away is the call to settle decisions that are blocking other people. Consider a hypothetical: you are deploying an agent for a customer, and for two weeks nobody has decided whether the agent should read directly from the production database or from a nightly export. The data, security and operations teams are all waiting. The way to close the question is a one-page proposal: the two options, the cost of each, the option you recommend and why. State clearly who needs to approve it and by when. A decision with an owner and a deadline is much harder to leave hanging than an open-ended discussion. There are three common mistakes. Wait for complete agreement from all three teams and the question stays open indefinitely. Decide alone and simply announce the outcome, and you alienate exactly the people who will have to run the system. The third mistake relates to the lesson of part two: spending all your social capital on small things beforehand. When you need three teams to open up data access within a week, the goodwill you have left is what decides whether they help. Once the decision is made, the idea of "handing over" your work is a reminder to record the reasoning, so the customer's team can deal with the next one without you. **Key point:** Leading beyond a single team means helping other people move faster, not doing more yourself. These ideas should be read alongside the warning in "Being Glue": Reilly writes that doing glue work too early can limit a career, and even push people out of the industry. The practical advice: when you describe connecting work on a CV or in an interview, pair it with a concrete technical result. ## In what order should you read it? For developers with 2-8 years of experience, start with the "Being Glue" essay on noidea.dog. It is short and gets you used to the author's voice. Read part one once you have a real project to measure it against. Save part three for when you start mentoring others. For another perspective, Will Larson's *Staff Engineer* covers the same ground, and it is the book Reilly wrote the foreword for. When you read FDE job descriptions, look for phrases such as "ambiguous", "cross-functional" or "stakeholder". Those are the moments when you need a story like the scenario above, with a specific decision, specific approvers and a specific outcome. The book is written for people who want to reach staff level without becoming managers. If your chosen path is working alongside customers, those skills will be tested much sooner, which is all the more reason to read it early. **Try this week:** - Read the "Being Glue" essay on noidea.dog, then list the glue work you have done in the past 3 months that nobody has recognised. - Find a technical decision in your project that is blocking other people and write a one-page proposal to settle it, with a deadline and named approvers. - Rewrite one line of your CV, changing it from a list of tasks to a description of a cross-team project you carried over the line. ## Sources - [The Staff Engineer's Path (Ingram Academic)](https://ingramacademic.com/products/the-staff-engineers-path-9781098118730) - [Staff Engineering — No Idea Blog](https://noidea.dog/staff) - [Being Glue — No Idea Blog](https://noidea.dog/glue)