Everyone has a Brent
On a business novel with cardboard people in it, the four kinds of work, and the deeply unflattering reason bottlenecks stay bottlenecks.
People have been telling me to read The Phoenix Project for years now and I kept not doing it, mostly on the grounds that it looks like the sort of thing you get handed for free at a conference booth. Which, having now read it, is not an unfair read of the cover.
And look, I want to be upfront: it is not a good novel. Everybody in it talks in the same voice. There’s a board member named Erik who has all the answers and refuses to just say them, because he’d rather take you to a factory floor and ask you leading questions for a chapter, and I spent most of the book wanting to shake him. There are scenes where two adults explain manufacturing theory to each other over dinner while one of them says “go on…” I finished it in about four days and I’ve thought about it most weeks since, which is genuinely annoying, because I’d much rather be reporting that it was mid.
The four kinds of work
The bit that got me first is also the least mystical thing in the book. Bill, the guy who gets handed IT operations at a car parts company that’s quietly dying, works out that there are four kinds of work: business projects, internal IT projects, changes, and unplanned work.
The first three you can point at. They’re on a board somewhere, somebody’s tracking them, they show up in a status meeting. The fourth one is where the entire week actually goes.
And the framing that stuck with me is that unplanned work isn’t really work at all. It’s the thing that stops you doing work. It’s anti-work. You commit to a sprint on Monday in good faith, and then a client emails, and a cert expires, and something in prod starts throwing 500s for 11% of requests for reasons that will take two days to understand, and it’s Thursday afternoon and you’ve got four hours left. Nothing you did was optional. None of it is on the board.
So from the outside you just look slow. You said two days. It’s been six. You have been working the whole time, at capacity, sometimes at 11 pm, and there’s no artifact anywhere that says so. I think that gap between how the week felt and how the week reads is responsible for a truly unreasonable share of developer misery, and the book’s answer to it is almost insultingly simple: put it on the board. Make the interrupts visible. If half your capacity reliably goes to things that arrive rather than things you chose, then plan for half your capacity, out loud, where everyone can see it. Otherwise you’ll keep planning as though it doesn’t happen and being surprised every single sprint that it happened.
Everyone has a Brent
Brent is the engineer everything routes through. Every incident, every escalation, every deploy that’s a little bit weird, every system where the actual documentation is a conversation with Brent. Half the plot is just people trying to get work out of Brent’s queue, and the other half is Brent getting pulled back in because the thing is on fire and only he knows where the valve is.
The lesson everybody quotes is the obvious one. Spread the knowledge, write it down, don’t let one person be a single point of failure. Fine, yes, true.
The part I don’t see quoted is that being Brent feels amazing.
Being needed is a hell of a drug. You’re the one they call. The phone goes off at 9 pm and you’re annoyed and also, somewhere underneath that, a little bit delighted, because it confirms something. You are structurally the most important person in the room and the room keeps telling you so. Meanwhile every incentive around that person is quietly paying them to stay exactly where they are: they get thanked in public, they’re in every important meeting, and they are functionally impossible to lay off.
I’ve watched this happen from a couple of feet away more than once, and the thing that struck me is that nobody involved was being cynical about it. Nobody sits down on a Tuesday and decides not to write the deploy setup down as a career move. It’s just that writing it down is never the most urgent thing in front of you, and the reward for finally doing it is fewer phone calls, which is only a reward if you wanted fewer phone calls. So it slides. It keeps sliding, for years, and everybody involved describes the whole situation as a time problem, because that’s the true and comfortable 90% of it. Nobody says out loud that job security and being a bottleneck are the same shape.
Nobody says out loud that job security and being a bottleneck are the same shape.
Which means telling Brent to document things is the wrong lever, and it’s the lever everyone reaches for. You’ve built a system that rewards someone for being irreplaceable and now you’re asking them, as a personal favor, to be less important. Of course that goes nowhere. The thing that actually moves is recognizing the incident that got resolved without them. Ideally louder than you’d have recognized them for fixing it.
Your constraint is not where you’re looking
This is the actual engine of the book, and it’s the idea I keep finding uses for. Any improvement made anywhere other than at the constraint is an illusion. Not “less valuable.” An illusion. It doesn’t do anything.
That feels wrong the first time you hear it, and then you picture a highway where someone’s adding lanes right up to a single toll booth, and it stops feeling wrong.
The web dev version of this is everywhere once you’re looking. You spend a week making CI 40% faster and everybody’s pleased, and PRs still take four days to land, because the constraint was never the build, it was that two people are allowed to approve and both of them are in meetings. Or you hire two more devs and now design is the queue. Or there’s one staging environment and it’s booked. Everybody optimizes the part they can see and own, it feels productive, and the number at the end doesn’t move at all.
It’s an ad, though
It’s worth saying that the book was written by people who sell the model. Gene Kim is IT Revolution, and this is, structurally, a 350-page ad for DevOps, aimed with real precision at the exact person likely to buy it. Ops people who feel unheard get a story where the ops guy saves the company and ends up on the COO track. That is a very comfortable thing to be told and I noticed how much I enjoyed being told it.
And the win is far too clean. A mysterious rich board member turns up to personally mentor you. The security guy who blocks everything has a redemption arc. The CFO turns out to be reasonable once someone explains things properly. Nobody is getting an Erik. Most people are getting a reorg and a new VP with opinions about Jira.
The manufacturing analogy also leaks in a few places, and I think the book is more confident than it’s earned. Work in progress on a plant floor is physical: you can walk over and count it, it’s sitting there taking up space. A half-built feature is not a half-built chassis, and estimating knowledge work is genuinely, structurally harder than measuring throughput on a line. Some of the book’s certainty is borrowed from a domain where the measurement is easy.
But the real gap, for me, is that the book has almost nothing to say about building the wrong thing. Phoenix is late, and everyone’s problem is that it’s late. Whether anyone actually wanted Phoenix barely comes up. And in my experience that failure is at least as common as the pipeline one. You can have immaculate flow, small batches, beautiful automated tests, and use all of it to ship something nobody asked for, on schedule.
And it survives all of that anyway
Because if you strip the vendor layer off, what’s left is three fairly boring claims. Make the work visible. Limit how much you take on at once. Shorten the gap between doing something and finding out whether it worked.
None of those need a toolchain, or a platform, or a transformation. You can do all three with index cards and a wall, which is, to the book’s credit, roughly what they end up doing.
Usual caveats about where I’m standing. I don’t work at a 4,000-person parts manufacturer with a change advisory board and an audit finding hanging over me. On a lot of what I do there is no ops team, the ops team is me, on a Sunday, sweating. So plenty of the specifics don’t port. But the four types of work port completely, and “the constraint isn’t where you’re looking” ports completely, and honestly those two ideas are most of the book’s value anyway.
Read it, I guess
Read it, I guess, but feel free to skim. It’s an audiobook-while-doing-dishes sort of book rather than a sit-down-and-annotate one, and you’ll have the shape of it by chapter 15. Or read The Goal instead and mentally substitute your own deploy pipeline for the factory. Same medicine, less IT.
But if your team has one person that everything routes through, and you’ve spent this whole post nodding along about who it is, I don’t think the useful question is how to get them to write more down. They know. The question is whether anything your team has ever done, out loud, made being less necessary feel like a win to the person doing it. If the answer is nothing, that’s not really their bug.