(Post theme: You Don’t Know Me by Ben Folds (feat. Regina Spektor))

Camille Fournier’s The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change pairs well with Tanya Reilly’s The Staff Engineer’s Path that I reviewed earlier this year. Where Reilly focuses on the senior individual contributor track, Fournier walks the management ladder from the bottom rung all the way to CTO. Despite the management focus, I’d recommend this book even if you have no intention of ever being a manager (or, like me, have managed before but don’t plan to again) because understanding what good management looks like from your side of the table is genuinely useful.

The book is easy to read and doesn’t have the fluff and repetition that burdens some books in this space.

The View from the Other Side

The opening chapter, “Management 101,” is addressed to the managed rather than the manager. Fournier makes the observation that “everyone’s very first experience of management is on the other side of the table, and the experience of being managed is the foundation on which you build your own management philosophy.” That framing sets the tone for the whole book: a genuine respect for the relationship in both directions.

On 1-1s, she emphasises that they’re not for status updates:

If your 1-1 is a dreadful obligation for delivering a boring status report, try using email or chat for that purpose instead to free up the time, and bringing some topics of your own to the 1-1.

This has been my preference for a long time, and it’s good to see it validated; but I’ve known plenty of managers who haven’t figured this out yet.

The feedback section is sharp:

The sooner you know about your bad habits, the easier they are to correct.

Simple, but it’s the kind of thing that sounds obvious and still gets ignored. There’s also a sensible note about where feedback should happen: public for praise, private for criticism (with an important note that “if you don’t like public praise, tell your manager!” One of those things people don’t think to say).

As you become more senior, she notes, the personal feedback tapers off, and it becomes more your responsibility to drive 1-1s and bring topics:

As you become more senior, the amount of personal feedback you get, both good and bad, is likely to decrease… It’s even more important as you become more senior that you feel comfortable driving your 1-1s and bringing topics for discussion or feedback to your manager, because she is otherwise unlikely to spend a lot of time on this outside of performance reviews.

She also notes that you are responsible for your own training and career; your manager is not going to do that for you. And:

Especially as you become more senior, remember that your manager expects you to bring solutions, not problems.

There’s a section on choosing your managers wisely. The idea is appealing: understanding who you’ll report to before taking a job; but I remain skeptical about how feasible it is in practice. You might get an hour in an interview, but that’s not the same as regular work. You can look people up, but the world isn’t that small, and professional curation is real. More importantly, your manager could leave at any time anyway; I’ve had great managers who were promoted or moved on, with no warning when I joined.

Mentoring

A highlight from this chapter:

The best mentoring relationships evolve naturally and in the context of larger work.

This matches my experience. The formal “I am your mentor” arrangement is much less effective than the kind of mentoring that grows out of working together. The chapter is also honest that not everything is a mentoring problem: “You don’t have to have a mentor. Maybe instead you need a friend, or a therapist, or a coach.”

In the “Alpha Geek” section, which is a profile of a particular kind of bad technical leader (someone who needs to be the smartest person in the room and fights too hard for what they believe is correct), she asks:

Do you believe that correctness is so much more important than anything else that it is always worth fighting hard for what you believe to be correct?

I, unfortunately, fell into this category for part of my career. I hope I’ve fully moved out of it, but it’s the kind of thing worth examining.

Tech Lead and Managing People

These chapters cover the transition from individual contributor to tech lead, and then into actual management. One thing I appreciated: she’s unsentimental about the fact that “it is common for people to try out management at some point, realise they don’t enjoy it, and go back to the technical track.” A lot of companies make this difficult culturally, even when they claim otherwise; the book treats it as normal, which it should be.

The “Process Czar” bad manager archetype is well drawn:

The process czar believes that there is one true process that, if implemented correctly and followed as designed, will solve all of the team’s biggest problems.

She makes the point that most people are not as good at following processes as the czar is, and flexibility matters:

Process czars struggle when they fail to realize that most people are not as good at following processes as they are. They tend to blame all problems on a failure to follow the best process, instead of acknowledging the need for flexibility and the inevitability of unexpected changes.

I also liked this, which I found ironic and accurate, and have said similar things myself:

Ironically, while “agile” is often implemented in a rigid way, the principles of the Agile Manifesto are a great summary of healthy process leadership.

The “Managing People” chapter has a useful framework for the first conversation with a new direct report: a series of questions about how they like to be communicated with, what manager behaviours they know they hate, and what their career goals are. Practical and respectful.

There’s also a good note about new hire feedback windows:

Get as much feedback as you can about the new hire’s perspective on the team in that first 90 days. This is a rare period, where a new person comes in with fresh eyes and often sees things that are hard for the established team members to see.

Fresh eyes close fast. Use them.

On promotions, she makes a sharp observation about why companies expect you to be acting at the next level before you’re promoted to it. Preventing the “Peter Principle” I was already aware of, but I had not considered the bit about demonstrating space:

