Last week, Robert X. Cringely did a fascinating four-part series1,2,3,4 on IBM’s failing fortunes.
It’s a great series of posts, and definitely worth your time, especially if you find you and your friends pondering the Old Guard’s tactical responses to current trends in our industry at cocktail parties5.
Cringely references a quotation from an old Steve Jobs interview to explain why the problem exists, and it really resonated:
The reason IBM can’t deliver is also explained well by Steve Jobs. It’s IBM’s maniacal fixation on process, once a strength but now a cancer.
“Companies get confused,” Jobs told me. “When they start getting bigger they want to replicate their initial success. And a lot of them think well somehow there is some magic in the process of how that success was created so they start to try to institutionalize process across the company. And before very long people get very confused that the process is the content6. And that’s ultimately the downfall of IBM. IBM has the best process people in the world. They just forgot about the content.”
This is a very astute observation7 and still an incredibly common problem, even today, with respect to process. You see it in organizations of all sizes, from start-ups to, well, IBM.
I think the issue stems from the notion that if it is assumed any good process can be scaled to any size organization or problem, then the structure of the process itself must be able to be extrapolated and specified. And because of this requirement that we do the heaving lifting to extrapolate, and all the work to specify it, it will remain consistent, and thus remain effective.
It’s a tantalizing notion. If true, it would mean one can make their finely tuned, tweaked, “perfect”-process into an asset, which they can apply everywhere and/or sell.
While there might be some truth in that—certainly, many attempt to make a living doing exactly that—ultimately the structure-of-the-structure of the process8 is more important than the structure of the process.
Put another way: good organizational (build/release) process has aspects that are clearly consistent across organizational size and disciplines, but trying to bolt the steps of a enterprise corporate security firm’s release process onto, say, a desktop client for a cloud-based media product, is a recipe for a lot of consternation9.
Pre-landing checklists obviously make sense for A380s just as much as they do for 182s; good checklists in both cases will have a natural flow which is backed up by the accompanying equipment’s ergonomics, seamlessly incorporate multiple checks for critical items, and are designed to fail-as-safely-as-possible.
But they’re very different checklists.
The desire to force “wrong-sized” process is what makes everyone roll their eyes and make that “I’m gonna barf”-motion capital-P Process comes up.
Figuring out what needs to go on their own release checklists, making it logically flow between their infrastructure and processes, and fine-tuning is one of my favorite exercises with my clients10.
One size certainly does not fit all, and transplanting process wholesale seldom works. But when we dissect effective process (and process management) from other disciplines, by taking a look at its structure, not the process itself, we can learn something applicable to release engineering.
And very valuable, too.
_______________
1 Part 1
2 Part 2
3 Part 3
4 Part 4
5 As I often do…
6 Cringely later clarifies: “In this instance content means the deliverable, whether a product or service.”
7 As most of Jobs’ are…
8 How very meta!
9 This may be obvious, but I see it all the time. Usually in reverse
10 If it’s something you struggle with, we should chat!
