Confusing outcomes with capabilities

I don’t have this sorted out well, but the baby keeps crawling on me to remind me to chill the fuck out about being a professional thought leader and be more of a professional dad. (That’s right, I’m blaming my three year old for the shoddiness of the below!)

In the technology world, you are taught to think in terms of “outcomes,” or “business outcomes” to use the longer jargon. An outcome is the final effect a technology, decision, or change has. It’s a variation of “the means justify the ends.”

What does this technology help us achieve? Revenue, security compliance, faster app response times, developer productivity, migration, etc.

As ever, things are not cut and dry, but I’d say the two other ways of thinking about a tool are capability and price.

Capabilities are things like “run on Windows,” a general programming framework, a service mesh, a configuration tool, any given open source project…this a way of thinking about the tool as the tool. When you think of technology’s capabilities, you’re not really asking “and will that be useful to us?” Of course, “it works” is an assumed feature.

Price is obvious: it is either more than you want to pay, or less than you want to pay. Or, you know, Goldy Locks. Whether it’s a capability you want or it achieves the outcome you want doesn’t matter: it’s the number you want. For handful of of technologies, price is a feature, but not nearly as much as in handbags, t-shirts, and koozies. In general, there is only one price enterprise buyers want: cheaper.

Anyhow, I wanted to talk about mixing up outcomes with capabilities.

In the infrastructure space, we’re really bad at allowing those two to intermix, even treating them as the same thing, instead of keeping them separate.

To illustrate it: there are very few things that give you the outcome of developer productivity. Even defining “developer productivity” is stacking the deck for what you want to argue. I’ll define it as “allowing developers to do more work, ship more often, and probably be happier.” You could make it too vague and say “create the most business value with the shortest amount of time and cost.” As it says: productivity! This usually means removing toil from developer’s day-to-day lives, automating/eliminating manual reviews and meetings, speeding up onboarding (getting faster laptops and test labs), and automating as many things as possible (tests, building, deploying, monitoring, managing). MY DEFINITION IS NOT GREAT, MOVING ON.

(There is another thing we do too much in marketing and that is to think about “developer productivity” as a business outcome which…it could be…but I don’t think most businesses are that sophisticated in how they think about their software strategies. For example, if you’ve historically outsources your custom programming, you’re probably not sophisticated enough. In contrast, as I learned in a recent DevOpsDays talk, John Deere does look at its software factory as a core function so they can think of developer productivity as a pure business outcome. ANYHOW.)

Here is the problem: when you sell, evaluate, use, or otherwise think about a technology based only on its outcome. Us marketers are especially bad at this. Have you ever seen a pitch about some infrastructure technology that starts off telling you about macro economic headwinds and, like, software is eating the world? Chances are you’re thirty minutes to never away from hearing about the actual technology, what it does, and how it works.

The OpenStack era of cloud was rife with this. So many pitches started off saying why cloud was important (cloud or die!), explaining what cloud was, and then that it would help you achieve all sorts of outcomes like agility and moving from capex to opex.

I know it seems like I pick on Kubernetes a lot. And…yes, I do - I have mixed feelings - but, it’s also a recent phenomena we all know. Throughout it’s history, a lot of chatter about Kubernetes has focused on the outcomes it achieves: better cost control, developer productivity, etc. As it turned out, Kubernetes doesn’t really directly give you those outcomes: it’s just part of an overall stack that helps you get there.

Sure, it’s linked. But contrast that with the capabilities of an IDE. If I right click on a chunk of code and say “refactor this code to its own method,” that directly addresses productivity. Most of what an IDE does has the outcome of developer productivity. You know this because you can look at the alternative, a text editor, and see that developers are so much more productive with an IDE.

Now, you could say that Kubernetes gives operations and infrastructure people capabilities…“ops productivity,” and I would say - YES IT DOES (though, now that I look at the chart below for the thousandth time, ops productivity seems to be going in the wrong direction year/year? You see, I haven’t really looked at this chart in terms of operational productivity, just developer productivity.):

Operations people work directly with Kubernetes to get the capability of “install a shit-ton of containers on this cloud thing I setup and obey the configuration governance and policy and have all the processes in those containers talk with each other over the network like this. Oh, and, like, be secure?” The alternatives may not be as good, or as fast, or as reliable.

But Kubernetes itself doesn’t give a shit about application developers. For application developers, it offers a blinking cursor as if to say, “worked fine in ops, dev problem now.”

This is fine! This is what was intended! (Along with Google and Red Hat, et. al., neutralizing AWS’s competitive advantage in IaaS.) The Kubernetes thought-leaders have been trying to tell us this all along:

Kubernetes can certainly be part of a stack that makes developers more productive, but that’s not really a core thing it does. So if you’re thinking in terms of kubernetes as developer productivity, you’re at risk of mixing up outcomes and capabilities.

Things get a bit loopy here - there’s a needling distinction between being part of an overall stack that gets you come outcome (Kubernetes and developer productivity) versus directly creating that outcome (IDEs and developer productivity).

The closer the outcome and the capability are, the more accurate your thinking will be.

Another problem with thinking only about outcomes is that you can’t evaluate it against alternatives. When Puppet, Chef, Ansible, and Salt were going at it, they all wanted to deliver the same outcome. Competition came down to which had the capabilities to do it better, more reliably, in a way ops people liked, and (I assume) price. If you were talking about any of those in terms of outcomes, it’d have been largely a waste of time.

Outcome marketing is best for enterprise sales

In technology marketing and sales, there’s a relationship between the price of the technology, the seniority of the decision maker (whoever approves buying the technology), and how outcomes focused you are. As you can guess, the higher the price, the higher decision maker in the organization, the more you focus on outcomes:

(1) With rare exception, the senior executives approving purchasing something don’t have time to care about how the technology actually works, or evaluate it versus alternatives: they just have to build up a hunch that it seems like it’ll get them the outcome that they want.

(2) And, if you have a high price, you’re going to need a senior executive to approve the budget, so you’re pitching to senior executives, and then see (1).

If all you hear is capabilities talk, the pitch is intended for an individual way down the org chart. If all you hear is outcomes talk, the pitch is included for an executive, way up the stack.

SpringOne Tour is coming up in Amsterdam, October 9th, 2023. I’ll be MC’ing it. I live here, after all! It’s focused on - surprise! - the Spring Framework and programming:

Our Spring advocates, technical engineers, and application development experts bring an in-depth look into the beauty of open-source, with Spring Framework, Spring Boot 3, Kubernetes, Progressive Delivery and more, to strategize with you on how you can innovate faster.

It’s free to come and the content is great, so register and come check it out.

Upcoming

Talks I’ll be giving, places I’ll be, things I’ll be doing, etc.

Sep 13th, stackconf, Berlin. Sep 14th to 15th SREday, London, speaking (get 50% of registration with the code 50-SRE-DAY) Sep 18th to 19th SHIFT in Zadar, speaking. Oct 3rd Enterprise DevOps Techron, Utrecht, speaking. Oct 5th to 6th Monktoberfest, Portland, ME. Oct 9th Spring Tour Amsterdam Nov 6th to 9th VMware Explore in Barcelona, speaking (twice!).

Logoff

I’ll be in Berlin and London this week. Whacky!