As a Software Engineering Manager, I’m always looking for ways to improve team efficiency, reduce bottlenecks, and ensure we’re delivering value. Recently, I read most of The Phoenix Project by Gene Kim, Kevin Behr, and George Spafford. While I didn’t finish every chapter (it dragged on a bit at the end), the key concepts resonated deeply with me — especially in managing software teams. The book really drives home how to optimize workflows and IT operations, pulling from lean manufacturing, DevOps, and the Theory of Constraints. It breaks down how small changes in the right areas can make a huge impact.
One of the most important lessons for me was the idea of focusing on bottlenecks first. The Theory of Constraints emphasizes that making improvements anywhere other than the main bottleneck is just an illusion of progress. That hit home. In software development, it’s easy to get caught up in optimizing things that don’t really move the needle. If code reviews are the biggest slowdown, fixing deployment speed won’t help. If waiting on external teams causes delays, improving your own team’s process won’t solve the real issue.
Unplanned work is a constant challenge. It’s easy to overlook how much of an impact it has until you step back and see how much time gets lost to firefighting and unexpected issues. The book categorizes work into business projects, internal projects, changes, and unplanned work. That last category can be the most disruptive — derailing progress and shifting focus away from planned initiatives. I’ve seen teams fall behind, not because they lacked effort or talent, but because they were constantly reacting instead of executing. The key takeaway is the importance of making this type of work visible, tracking it, and actively reducing it rather than just accepting it as inevitable.
Limiting work in process (WIP) is extremely important. Context switching and overload don’t just slow teams down — they grind progress to a halt. It’s not about how many tasks you start but how many you actually finish. When there’s too much in motion, nothing gets done efficiently. The key is keeping priorities clear and ensuring work moves smoothly through the system rather than accumulating in queues.
Another core idea is the importance of feedback loops. The faster teams get feedback — whether it’s on code quality, system performance, or deployment issues — the faster they can adjust and improve. It’s easy to assume that just having a process in place is enough, but delays in feedback can cause problems to snowball. Shortening those loops, making feedback more immediate, and ensuring it’s actionable are things I’ve been thinking about applying more deliberately.
One of my favorite takeaways from the book is that continuous improvement matters more than perfection. It almost doesn’t matter what you improve, as long as you’re improving something. That really resonated with me because it aligns with how I think about team growth. If you’re always improving, even in small ways, things will get better. If you’re not, entropy will take over and things will get worse. I want to double down on reinforcing a mindset where making things better is just part of how we work.
Reading The Phoenix Project reinforced a lot of what I already believed, but also gave me new perspectives on workflow optimization and continuous improvement. Lately, I’ve been focused on finding ways to improve cycle times and identifying areas where processes could be more efficient. While limiting WIP hasn’t been my primary focus, it’s come up more often and is something I think really makes sense. Unplanned work always deserves scrutiny, and I’m continuing to look for ways to manage it effectively when it arises. If you’ve read The Phoenix Project, I’d love to hear what lessons resonated with you and how you’ve applied them.