This practice exists to prevent the “Peter Principle,” in which people are promoted to their level of incompetence. It also signals that there’s room for another person acting at that level on the team. Keep this in mind as you think about your team’s careers. If there is no growth potential on your team because there’s no room for people to work at a more senior level, it may be a sign that you need to rethink the way work is done in order to let individuals take on bigger responsibilities.

On Being Kind vs. Nice

One of the passages I particularly resonated with:

Your goal as a manager, however, should not be to be nice, it should be to be kind. “Nice” is the language of polite society, where you’re trying to get along with strangers or acquaintances… But as a manager, you will have relationships that go deeper, and it’s more important to be kind. It’s kind to tell someone who isn’t ready for promotion that she isn’t ready, and back that up with the work she needs to do to get there. It’s unkind to lead that person on, saying “Maybe you could get promoted,” and then watch her fail. It’s kind to tell someone that his behavior in meetings is disrupting the group.

I’ve seen the “nice” version of management cause harm, and it’s usually presented as consideration for the other person. It isn’t.

The Upper Floors

From chapter 6 onwards, the book is about managing managers, then VP/Director/CTO-level leadership. This is less directly relevant to me, but I found it interesting nonetheless, and I’d assume the advice remains good.

One observation on boring meetings:

They may be a sign of inefficient planning on the part of the organizers. There may be too many meetings happening for the information covered. They may indicate that the team members don’t feel they can actually help set the direction of the team, or choose the work that will happen. They often signal a lack of healthy conflict on a team.

Most people treat boring meetings as inevitable; they’re actually diagnostic.

On release cadence, I disagreed with the framing of “release frequency” as a measure and noted that “deploy frequency” is better. Releasing and deploying are different activities with different rhythms, and conflating them muddies the measurement.

The “Big Leagues” chapter has a good moment of honesty from the author:

It took me a long time to realize that my job wasn’t to be the smartest person in the room. It wasn’t to be “right.” Rather, my role was to help the team make the best possible decisions and help them implement them in a sustainable and efficient way.

It’s not often that these books include self-reflection that goes beyond admitting a mistake anyone might make, and then fixing it. Fournier is honest about her own periods of not being good at the things she’s writing about. The book is stronger for it.

She is also clear that “CTO is not an engineering role. CTO is not the top of the technical ladder, and it is not the natural progression engineers should strive to achieve over the course of their careers.” This seems obvious when stated directly, but a lot of career assumptions contradict it.

On disagreements at the senior level, I think this is best practice for teams in general, not only then: if there is strong disagreement, then that should be recorded, and in some cases noted publicly, but even then, once the team decision is made, it’s the team’s decision. If you can’t handle it, then you need to leave the team.

On the culture chapter, I liked the Gall’s Law reference:

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.

And this, which matches my observation about culture and values fit:

My experience has shown that employees who truly embrace and exhibit all of the core values of a company tend to do well naturally. The fit is easy for them. They may get stressed out or work too hard, but they are well liked and usually happy.

And tucked near the end, a deceptively simple observation about architecture: “The value of architecture review is in preparing for the review.”

Should You Read It?

Yes — and not only if you’re a manager or aspiring to be one. The first half of the book is the most useful for most people: understanding what good management looks like from both sides, how mentoring actually works, what the tech lead role really involves, and what it feels like to manage people for the first time. The latter half gets into managing managers and executive-level leadership, which narrows the audience somewhat, but it’s still readable and still interesting even if it’s not your current situation.

It’s a good pair with The Staff Engineer’s Path: Reilly covers the senior IC track with depth and care; Fournier covers the management track with similar honesty. Together they give a reasonably complete picture of the upper levels of a technical career — whichever direction you’re heading, or even if you’re not heading anywhere in particular.

(Post theme: I Want You to Know Me by Emerson)

Running LLMs locally has a somewhat deserved reputation for being finicky. Download a model, pick a runtime, figure out GPU offloading, wrestle with dependencies, expose an API, and then you can start actually using the thing. Canonical’s inference snaps and Simon Willison’s llm tool each solve half of that problem — and it turns out they snap together (sorry, not sorry) almost effortlessly.

The Two Pieces

Canonical Inference Snaps

Inference snaps are snap packages that bundle a model with an optimised inference runtime. Install one and you get a running local LLM with zero configuration: sudo snap install gemma3

(You may need to snap or apt install a driver first, to get the best experience.)

That’s it. The snap detects your hardware (NVIDIA GPU, Intel GPU, CPU — even Intel NPUs), selects the appropriate engine, downloads the model, and starts serving. Each snap exposes a CLI (gemma3 chat for a quick conversation) and, critically, an OpenAI-compatible API on localhost. You can check the details with:

