The head of strategy and growth in PMI, Dave Garrett advised me to read “The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win”. We were discussing citizen development, low-code and no-code, and it must have been very obvious to Dave that I had no clue about IT, coding or software (or project management for that matter).
Hard to read
It has been hard to read. Not because of the writing, it is a well-written story about how a COO tackles a plethora of IT and staff issues. It was hard to read because I don’t have the context or language to understand. What you do pick up immediately is how, if IT is not managed correctly, it will create havoc. That development and operational teams need to work together.
Quotes
I will share some of the quotes from the book:
- Developers are even worse than networking people. Show me a developer who isn’t crashing production systems, and I’ll show you one who can’t fog a mirror. Or more likely, is on vacation.
- The only thing more dangerous than a developer is a developer conspiring with Security.
- When something hits the fan, you need all the various stakeholders and technology managers to communicate and coordinate until the problem is resolved.
- CIO stands for “Career Is Over.”
- There’s a chain of command: gripes go up, not down.
- Any COO who doesn’t intimately understand the IT systems that actually run the business is just an empty suit, relying on someone else to do their job.
Terminology
I learned a new language. Terms such as information flow, virtualization, change management process (not to be confused with change management), tooling, Infrastructure Library, incident and break-fix work, replacement drives, logical or virtual applications, databases, operating systems, networks, hardware. WIP, cycle times, change over time, deployment cycle, value stream, deployment pipeline, version control, test and production environments, load testing, firewalls, database setting, library versions and evil chaos monkeys.
Management
Throw in the Theory of Constraints, Lean production or the Toyota Production System, and Total Quality Management. Bottlenecks and constraints, planning flow, system thinking, feedback loops, kata, experimentation, learning from failure, and understanding that repetition and practise are the prerequisites to mastery. That describes the journey of the book.
The goal
The book quotes “The Goal” by Dr Eli Goldratt. A good old management classic. Outcomes are what matter, not the process, not controls, or, for that matter, what work you complete.
Step 1 is to identify the constraint.
Step 2 is to exploit the constraint.
Step 3 is to subordinate the constraint.
About agility
IT is crucial to create agility. Business agility is not just about raw speed. It’s about how good you are at detecting and responding to changes in the market and being able to take larger and more calculated risks. It’s about continual experimentation. If you can’t out-experiment and beat your competitors in time to market and agility, you are sunk. Citizen Development is optimized for rapid change and agility.
Every business is a technology business
Every business is an IT business. It’s pervasive, like electricity. Understanding what technology can and can’t do has to become a core competency that every part of a business must have. COVID has proven that point once again. Citizen Development democratises the use of that technology. It makes it even more pervasive and makes change more distributed.
Structure
This is what I learned. There is no form without structure. Which is I think the point Dave was trying to make. If you want to be successful with citizen development, structure is fundamental. Follow PMI here.
