Management Consulting
Software Engineering
Product & Strategy
AI
Security
Cloud
Data
Talent
Coming to Consensus
It’s one thing to do stuff… it is quite another to write about what you do. It is tough to be clear and articulate; always making sure to leave your reader in a better place than when you got them. I’ve learned that the hard way over the past few years while doing papers for VersionOne and writing this blog. That said, collaborating with Dennis on the framework for our book has taken this challenge to a whole new level.
Over the past few days I stopped writing about the book because we hit a bit of a wall. We knew some of the words we were using were overloaded. What we didn’t realize was how much that overloading allowed us to have a conversation without having any idea what each other were talking about. Okay… that might be a little strong… but getting through it was pretty frustrating. Having two strong willed, capable dudes… both with a strong vision and sense of direction… trying to merge complex ideas into something simple and digestible has proven pretty challenging.
Last week I talked about three types of capabilities: Value, Core, and Supporting. I had described Value Capabilities as the stuff we provide back to the business… stuff we might sell to an actual customer. Our problem wasn’t that Value Capabilities don’t exist… it’s just that in our model all capabilities have a value attribute. I inadvertently overloaded the word Value as well as the word Capability. From here out we are going stop using the expression Value Capabilities and replace it with the idea of Product Capabilities. Same concept, different language.
I’ve never been a big fan of how we were using the expression Core Capabilities. Again… it’s not that these kinds of capabilities didn’t exist… its just that describing them as core didn’t prove descriptive enough and led to some confusion. We’ll keep the category basically the same… it will include all the stuff we directly do to deliver the Product Capabilities… stuff like writing software and testing… but we are going to call them Delivery Capabilities. It seems a little more descriptive for the purposes of our conversation.
Finally, we talked about the idea of Supporting Capabilities. I had described these as the things you need to be good at to support your ability to deliver Product Capabilities. I had included environmental things like building CI environments, invoicing and collecting payments. I had also included stuff like managing the project and communicating status. Dennis has convinced me that we need to separate these into two categories. To that end, we are now going to think about these in terms of Supporting Capabilities (CI environments, invoicing and collecting payments) and Controlling Capabilities (managing the project and communicating status).