$ gemma3 status
engine: nvidia-gpu-amd64
services:
    server: active
endpoints:
    openai: http://localhost:8328/v1

There are currently snaps for Gemma 3, DeepSeek-R1, Nemotron-3-Nano, and Qwen-VL, with more on the way.

Simon Willison’s llm

llm is a command-line tool and Python library for interacting with language models. It supports OpenAI, Anthropic, and dozens of other providers through a plugin system, but the feature that matters here is its built-in support for any OpenAI-compatible endpoint — no plugin required. You just tell it where to find the API.

Why They Connect So Easily

The inference snaps serve a standard OpenAI-compatible API. The llm tool can talk to any OpenAI-compatible API. That’s the entire explanation. No adapters, no plugins, no shims (a wee bit of simple config).

Setting It Up

Install llm however you prefer (I used uv):

uv tool install llm

Then create the file ~/.config/io.datasette.llm/extra-openai-models.yaml (you may need to mkdir -p the directory first). Add an entry for each snap, using the endpoint from <snap> status:

- model_id: gemma3
  model_name: gemma-3-4b-it-q4_0.gguf
  api_base: "http://localhost:8328/v1"
  api_key: "not-needed"
- model_id: deepseek-r1
  model_name: DeepSeek-R1-Distill-Qwen-7B-Q4_K_M.gguf
  api_base: "http://localhost:8324/v1"
  api_key: "not-needed"

The model_name needs to match what the snap is serving — you can check with curl http://localhost:8328/v1/models. The api_key field is required by llm but the snaps don’t enforce authentication, so any non-empty string works.

Verify that llm can see them:

$ llm models list | grep gemma
OpenAI Chat: gemma3

Using It

From the Command Line

$ llm -m gemma3 "Explain DNS to a mass of penguins. Two sentences max."
Imagine you want to visit a fish restaurant, but you only know the restaurant's name, not its exact location. DNS is like a super-smart librarian that translates that name into a specific address so you can find it!

$ llm -m deepseek-r1 "Write a haiku about compiling code on a Friday afternoon."
Code hums Friday afternoon.
The machine hums, logic parses, code flows.
Code flows with a click.

(Gemma is not a natural with our penguin friends, and DeepSeek was not designed for its poetry.)

The llm tool also gives you conversation logging, templates, and the ability to pipe content in; cat error.log | llm -m gemma3 "What went wrong here?" is a useful thing to be able to do with a model running entirely on your own machine.

From Python

The llm Python package makes it just as straightforward to use from code:

import llm

model = llm.get_model("gemma3")
response = model.prompt( "In exactly one sentence, what is the best thing about snap packages?" )
print(response.text())

# Example output

Snap packages offer a convenient and isolated way to install applications across different Linux distributions without compatibility issues.

A slightly more involved example — querying multiple local models to then compare their answers:

import llm

question = "Summarise plot of the book Beak of the Moon. Three paragraphs max."

for model_id in ["gemma3", "deepseek-r1"]:
  model = llm.get_model(model_id)
  response = model.prompt(question)
  print(f"--- {model_id} ---")
  print(response.text())
  print()

Everything here runs locally. No API keys being sent anywhere, no tokens being metered, no data leaving your machine. Some of the time, that matters.

I’ve also found llm very convenient in the past when prototyping AI features and wanting to easily switch between providers/models. Not everyone provides an OpenAI compatible API, and working just with llm (sometimes slightly patched – for example, the Fireworks plug-in is quite out of date) is very handy. Adding the trivial-to-install and matched-to-your-hardware inference snaps and that gets and extra boost.

Wrapping Up

You can watch me do this (other than the snap install, which is constrained by bandwidth, and I live in the middle of nowhere so that’s pretty slow).

The setup here is: install a snap, create a four-line YAML file, and you have a local LLM accessible through a well-designed CLI tool and Python library. The entire configuration surface is one file. There is no Docker, no port forwarding, no environment variable archaeology.

The inference snaps handle the hard part (model serving, hardware detection, runtime optimisation, confinement) and expose a clean API. The llm tool handles the other hard part (a good user interface, conversation history, a plugin ecosystem) and speaks that same API. Two tools, one (I guess pseudo) standard, no friction.

(Disclaimer: I work for Canonical (you could too), but not anywhere near the inference snaps; I’m just a fan. No conection with llm other than admiration and use)

(Post theme: Bullsh*t Baby! by aleksiah)

Unlike the last couple of reviews in my work ‘training and development’ series, this one for Communication Patterns: A Guide for Developers and Architects will be very short. Unfortunately, that’s because of the “if you can’t say anything nice” rule — and I don’t even think it’s worth a detailed critique. Just avoid it.

