First published in danish here
I would like to recommend you a book on IT operations . It is written as a novel, but contains significant learning points and academic elements that are relevant. The book is written in an attractive and readable language, with many all-action sections where IT operations often are compared to war-like situations or American action movies. I have several times been thinking my time in the military, when the authors are talking about crashes in IT systems. For example, the IT operations chief speaks to his section leaders on a massive crash in the payroll system and then a crash in the SAN:
First, the events that led to the SAN and payroll failure on Thuesday may not happen again. What started off as a medium-sized payroll failure snowballed into a massive friendly-fire SAN incident. “ s. 78.
One is tempted to shout hell yea - Oorah . (Expression from the Marines) when reading these passages in the book.
At the same time I often find myself smiling of recognizable elements in the small incidents portrayed in the book. These episodes are easy to relate to from my own time in an IT operations organization. This makes the book relevant and funny in its own light consenting shape.
The book starts with the main character Bill Palmer being promoted two levels in the IT department of a large manufacturing company that produces car parts. Bill is a former Marine and a sergeant and hence the book's explicit big hero. He goes from being head of section in a smaller section with 6 employees to become Head of the entire IT operation. Meanwhile, a number of large business critical projects are delayed - especially the Phoenix project (part of the title of the book), which is a 2 -year delay, 20 million dollars big project to reverse the decline of the Company Bill is employed in. In addition, IT operations in the enterprise are characterized by their daily effort to fix a large number of issues and they have no overview of what the employees actually spend their time on.
The book's major theme is described fairly accurately on page 53 where Bill Palmer himself describes the issues that the IT department faces. The following may also be well regarded in a general perspective on the industry, and therefore the book's messages are often relevant and recognizable.
The plot is simple: First, you take an urgent date-driven project, where the shipment date cannot be delayed because of external commitments made to Wall Street or customers. Then you add a bunch of developers who use up all the time in the schedule, leaving no time for testing or operations deployment. And because no one is willing to slip the deployment date, everyone after Development has to take outrageous and unacceptable shortcuts to hit the date.
The results are never pretty. Usually, the software product is so unstable and unusable that even the people who were screaming for it end up saying that it’s not worth shipping. And it’s always IT Operations who still has to stay up all night, rebooting servers hourly to compensate for crappy code, doing whatever heroics are required to hide from the rest of the world just how bad things really are.( s.53)
Bill Palmer and his two section leaders are in the first part of the book thrown in one big IT crash after another, an external security audit and several issues that only a few of their employees can solve (bottlenecks ) . After those issues Bill Palmer meets Eric Reid who has previously worked in the production at one of the factories and has now been offered a seat on the board. Erik Reid is Bill Palmer's savior and he introduces a number of tools that Bill can use to get a handle on his organization and production. Erik explains his method in a sort of hippie / Buddhism kind of way:
”The First Way helps us understand how to create fast flow of work as it moves from Development into IT Operations, because that's what's between the business and the customer. The Second Way shows us how to shorten and amplify feedback loops, so we can fix quality at the source and avoid rework. And the Third Way shows us how to create a culture that simultaneously fosters experimentation, learning from failure, and understanding that repetition and practice are the prerequisites to mastery." S. 91
Bill Palmer works subsequent to correct the IT department, aligns IT with business, ensure good and u bureaucratic processes and distribute work equally among the employees. He tries to identify and address bottlenecks and minimize unplanned work (read emergency breakdowns and project tasks) , to work in a structured , strategic and coherent end-to -end process. All the walls eventually are patched with Kanban boards and LEAN concepts are flying freely through the air. All very nice when he succeeds, but the portrayal of the book seems a little saved, and almost too easily managed and to happy.
The book is also a little archetypal in its character sketches. Bill our biggest hero, Patty is a change manager who love (long and complex) procedures, Wes is operationsmanager with everything that belongs to the subject. He yells before thinking it through , he 's a little overweight and loves technology more than people , John is the IT Security Officer and Bren 's IT nerd , magician , WizKid or some sort of Yoda doing everything in the IT department. Virtually nothing work in the IT department at the beginning of the book, and it cannot be fixed without Brent helps. When Brent works, he goes like in a trance-like state, manipulate code in an intuitive and incomprehensible way. (“You do not need to see his identification ... These are not the droids you're looking for ...).
In other passages in the book, the person depictions is little archetypal and ordinary, but that makes them on the other hand very recognizable from the real world. It is partly amusing but also instructive in terms of how to get people with different backgrounds and perspectives to work together.
Implementation of Eric Reid's three ways runs more smoothly in the book than it probably would in reality. There's just nothing that is that bad and that rapidly becoming well. But if you can ignore this, then the content of the book is still relevant. The book does not deal with human or cultural elements of such major changes, which is probably a major gap.
I think the book is excellent and I would recommend it to everyone in the IT industry. The book also provides an accessible insight into the engine room of an IT department, and illustrates the importance of getting an IT strategy, prioritization of IT projects and the selection of projects coordinated and consolidated with the business vision and goals.
On this basis alone, the book should be read by managers, department and section managers and development staff in companies, which are all dependent on IT to achieve their business goals.
The Phoenix Project: A Novel About IT, DevOps , and Helping Your Business Win
All page references are based on the Kindle version with an upright angle.
The book starts with the main character Bill Palmer being promoted two levels in the IT department of a large manufacturing company that produces car parts. Bill is a former Marine and a sergeant and hence the book's explicit big hero. He goes from being head of section in a smaller section with 6 employees to become Head of the entire IT operation. Meanwhile, a number of large business critical projects are delayed - especially the Phoenix project (part of the title of the book), which is a 2 -year delay, 20 million dollars big project to reverse the decline of the Company Bill is employed in. In addition, IT operations in the enterprise are characterized by their daily effort to fix a large number of issues and they have no overview of what the employees actually spend their time on.
The book's major theme is described fairly accurately on page 53 where Bill Palmer himself describes the issues that the IT department faces. The following may also be well regarded in a general perspective on the industry, and therefore the book's messages are often relevant and recognizable.
The plot is simple: First, you take an urgent date-driven project, where the shipment date cannot be delayed because of external commitments made to Wall Street or customers. Then you add a bunch of developers who use up all the time in the schedule, leaving no time for testing or operations deployment. And because no one is willing to slip the deployment date, everyone after Development has to take outrageous and unacceptable shortcuts to hit the date.
The results are never pretty. Usually, the software product is so unstable and unusable that even the people who were screaming for it end up saying that it’s not worth shipping. And it’s always IT Operations who still has to stay up all night, rebooting servers hourly to compensate for crappy code, doing whatever heroics are required to hide from the rest of the world just how bad things really are.( s.53)
Bill Palmer and his two section leaders are in the first part of the book thrown in one big IT crash after another, an external security audit and several issues that only a few of their employees can solve (bottlenecks ) . After those issues Bill Palmer meets Eric Reid who has previously worked in the production at one of the factories and has now been offered a seat on the board. Erik Reid is Bill Palmer's savior and he introduces a number of tools that Bill can use to get a handle on his organization and production. Erik explains his method in a sort of hippie / Buddhism kind of way:
”The First Way helps us understand how to create fast flow of work as it moves from Development into IT Operations, because that's what's between the business and the customer. The Second Way shows us how to shorten and amplify feedback loops, so we can fix quality at the source and avoid rework. And the Third Way shows us how to create a culture that simultaneously fosters experimentation, learning from failure, and understanding that repetition and practice are the prerequisites to mastery." S. 91
Bill Palmer works subsequent to correct the IT department, aligns IT with business, ensure good and u bureaucratic processes and distribute work equally among the employees. He tries to identify and address bottlenecks and minimize unplanned work (read emergency breakdowns and project tasks) , to work in a structured , strategic and coherent end-to -end process. All the walls eventually are patched with Kanban boards and LEAN concepts are flying freely through the air. All very nice when he succeeds, but the portrayal of the book seems a little saved, and almost too easily managed and to happy.
The book is also a little archetypal in its character sketches. Bill our biggest hero, Patty is a change manager who love (long and complex) procedures, Wes is operationsmanager with everything that belongs to the subject. He yells before thinking it through , he 's a little overweight and loves technology more than people , John is the IT Security Officer and Bren 's IT nerd , magician , WizKid or some sort of Yoda doing everything in the IT department. Virtually nothing work in the IT department at the beginning of the book, and it cannot be fixed without Brent helps. When Brent works, he goes like in a trance-like state, manipulate code in an intuitive and incomprehensible way. (“You do not need to see his identification ... These are not the droids you're looking for ...).
In other passages in the book, the person depictions is little archetypal and ordinary, but that makes them on the other hand very recognizable from the real world. It is partly amusing but also instructive in terms of how to get people with different backgrounds and perspectives to work together.
Implementation of Eric Reid's three ways runs more smoothly in the book than it probably would in reality. There's just nothing that is that bad and that rapidly becoming well. But if you can ignore this, then the content of the book is still relevant. The book does not deal with human or cultural elements of such major changes, which is probably a major gap.
I think the book is excellent and I would recommend it to everyone in the IT industry. The book also provides an accessible insight into the engine room of an IT department, and illustrates the importance of getting an IT strategy, prioritization of IT projects and the selection of projects coordinated and consolidated with the business vision and goals.
On this basis alone, the book should be read by managers, department and section managers and development staff in companies, which are all dependent on IT to achieve their business goals.
The Phoenix Project: A Novel About IT, DevOps , and Helping Your Business Win
All page references are based on the Kindle version with an upright angle.
