Review: The Phoenix Project

The Phoenix project is a fictitious novel which follows Bill in his new role as VP of IT operations at Parts Unlimited.

Mentored by Erik, a potential board member, Bill and his colleagues turn around a department which is firefighting, missing deadlines and misaligning with the organisation’s objectives. They create an IT department which can respond rapidly to changing markets and deliver IT systems which help the company meet their targets and gain competitive advantage.

My Thoughts

The style of the book makes it a quick and easily read introduction to devops. It delivers a plethora of information (based on the length of my notes) on ways you can improve how your team, department and company operate in an easily digestible fashion. It could be argued that change and improvement come too easily in the book but that didn’t bother me. The point of the book is to distil information in an easy to absorb manner not win a literary book award.

Most of the improvements were things I was already aware of and which I see implemented in the projects I work on but it is still a useful reminder. The thing that really stuck with me is to not be a bystander but to be someone who actively challenges the norm and looks for ways to improve things. Don’t be a yes woman. Be someone willing to take a risk and innovate.


Here are some of my takeaways

  • Co-ordination and communication across teams, roles and departments is key especially during times of pressure.

  • Regular outages mean you are reactive and take up resource and time meant to be spent on planned work. Need to understand why they are happening and put measures in place to stop them happening.

  • Know your constraints including people and have plans in place for how to reduce dependency on them.

  • Make sure you exploit your constraint so it is never waiting on anything. Focus on top priority work and set tempo of work according to constraints

  • Avoid knowledge silos. Make sure the heroes in your company share knowledge.

  • Not throwing code over the wall. Developers shouldn’t consider their code successful until it is deployed to live and working as expected. Need to work with ops to supply them the knowledge required to achieve this.

  • It is not enough to have a process in place. It must be light weight enough for people to follow it

  • Importance of testing including non-functional testing e.g. performance, capacity testing.

  • Design code for operations. Non-functionals should be built in early and not an after thought.

  • Integrate security into day to day work not an afterthought

  • Controlled release of features and change so you know exactly what code/features/configuration exist in an environment e.g. source control of code including build configuration, automated deployment, reproducible environments

  • Importance of having monitoring and health checks in place to warn of issues.

  • Work In Progress is a silent killer

  • Theory of constraints: improvements made anywhere beyond bottleneck are illusion. Identify your bottleneck and make improvements there to stop it being a bottleneck … then find the next bottleneck

  • Value in visualizing work to be done and flow through system e.g. kanban board

  • Outcomes are key. Focus on what is important to business. Avoid needless work. Question need to do work.

  • Have a culture which allows for blameless post-mortems so you can get down to the real root cause of issues.

  • Importance of paying down technical debt. Like financial debt, the compounding interest costs grow over time.

  • Need ability to say no and not blindly say yes

  • Improving daily work is even more important than doing it

  • Need metrics to make informed decision

  • Importance of making time for retrospectives

  • Know end goals and align with them. Linking individual objectives with team, department and organisational objectives. E.g. a department’s goals may be reliant on delivery by IT so there is a risk if IT does not deliver. Integrate IT into performance measures.

  • Talk to business owners, understand processes and goals, your role in achieving them, concerns and risks

  • Reduce cycle times e.g. move to 2 week sprints. Get feature to market quickly to test assumptions and get feedback from customers

  • Guard assets. Protect them from distractions.

  • Identify common processes/steps, standardize and automate them

  • Encourage experimentation, innovation and risk taking. Make it ok to fail.