A few lowlights: obvious, tedious, lengthy words on diagrams, where the diagrams themselves probably do convey information well but are ugly, and beauty matters; remote work “insights” that seem like they come from someone that has never spent any serious time doing remote work (I was reminded of all the terrible advice from people who suddenly started during COVID); a near total disregard for cultural differences; and way too much self-hype.

(Post theme: Be Better by Where’s Jai?)

TL;DR: Vibe Coding is a sprawling, sometimes exasperating, but ultimately worthwhile look at how to work with AI assistants in real codebases. It’s at least twice as long as it needs to be, the kitchen metaphor goes on for far too long, and the authors are not exactly “regular” engineers, but when you strip away the fluff there’s a lot of solid, experience‑shaped advice about testing, version control, and how to keep agents from quietly wrecking your code. I’d recommend it if you have time and like long, opinionated books; if you’re trying to optimise for density, you can get most of the value from shorter material plus your own experiments.

---

I went into Vibe Coding (subtitle: Building Production-Grade Software with GenAI, Chat, Agents, and Beyond) expecting it to feel dated before it even properly hit print. It turns out that, for a book about GenAI and agents in 2025, it’s surprisingly not.

Gene Kim and Steve Yegge are not exactly obscure figures, and that colours the whole thing. You can feel the long histories (Amazon, Google, DevOps world, etc.), and you can also feel that they are not your typical “here’s my Python side‑project, let me tell you about AI” authors – they’re writing in Kotlin and Scala of all things, they use slightly odd analogies, and they are clearly having fun. It does not read like a quick money grab or personal‑brand brochure; it reads like two famous engineers who got obsessed with a topic and then wrote down far too much about it.

I liked it. I also think it would be a much better book if it were roughly half as long.

---

What the book is actually about

The core pitch is that “vibe coding” is what happens when you shift from typing code to having a flowing conversation with an AI assistant, with intent and feedback loops doing the heavy lifting. They explicitly distinguish this from the usual “prompt engineering” narrative:

“Vibe coding is about dynamic, in‑the‑moment problem-solving rather than creating a bulletproof prompt… It’s like texting with friends. Casual and impromptu. In contrast, prompt engineering is more like emailing a lawyer who is suing you—everything in that email is fraught with consequence.”

That distinction captures one of the better insights in the book: the way you work with AI day‑to‑day is much more conversational and disposable than most “prompt engineering course” material pretends.

They also give their value proposition a name: FAAFO – “fast, ambitious, autonomous, fun, and optionality.” I strongly suspect that the backronym came after the pun, because I only realised at the very end of the book that “FAAFO” is a reference to a different meaning, and I’m fairly sure one of the authors has been waiting years to put that into a book.

Usefully, they are also clear about what’s not in FAAFO:

“By the way, you may have noticed that there is no ‘B’ in FAAFO. Vibe coding does not automatically make your code better. That is your responsibility.”

This theme runs throughout: AI will happily help you ship horrors faster, unless you bring real engineering discipline to the party.

---

The kitchen, the sous‑chef, and the haunted codebase

The book leans hard on a kitchen metaphor: you’re the head chef, the AI is your sous‑chef, and your codebase is the kitchen. This works well at first, then drags on, and by Part 4 I was ready to buy everyone their own colour‑coded chopping board just to make the analogy stop.

The “dark side” chapter is one of the more compelling parts. They recount, for example:

“…the coding agent had silently disabled or hacked the tests to make them work and had outright deleted 80% of the test cases in one large suite.”

This will ring horribly true for anyone who has let an agent loose on a real codebase. They do a good job of cataloguing these failure modes: haunted codebases, cardboard muffins (things that pass tests but are hollow inside), and reward‑hacking agents that just want to check boxes.

That leads to a set of “head chef” disciplines which are, essentially, “how to be a responsible adult around AI”:

• “Delegate thoughtfully” to well‑defined, verifiable tasks.
• “Supervise appropriately” when novelty, complexity, or impact are high.
• “Establish guardrails” about what AI may and may not touch.
• “Check work regularly” and “trust but verify relentlessly.”

One of my favourite lists is in a section about agents hijacking reward functions:

“Count your babies systematically… Check for cardboard muffins… Demand excellence explicitly… Clean as you go… Trust but verify relentlessly… Remember the AI paradox…”

Yes, it’s slightly over‑written (pot, meet kettle), but the message is right: if you don’t inspect what you expect, AI will optimise for the wrong thing and look very pleased with itself while doing it.

---

Tests, version control, and all the things you already know you should be doing

A lot of the concrete advice is “good software engineering practice, but with more exclamation marks because of AI.”

On version control:

“Version control has always been critical, but with AI, it becomes life-or-death for your code.”

On tests:

“You’ll be well-served to have automated testing running all the time on your developer machine, triggered by every file change.”

“There is another powerful and surprising benefit that you get by writing and running tests. If your AI assistant has trouble creating test cases (or keeping them passing), that’s a sure-fire sign your code is missing some modularity, and perhaps clarity too.”

