This post continues the book club discussion of The Phoenix Project. See also: The Phoenix Project – Part 5
Here are my notes for chapters 26-30…
- It’s important that the team — not just the IT department — owns things working or not working.
- We discussed the analogy of one salesperson missing their goal isn’t going to bring down the organization, but one misconfigured server can. Jameson said this is an issue of scale: One IT domino brings everything down.
- The book mentioned that some of these targets and timelines seemed arbitrarily set by the board (i.e., not the people doing the work).
- The theme of “no one likes doing maintenance” appeared again; it catches up with you eventually.
- The concept of quick time to market and failing fast came from manufacturing.
- Money invested in a project and code not in production does nothing for you until you produce something from it.
- We discussed Dick’s attitude about the spreadsheet that Bill and his team put together (performance measures, areas of IT reliance, business risk due to IT) and it being too late to learn these things. Geoff said Dick’s attitude doesn’t help because he needs the project to succeed; demeaning the team isn’t effective here.
- If IT fails, the company fails. How does IT not know what their role is? Jameson said this is a bottom-up problem: IT isn’t communicating how their changes led to this point. Now they can breathe a bit and evaluate their position instead of fire-fighting.
- IT risk = business risk
- Repetition, especially for things that require team work, creates trust and transparency.
- We discover that Sarah is spending $200K to work around the IT systems, and that workaround violates data privacy policies. John is now speaking up and getting serious (instead of crying wolf) about things that matter.
- Houston and Jameson talked about the mantra of, “Oh, if you think this is bad, you should have seen it before.” Unless you actively acknowledge that things can be better than they are now and outline a plan to get there, this attitude breeds complacency (i.e., at least this isn’t as bad as it was). This is a slippery slope, as this attitude can be helpful to boost morale in the short term.
- It’s important to have a staging/test environment that’s similar in hardware, configuration, software, etc. to the production environment.
- Steve is more on board with standing up to Sarah not complying with new IT work (i.e., $200K workaround). Jameson noted that the representative not in the room was HR. Steve needs to lead and needs others to support him; they see he’s helping by standing up to Sarah’s tactics.
- There was an analogy to a motorcycle with no reverse gear. Work shouldn’t roll back (unless absolutely necessary); it should roll forward. (Note: I tried to find an unbiased and current version of something to link to that describes rolling forward and couldn’t locate a satisfactory source.)
- Houston suggested that Erik is a framing device (i.e., something for the protagonist to learn from instead of a “real person”), which is why none of us can find a good analog to him in our careers.
- Work smaller, groom the backlog, deliver sooner.
- Instead of thinking at the work center level, Bill needs to think at the plant manager level. IT is the plant in this case.
- The three of us learned about takt time. (Fun side note: Geoff had the advantage here of reading this book via Kindle edition, so Houston and Jameson thought this was “tack time” from their Audible experience.)
- “Get humans out of the deployment business.”