The Phoenix Project: When the Hero Is the Bottleneck

Ivan, whom Alexander has known for about five years, picked the book because his career is full of two worlds colliding: a client who does not really understand IT and a contractor who understands it very well. He likes business novels — there is movement and action, it does not read dryly, and hard ideas arrive through a story, although a seasoned professional will find no deep theory or formulas here. Alexander adds context: the book came out more than ten years ago in English from IT Revolution, and before it, by his own hedged recollection, the same authors had done the DevOps handbook — the theory was told first, then it had to be felt. It reads like The Goal moved off the factory floor into IT operations. Alexander reconstructed the structure through a book-summary service: setup, first steps, crisis, radical change. Ivan listened to the audio version and saw no structure at all.

Alexander drew the fictional company: board and CEO on top, manufacturing with warehouses and assembly lines, distribution with shops and delivery, business functions such as finance, marketing and sales, and IT as a service function where security is seen as the people sticking rods into the wheels. Ivan was surprised that operations in the book look like huge cooks frying cutlets out of development's half-finished products: in his world operations never dig deep, they hand you a link and tell you to sort it out. Alexander recalls the run/change model: operations hold the organisation up like Atlases, while development sits on the side writing Phoenix for three years, detached from reality — he would title the book not DevOps but dev in lower case and Ops in capitals. Ivan adds that IT is often outsourced because growing the competence in-house is hard, and departments throw work over the fence: when four projects landed on him at an agency, he and his colleagues made a game of forwarding a client reply to the team lead and inventing a reason to send the task back.

Bill is made head of IT the way it happens in films: there is nobody left but you, everyone smarter has resigned. Ivan finds the story idealised and singles out Steve, who pushed the appointment through, handed over the job and vanished without telling anyone — he has met plenty of leaders like that. On day one comes a top-priority incident: the payroll system is down. The investigation leads to a chain — security asked a developer to do something with the data, the developer went on holiday, and network trouble was added on top. Alexander says it looks less like a drilled surgical team and more like a detective inquiry, and gives Bill credit for taking responsibility from the first day. The fix comes from the star engineer, the classic bottleneck who can do everything but not at once, and it comes later than needed, so plan B kicks in: repeat last month's payments, sort out the differences and wait for the newspapers to react.

Alexander had a similar outage in his first months at a bank: a cache added by the mobile team brought the whole monolith down, taking the investment app news and the online acquisition pages with it; the application was later split by criticality, and a week after that release the orchestrator collapsed and the services were reassembled on single machines. Phoenix, meanwhile, is to ship in two weeks: the testers have never run a full cycle, operations cannot get environment requirements, and there are no physical servers — a rack has to be built and cables pulled. The release is set for a Friday and four days, the weekend goes on shifts with pizza and doughnuts, and Ivan finds it comic from beginning to end. Alexander recalls his own launch on 8 March 2014: a publishing house portal rewritten from Perl to PHP, promised in a month and delivered a year later, on physical servers carrying Italian women's names — not pets, but women with characters of their own. The two-way sync between old and new went untested, so they simply switched traffic, ready to roll back.

Erik, the mentor who drives Bill out to the plant, is by Ivan's account a direct nod by one of the authors to Jonah from The Goal, and Alexander lays the plot along the hero's journey, hedging as he recalls Campbell's book. Erik asks Bill to work out which types of work exist inside his department and points at the bottleneck. They come out as business projects such as Phoenix itself, internal operations projects, changes, and unplanned work; some four hundred changes are in flight and interfere with each other, and there is no task tracker at all — the specialists are autonomous, never talk to one another, and knowledge lives in their heads. Alexander says he would not single out changes as a separate type today: in cross-functional teams with a full cycle they dissolve, though big coordinated efforts remain — a redesign, say, that six dozen mobile-bank teams have to deliver on a date. Ivan adds that there is no theory of types of work, only the streams of a particular business.

Radical change looks like this: a VIP list of four or five business projects, a 20% quota for internal ones — the same magic number people use for tech debt — and work aimed not at the whole process but around the bottleneck, whose expertise they start unpacking and handing on. Kingman's formula is not derived but explained in plain terms: a doctor loaded to a hundred per cent means a queue; the participants extend the example — taking a child through every doctor in one day fails because of dependencies. Flow and feedback loops, Alexander notes, have since moved into frameworks for assessing engineering: DORA, SPACE, developer experience. Ivan argues against measuring that with surveys instead of live retrospectives, and Alexander answers that in an organisation with thousands of engineers surveys give a helicopter view. Ivan liked that the corporation finally spins out a small cross-functional team of business, development and operations, but both find the ending rushed, a fast-forward to the harvest.