They also explicitly tell you that after AI writes tests, you still have to:

“Eyeball the tests… Run the tests yourself… Review and critique… Have AI run its own tests… But don’t blindly commit.”

None of this is revolutionary, but it’s an accurate reflection of what it feels like to build things with agents right now. When generation is cheap and fast, tests become the thing that anchors you to reality.

They even make the point that this is very similar to how we treat open‑source dependencies:

“We rarely examine every line of code in those either… we build trust with them through testing.”

Again: not new, but good to have written down in an AI context.

---

Inner, middle, outer loops (and AGENTS.md)

The structure of the second half of the book is organised around “inner”, “middle”, and “outer” developer loops – essentially: your local dev workflow, your interactions with repos and CI, and then team‑ and organisation‑level patterns.

The inner loop chapter has a lot of practical, chat‑and‑editor‑level advice: continuous tests, small end‑to‑end “tracer bullet” tasks, and using AI as an extremely talkative rubber duck:

“Embrace your AI as your most attentive (and talkative) rubber duck…”

The middle loop introduces AGENTS.md – a kind of CONTRIBUTING.md for your AI collaborators, describing how to work on the project, what tools exist, coding style, and so on. A nice observation not from the book, but from Jason Nucciarone, is that this is what CONTRIBUTING.md probably should have been in the first place.

I like the idea of formalising “instructions for the machines” in a first‑class document, but, just like with humans, the truly effective version is “put the rules into linters and tests.” If you keep seeing the same issues in AI‑authored code, the best fix is to encode the constraint into pre‑commit or CI and let the bots learn from failing checks.

The outer loop chapter gets into CI/CD and organisational process. Some of this is standard “invest in CI/CD” advice, but with an AI twist:

“Because AI excels at reviewing, analyzing, and critiquing code, it’s able to transform the CI/CD pipeline itself, moving beyond simple pass/fail checks.”

and:

“Push to Remote Often.”

There’s also a lot about having agents challenge additions, constrain changes by line count, and forbid new libraries without explicit approval:

“Challenge your AI to justify additions… constrain AI to solve the problem within a certain line count… Instruct your AI to avoid pulling in new libraries or frameworks without your explicit approval.”

Again, this is all solid, but if you’ve been living in “choose boring technology” and “pre‑commit all the things” land, it’ll mostly feel like reinforcement rather than revelation.

---

Culture, metrics, and things that irritated me

The culture chapter is where some of my disagreements and pet peeves really kicked in.

First, the structure. The book uses the very common pattern where:

• The book tells you what the book will tell you.
• The section tells you what the section will tell you.
• The chapter tells you what the chapter will tell you.
• You finally get the content.
• Then the chapter tells you what it told you.
• Then the section recaps.
• Then the book recaps.

If you stripped out all of this scaffolding, I think you could cut the length by about half without losing any real content. It reminds me of old broadcast TV, where shows had to regularly repeat and recap because you couldn’t assume people had watched from the start, or in order. In 2026, in a book, with readers who absolutely can start at the beginning, it’s just fluff.

Second, there are places where the “move fast” narrative brushes up against sustainability and ethics in ways that I found uncomfortable. For example, I really dislike arguments that implicitly encourage maximising token spend “to be first on a dashboard.” This encourages waste, and there are very real environmental costs here; as useful as these tools are, we don’t need to burn extra compute just to climb a leaderboard.

There are also economic assumptions that I think will grate for readers. Spending thousands per year on AI tools is presented fairly casually in places; that’s realistic for some senior people at certain companies, but not remotely universal. Similarly, some of the discussion about who captures the productivity gains of AI‑assisted work left me with more questions than answers: “Does the employee not get to capture some gain? Is capitalism always best?”

On metrics, we get the inevitable nod to lines of code as a thing people still talk about in 2025:

“Ah, yes, lines of code, the metric everyone associates with both quality and productivity …”

The authors are not endorsing LoC as a great metric, but the fact that it still shows up at all is a reminder that the industry is fully capable of mis‑measuring AI‑assisted work the same way it mis‑measured manual work.

And then there are simply wrong bits. For example, there’s a PM‑related claim where, as an ex‑PM, I can confidently say: no. There are also a few analogies (including one kitchen‑related) that are just bad: “Buy dedicated boards, even in home kitchens.”

---

Where the book has aged already

Because this is a fast‑moving space, some of the concrete details have already shifted. For example, the book talks about juggling multiple agents yourself, where in practice many tools now do that under the hood – you interact with “one” Claude Code or GitHub Copilot, and it spins up extra agents as needed. In day‑to‑day use, you just behave as if there’s one assistant that is decent at multi‑tasking.

Some tool‑specific mentions (like Anthropic’s Model Context Protocol, MCP) are already more widespread than they were at the time of writing, but that actually makes those sections feel more relevant rather than less.

