The Phoenix Project: what I have learned from this novel as a Software Engineer
The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win
“Bill is an IT manager at Parts Unlimited. It’s Tuesday morning and on his drive into the office, Bill gets a call from the CEO.
The company’s new IT initiative, code named Phoenix Project, is critical to the future of Parts Unlimited, but the project is massively over budget and very late. The CEO wants Bill to report directly to him and fix the mess in ninety days or else Bill’s entire department will be outsourced.
With the help of a prospective board member and his mysterious philosophy of The Three Ways, Bill starts to see that IT work has more in common with manufacturing plant work than he ever imagined. With the clock ticking, Bill must organize work flow, streamline interdepartmental communications, and effectively serve the other business functions at Parts Unlimited.
In a fast-paced and entertaining style, three luminaries of the DevOps movement deliver a story that anyone who works in IT will recognize. Readers will not only learn how to improve their own IT organizations, they’ll never view IT the same way again.” -> From Google books
We are used to reading about successful IT stories. “The Phoenix Project” shows us everything from the opposite side: what happens when IT people have no idea what business people are trying to achieve.
At the same time business people, people with very minimal or even zero technical knowledge, make technical decisions.
What have I learned from this novel as a Software Engineer?
1. Communication is key #1 to success
All the positive improvements in The Phoenix Project happen when technical leaders finally meet in person with Dick (the big boss who manages the company’s business strategy). Bill finally asks the main question: “What does the business is trying to achieve? And what IT department can help them with?”.
Couldn’t they ask it from the very beginning? They could but they didn’t. They were trying to fix lots of technical issues, focusing on software improvements that are not important for the business without even knowing where the company is heading, what the main business goal is, what their customers even need.
Simple regular and established communication between business people, sales and technical engineers helps everyone win and avoid time and effort being wasted.
As a Software Engineer, I have learned…
from this lesson, to think more about the business part of my everyday work. I want to fully understand the product I am working on, understand its main purpose and how can I help the company to succeed. I have learned that my communication skills and ability to understand the business vision for a software product are often even more important than my technical skills.
Here is a tip for you: ask yourself: “What is the business strategy for the product I am working on? What value the features I am developing can bring to our customers? Do I do enough to help our business win?”.
If you don’t know the answer, please, go ahead and talk with your teammates, product owners, managers or salespeople. Practice regular communication.
2. You have to know how to deal with unplanned work
In The Phoenix Project Bill is learning about the main categories of work. One of them is unplanned work.
Unplanned work is a destructive type of work. It appears all of the sudden, makes you nervous and ruins all your plans. It’s something you want to avoid.
Unplanned work takes you away from your goal. That’s why it’s so important to know where your unplanned work is coming from. -> “The Phoenix Project, chapter 15”.
As a Software Engineer, I have learned…
that wise time management and work estimation are critical to achieving your goals. Oh wait, didn’t I know that before? Isn’t it obvious?
Yeah, I guess it is BUT from now on I always plan unplanned work!
What if there is a bug that has to be fixed ASAP or a failing CI pipeline blocking everyone? Of course, all my other work suddenly gets “less important” and I am going to leave it and focus on fixing urgent issues. And the truth is: in the everyday software development real world it happens all the time. We have to deal with unplanned work all the time!
That’s why I am learning to predict it and plan some extra time in case it happens. Thinking about unpredictable issues which can affect your productivity, as a software engineer, or all your engineering team, helps you to achieve more and reach your goals.
3. DevOps is a Culture
I am one of those people who believe in DevOps as a Culture.
I think ‘The Phoenix Project’ shows it’s every well: DevOps is not just a job title, it’s not just a role. DevOps is not even just a modern work approach.
DevOps is a Culture, a culture of continuous learning and improvement.
Modern IT is impossible without adopting a DevOps culture.
In “The Phoenix Project” Bill and his team make amazing progress after they start questioning everything they do every day and try to improve it.
They make releases to production more frequent and automated, they implement automated testing and most important: they change their mindset to follow DevOps culture.
Of course, they do mistakes and learn from them. And they keep looking for better ways to do the same job. Even at the very end of the story, they still have lots of things to improve. And they still keep learning.
As a Software Engineer …
I have got inspired even more to keep learning every day. Every software engineer has to be a lifelong learner. I knew about it before reading “The Phoenix Project” and now I am focused even more on getting better every day.
It’s so easy to get in a trap and get used the things as it is and stop noticing toils in your everyday tech work. Something which seemed uncomfortable and manual on your first workday for the project eventually starts feeling normal if you don’t try to improve it.
The critical mindset: that’s what I practise as a Software Engineer.
4. Don’t be that idiot who doesn’t ask for help
Well, ‘The Phoenix Project’ isn’t exactly about it but at the end of the story Bill gets amazing new job opportunities and hears these supporting words:
And remember that there are a lot of experienced people around you who’ve been on similar journeys, so don’t be the idiot that failed because he didn’t ask for help.
As a Software Engineer, I have learned…
I guess it’s clear what I have learned: I am not an idiot 😅 (🤞)
Thanks for reading my review!
If you have already read “The Phoenix Project” book, I hope you love it as much as I do! And if you are about to read it soon: enjoy every page!
If you like my article you can support me by buying me a coffee ☕️
