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!

In Iowa

I was in Des Moines this week to give one of the keynotes at DevOpsDays Des Moines (it went well). Here’s some snapshots from around town:

CEO Therapy

This week’s Software Defined Talk:

This week, we discuss Netflix's DVD deprecation, the remote work debate, and how to fork an open-source project. Plus, thoughts on why Europe needs more ice.

Have a listen!

Transcripts

For all the podcasts, videos, conference talks, and even notes to myself: I haven’t figured out what to do with automated transcript systems. It’s nice to have text, but the work involved in doing anything with feels almost as high as starting from scratch.

I’ve done hundreds of hours of video and podcasts over, like, 25 or 30 years. If I got actuate transcripts, I’m not sure what I’d do with them. When I do an hour interview with someone, you’d think getting a transcript would be useful.

You’d think that passing it ChatGPT to write an article would be useful. First, ChatGPT can’t handle that amount of text (at least, I don’t know how to get it to). Second, the result requires a lot of editing. Over that 30 years I’ve trained to become a good writer: I’m good at going from a blank screen and getting to 500, 1800, or many more words.

Maybe transcripts are not so good for writing, but they do seem good for:

• Voice Notes - I’ve never been a big user of voice notes. But that might actually be helpful. I’ve been it more than ever recently, and like many quips about taking notes, the value isn’t really in the note itself, but in using writing as thinking.

• Also, dictating writing might be good, but typing is so much faster and you can edit and correct as you go.

• I do read transcripts of other podcasts when I don’t want to listen to them, that’s fine.

This is a free report from Jennifer Riggins at The New Stack. I talked with her a couple times for it and reviewed the text ahead of time. You should check it out, I think it’s a good go at trying to nail down exactly what that term means. This month, at least :)

Wastebook

• “Survival is optional. No one has to change” is cold comfort to the employees of companies that didn’t survive. I wish we’d spend more time in the “digital transformation” world focusing on getting people to change, not just tell the survivors how awesome it’ll be once they change.

• Remember the positive feeling that you could be fine taking actions to do things instead of focus on your own hobbies. Working on your life instead of vague FOMO.

Relevant to your interests

• VMware Expands Tanzu into a Full Platform Engineering Environment - Overview of our take on platform engineering, product-wise.

• Dangerous Dimensions: Mind-Bending Tales of the Mathematical Weird - Looks like fun, right?

• HashiCorp Retools Licenses And Software To Grow Its Business - Extensive look into the HasiCorp financials and talk of their OSS licensing shift.

• The Works of Mars, 1671 - Fortification engineering.

• Here’s Something Past Its Expiration Date: the Expiration Date Itself - “Food experts broadly agree that the expiration dates on every box of crackers, can of beans and bag of apples waste money, squander perfectly good food, needlessly clog landfills, spew methane and contribute to climate change.” // And, they’re gone for the most part in the UK.

• Texas’s Biggest Barbecue City Is Attracting a New Crop of Exciting Restaurants - Lots going on in Lockhart.

• Favorite coffee-making setups from the Ars Technica staff - I made coffee with a Chemex for a few years. The coffee was good, and the overall ritual of it was just fantastic.

• Books Recommended With Uncommon Wisdom and Tender Care - “Over and over, Aoyama demonstrates how it’s done. In her Hatori ward, good fortune is not arbitrary or unearned; it is never a gauzy gift from the universe. It arises instead from action, experience and wisdom. Her characters appreciate each other; they are grateful to each other; they recognize in each other quality and potential. (Put these folks in a laboratory dish with the dramatis personae of a cynical HBO show and they’d annihilate each other, matter and antimatter.)” And: “You’ve got to be careful with novels about libraries and bookstores… The risk, in all these cases, is flattery. It feels nice to be assured that the places you find appealing are, in fact, wonderful. It’s also boring. The standard for such novels, therefore, is that they reveal something interesting and true about these environments.”

• It’s Not You, It’s Me: What It Really Means When Budget Is The Reason For The Breakup - Something that’s not useful isn’t worth paying for.

• Forrester’s Impressions: VMware Explore 2023 - A brief overview of VMware’s strategy and where Forrester thinks it going.

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. Nov 6th to 9th VMware Explore in Barcelona, speaking (twice!).

Logoff

Des Moines, 7:38am

I’ve got a lot of travel coming up - like the old days! Two more weeks of long trips.

More importantly, it’s the start of the school year for my three kids. You’re supposed to look at actual New Years as the start of a new cycle, but the school year has always been the beginning of the cycle for me, back to when I was kid, college, and even when I was kidless for a long time. It’s a time to start new habits, especially when it comes to parental pedantry. But, the structure of the school schedule also clear out all the time-wasting that comes with schedule ambiguity and openness. I was told once that I thrive in structure, which seemed right at the time, despite the chaos-driven nature I can seem to have: that’s just my writing and content style, though.

HashiCorp Retools Licenses And Software To Grow Its Business - Extensive look into the HasiCorp financials and talk of their OSS licensing shift.

Forrester’s Impressions: VMware Explore 2023 - A brief overview of VMware’s strategy and where Forrester thinks it going.

It’s Not You, It’s Me: What It Really Means When Budget Is The Reason For The Breakup - Something that’s not useful isn’t worth paying for.

The Works of Mars, 1671 - Fortification engineering.

Dangerous Dimensions: Mind-Bending Tales of the Mathematical Weird - Looks like fun, right?

Here’s Something Past Its Expiration Date: the Expiration Date Itself - “Food experts broadly agree that the expiration dates on every box of crackers, can of beans and bag of apples waste money, squander perfectly good food, needlessly clog landfills, spew methane and contribute to climate change.” // And, they’re gone for the most part in the UK.

Texas’s Biggest Barbecue City Is Attracting a New Crop of Exciting Restaurants - Lots going on in Lockhart.

Favorite coffee-making setups from the Ars Technica staff - I made coffee with a Chemex for a few years. The coffee was good, and the overall ritual of it was just fantastic.