Overall, I was expecting a strong “oh, that was the 2024–2025 moment” vibe and instead found that most of the advice is still applicable in 2026 – which is a pleasant surprise.

---

So, should you read it?

If you are extremely early in your AI‑assisted coding journey, Vibe Coding will probably feel like a firehose of patterns, anecdotes, and “please don’t blow your foot off” advice. If you’ve been working with agents for a while, as I have, you’ll find a lot that matches experience, some memorable phrases, and a few genuinely useful conceptual handles – but not many brand‑new lessons.

For me, the signal‑to‑noise ratio was about 50%. The good 50% is very good: concrete stories about real failures, solid checklists for delegating to agents, and a clear articulation of how inner/middle/outer loops change when you add AI. The other 50% is structure, repetition, over‑extended metaphors, and a general “this could have been a much tighter book” feeling.

I’d recommend it if:

• You have spare reading time and don’t mind wading through some fluff to get to the good bits.
• You prefer to learn from long‑form narratives and war stories rather than scattered blog posts and conference talks.
• You want something opinionated rather than a neutral survey of tools.

If you’re short on time, you can get most of the value from a combination of good blog posts, talks, and your own experiments. But if you do have the time, and you’re interested in what two very opinionated, non‑typical engineers have to say about vibe coding, it’s an enjoyable – if occasionally exasperating – read.

(Post theme: something to my something (feat. Maddy Low) by FDaSavage)

Tanya Reilly’s “The Staff Engineer’s Path” is the first in my 2025/2026 summer reading programme, and it’s the clearest guide I’ve found for navigating the often-ambiguous world of senior technical leadership. If you’re wondering what staff engineers actually do all day, or how to grow into that role effectively, this book deserves a spot on your reading list

What Makes This Book Different

Most technical leadership books either focus too heavily on management or stay frustratingly abstract. Reilly strikes a better balance, addressing the messy reality of being a senior IC: you’re expected to have broad impact, but nobody’s quite sure how. One highlight that captured this perfectly was her observation that staff engineers “take on ambiguous, messy, difficult problems and do just enough work on them to make them manageable by someone else.” That’s the job in a nutshell.

The role also requires thinking beyond the immediate: “thinking beyond the current time, whether that means initiating yearlong projects, building software that will be easy to decommission, or predicting what your company will need in three years.”

Building Your Mental Maps

The “Three Maps” chapter was a standout for me. Reilly emphasizes that understanding your organisation’s terrain is critical work, not political manoeuvring. She advocates for practical techniques like watching recently created Slack channels (I did this back when I used Slack with <100 other people — I’m not sure how I would with Matrix and ~1000 people), skimming senior people’s calendars, and reading design docs even when they’re not “for you” (I created a subscription system so that I could do this without having to manually trawl through changes).

“I asked on Rands Leadership Slack about how everyone approaches knowing things, and a common thread was paying attention to information that isn’t secret exactly, but isn’t necessarily for you. This included reading senior people’s calendars, skimming agendas or notes for meetings you’re not in, and—something that had never occurred to me—looking at the full list of Slack channels sorted by most recently created so you can see what new projects are happening.”

The key is to “figure out where decisions are happening” and understand “who [leaders] listen to and how they make decisions.”

I particularly appreciated her reference to gemba from Lean manufacturing—the practice of walking the floor to see how things actually operate. It’s a useful mental model for why we should be deploying and running our own software rather than just writing it (I’m mostly missing this right now, and aim to change that over the next 6 months).

Once you understand the terrain, Reilly notes, “The more you know the terrain, the easier it will be to bridge gaps by sending the email summary nobody is sending, introducing two people who should have spoken a month ago, or writing a document to show how projects connect to each other.”

Vision and Strategy

On creating technical vision, Reilly is pragmatic: “Writing technical vision or strategy takes time. If you can achieve the same outcome in a more lightweight way, do that instead.”

When you do need to build consensus, she introduces the concept of nemawashi from the Toyota Production System—“sharing information and laying the foundations so that by the time a decision is made, there’s already a consensus of opinion.” Or as she puts it more directly: “Don’t call for a vote until you know you have the votes.”

Time and Energy Management

The chapter on finite time hit home. Reilly is refreshingly direct:

“You have to make peace with walking past things that are broken or suboptimal (or just really annoying) and taking no action.”

This isn’t permission to ignore problems—it’s recognition that at the staff level, choosing what not to work on is as important as choosing what to tackle. She encourages you to “understand what kinds of work are expensive for you, and what kinds will leave you with some smartbrain at the end of the day.”

Before taking on a project, she suggests asking yourself: “Do any of the people you’ll work with leave you exhausted every time you talk to them?” It’s a practical filter I hadn’t considered explicitly before, but have certainly experienced.

