Pragmatic Engineering

Notes on software architecture and practical engineering, including insights from technical books and real-world experience.

6 lessons I've learned from The Phoenix Project

My take on the most important lessons I've learned from Gene Kim's book The Phoenix Project

reading: ~3m

1. Taking risks must be part of the company culture

Failing fast with new ideas, taking lessons, and improving is far more effective than following the standard way of working. With every technical task, think of ways to improve it next time. If you know how, try to find time to make those improvements. Delaying them for an "unknown later" will create technical debt, both for the project and yourself. Try to divide some Dev and IT time toward supporting tasks.

John is a chief information security officer who goes through the biggest change in work approach over the course of the book. His colleagues see him as a progress blocker. They blame his frequent IT security checks and following complex protocols for disturbing others. He changes after taking the initiative to teach and trust others. So, he goes from blocking progress to being an asset.

2. Documenting key project knowledge is required

The perfect solution would be to document every detail. Then, for a big project, like project Phoenix, we would know every step taken. In real-life projects, there's not enough time to document everything. So, focus on the complex, repeated processes (like onboarding, VPN setup, and vendor integrations). This will save time in the future.

3. Slack time is important

In the book, there's a guy called Brent who is the "know-it-all" type.

Brent is resolving different issues in many systems at a time and knows undocumented processes, so only he is able to solve them. Why is that? Brent is always busy, firefighting and working on projects, which means that until he's done, he can't take on any new work.

Like in the theory of constraints, some slack time is important. You can use it for new improvements, documentation, or high-priority work.

4. High trust and engineering spirit

A team does not achieve transparency, mutual trust, and vulnerability easily, but it needs them to function.

5. Priorities

Brent wasn't always doing the highest priority work. A lack of self-organization led him to try to pack in less important tasks, which prevented him from doing the priority work first. He often couldn't finish simple tasks on time as he neglected to set aside some slack time to automate them. Another issue with his work organization was a lack of trust in others. He took on work that only he could do, but someone else should have handled it.

I have a few strategies for handling tasks with efficiency. They are often high priority but boring, require neglected automation from long ago, or need rare skills. You can find them in this blog post.

6. Every company is now an IT company

At first, Steve, the company CEO, says, "IT is like keeping the toilets running. I should never have to think about it." As technology use grows, IT is now vital to the business. Companies must advance to keep up. So, he now sees IT workers as essential, not as janitors. Many companies still resist their IT departments and overdue change. They are at a competitive disadvantage.

I've been planning my kitchen lately. Before using Blender to model it, I checked various companies' design tools. IKEA offers an excellent, user-friendly kitchen design tool that works in the browser. In contrast, many other companies either had poor tools or none at all. I believe this can greatly influence customers looking to buy a new kitchen.