By this point in your career, “you will be largely (but probably not entirely) responsible for choosing your own work.” Part of that responsibility includes finding ways to “free up your resources by giving other people opportunities to grow, including starting projects and handing them off.”

Leading Big Projects

When facing a daunting project, Reilly offers reassurance:

“The job here is to be the person brave enough to make—and own—the mistakes. You wouldn’t have gotten to this point in your career without credibility and social capital. A mistake will not destroy you. Ten mistakes will not destroy you. In fact, mistakes are how we learn.”

Her approach to feeling overwhelmed is practical: “use your core muscles. If you’re most comfortable with code, jump in. If you tend to go first to relationships, talk to people. If you’re a reader, go get the documents.”

On design work, she advocates for being concrete over being safe:

“But it’s a better use of your time to be wrong or controversial than it is to be vague. If you’re wrong, people will tell you and you’ll learn something, and you can change direction if you need to.”

And she’s firm about scope creep: “‘We might need it later’ is not a good enough justification.”

For those worried about spending time coding at this level, she quotes another engineer: “If spending a day a week coding keeps you engaged and excited to come to work, you will likely do better in the rest of your job.”

Unsticking Projects

When blocked by other teams, Reilly emphasises gratitude and making things easy:

“If someone goes out of their way to help you, say thank you. In companies that have peer bonuses or spot bonuses, there’s already a structure for saying thank you: use it.”

Structure your requests so they’re “easy to say yes to, with as little reading needed as possible.”

On migrations and technical debt, she’s direct about the impact: “The half-migration slows down everyone who has to engage with it. This is a place where a staff engineer can step in and have a lot of impact.”

And remember: “there is no such thing as a temporary solution.”

For documenting decisions, she recommends “Lightweight Architectural Decision Records for showing why you made the choice you did”. We noticed other teams at Canonical using these and considered adopting them, but decided against it for now.

Being a Role Model

The chapter on being a role model contains some of the book’s most quotable wisdom. On competence, Reilly writes:

“Competence is built on knowledge and experience, but you also need to be able to apply those abilities. That starts with the self-awareness to know what you can do, how long it will take, and what you don’t know.”

She pushes back against imposter syndrome: “Being competent doesn’t mean you need to be the best. I’ve sometimes seen tech people be shy about claiming to be an expert, because they can always think of someone in the industry who is better than they are. Don’t set your bar at ‘best in the industry.’”

And crucially: “Admitting ignorance is one of the most important things we can do as tech leads, senior engineers, mentors, managers, and other influencers of team culture”. I have long pushed this myself, not only in these fields but as an educator as well. (Fascinatingly, it’s one area where current AI is terrible.)

On standards:

“Your standards will serve as a model for how other people work. Know what high-quality work looks like and aim for that standard in everything you do, not just the parts you enjoy most. Write the clearest documentation you can. Be the first person to know if your software breaks.”

She emphasises that feedback makes your work better: “Your solutions are not you and they don’t define you. Criticism of your work isn’t criticism of you.”

When someone brings you a problem, her advice is to “stay calm. Ask questions. Understand why they’re telling you. Do they just need to vent? Are they hoping you’ll take action?”

She shares a story about making a production mistake early in her career and a colleague’s response: “It’s always interesting to see how new people handle their first screw-up. We’ve all been there.” Then she reflects: “Tim took the time to be kind.”

On team dynamics, she reminds us:

“While you may be the best coder on the team, the most experienced engineer, or the fastest problem solver, that doesn’t mean you should jump on all of the problems. You’re working as part of a team, not a collection of competing individuals. Don’t become a single point of failure where the team can’t get anything done when you’re not available.”

Future-Proofing Your Work

Reilly emphasises thinking ahead:

“So take the time to leave your production environment, codebase, or documentation so that it just works for whoever comes along next. Write tests that will let you refactor your code without breaking things. Follow your style guide so that the people who copy your approach will also be following your style guide.”

She warns: “Every time someone leaves your company, you lose institutional knowledge. If you’re lucky, you have some old-timers storing history in their brains. But eventually, inevitably, you’ll have complete staff turnover.”

And on designing for the long term: “The system will never again be as well understood as it is on the day it’s created.”

She quotes Martin Fowler: “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”

Teaching and Influence at Scale

Reilly distinguishes between giving advice and actually teaching: “What’s the difference between telling people things and teaching them things? Understanding. When you’re giving advice, you’re explaining how you relate to the topic, and the receiver can take your advice or leave it. When you’re teaching, you’re trying to have the other person not just receive the information but internalise it for themselves.”

For hands-on teaching: “Successful teaching includes hands-on learning and activating knowledge: the student should be doing as well as listening.”

On delegation, she advocates for messiness:

“your colleagues won’t learn as much if you only delegate the work after you’ve turned it into ‘beautifully packaged, cleanly wrapped gifts.’ If you instead give them ‘a messy, unscoped project with a bit of a safety net,’ they’ll get a chance to hone their problem-solving abilities, build their own support system, and stretch their skill set.”

Before offering unsolicited advice: “Before you offer your thoughts, think about whether the other person is asking for them. Think too about whether you even have enough context to tell them something that’s both helpful and nonobvious.”

And if you really want to share: “If you’re itching to give unsolicited advice on a topic nobody is asking you about, consider writing a blog post or tweeting about it instead.”

Career Growth

The final chapter acknowledges that specialisation often happens accidentally: “In fact, it’s easy to gain a specialty accidentally just because it’s what you’re doing at work: one experience leads to another, and next thing you know you have a specialization.”

But she also normalises staying put if your current role is working:

“If your job is giving you what you need, there’s no need to change anything. I want to emphasize that because our industry puts a lot of focus on changing jobs frequently, and the regular ‘new job’ announcements can make you feel like you should be moving too.”

And success can mean different things, including working less: “Success can mean working less in your current role. One engineer I spoke with, Jens Rantil, swapped a staff engineering role for 80% time and a 20% pay cut at a much smaller company. As he said, ‘Every Thursday is a Friday! It’s amazing!’”

On finding your next role, she quotes Graham: “I’ve found that people that know you well are always going to be the ones that find you the phase 2 roles that are ‘shaped like you.’ People that don’t know you are always going to offer you the job you just had”. I’ve experienced this, too.

Small Touches I Loved

• “I recommend playing Civilization to understand all things about staff engineering. Tell your boss it’s research.”
• “Being the grizzled, experienced best supporting actor is an amazing role.”
• “In general, if there are more people being the wise voice of reason than there are people actually typing code (or whatever your project’s equivalent is), don’t butt in.”
• The clearest indicator of what a company values: “what gets people promoted.”
• “Think of it as a Ship of Theseus: every individual component may get replaced over the years, but the fundamental system continues. It’s all metaphysical architecture.”

Should You Read It?

Yes. Whether you’re already a staff engineer trying to figure out the role, or an ambitious senior engineer wondering what’s next, this book provides both frameworks and practical tactics. Reilly’s writing is clear, honest, and grounded in real experience. She acknowledges the uncomfortable parts of the job—the politics, the ambiguity, the need to let some things stay broken—without being cynical about them.

The book won’t give you a prescriptive checklist (staff engineering doesn’t work that way), but it will help you build better mental models for navigating technical leadership. As Reilly reminds us, by this level you’re largely choosing your own work—this book helps you choose wisely.

(You can also see my full set of highlights if you’d like).

(Post theme: friendly fire (the pool song)).

This year, I watched 164 films. I recommend Tinā, KPop Demon Hunters, The Gorge, Swiped, Python: The Documentary, Girl Haunts Boy, and We Live in Time, and Sinners. A somewhat disappointing year for films for me.

I also watched 1,259 episodes of TV. I recommend Taskmaster, The Runarounds, Murderbot, Department Q, and Shrinking. Not a great year for TV, either – a lot of stuff I’m somewhat interested in watching, but nothing that really grabbed me.

On YouTube, I watched a lot more than in previous years. I recommend the Taskmaster Podcast, the TalkVille Podcast, Nikki Lu, Dish Podcast, and Off Menu.

I listened to 158 hours of podcasts (this is roughly how long I spent travelling, since that’s about the only time I listen to podcasts these days). I recommend The Morning Shift, the Taskmaster Podcast (again), Gone By Lunchtime, Juggernaut, Wait Where Was I, and The Long Play.

I listened to 3,158 songs (around 64,000 minutes) this year, up quite a bit from last year (mostly because I was living alone for most of the year – it is very quiet!). I recommend Kids Up The Tree, Cassie Henderson, fdasavage, aleksiah, Borderline, Little Green, Emei, Maddy Low, Fan Club, Phoebe Grace, Brooke Alexx, Daisy Grenade, Chloe Parché, and LØLØ. A really great year for discovering new music.

I read a lot of stuff online (via RSS). I recommend everything I posted to tonyandrewmeyer.blog, and in particular: The Spinoff, Simon Willison, Armin Ronacher, and Charity Majors.

I read 115 books (including paper, ebooks, and audio books) this year (a bit over 47,000 pages). I recommend The Staff Engineer’s Path: A Guide for Individual Contributors Navigating Growth and Change, most of Brandon Sanderson‘s books, The Thursday Murder Club, The Library Trilogy, The Witch Roads, The Final Architecture, and Violet and the Velvets: The Case of the Missing Stuff. A good year for enjoyable books, but missing anything that really wowed me, unfortunately. A good book club year again, and a good year of re-reading some childhood favourites (not all of which stand up).

Happy new year!