Hey there! Welcome to Platform Weekly. Your weekly reduction of platform engineering noise. Every week, we boil down what’s actually worth knowing, cut what’s fluff, and flag what will bite you later.
Plus… Kelsey Hightower will be at PlatformCon’s Live Days in San Francisco this February and New York this June to open the discussion on our role as humans in the next era of platform engineering. Get your tickets before early bird pricing ends on September 15.
Does your platform deliver outcomes, or just output?
Is your platform actually a platform? Here is a test. Ask yourself - does it produce output, or does it produce outcome?
I was scrolling on LinkedIn a bit ago, and saw a great (I’ll humbly say) post on LinkedIn about Kaspar and I’s new book Thinking in Platforms. Rob, a Solution Architect, described his platform’s own journey moving from an early Backstage-based IDP built for discoverability and a decent portal experience into a fully fleshed-out internal developer platform. It’s a platform that delivers outcomes… not just a bunch of output.
That’s the exact distinction the whole Paths to Outcome model exists to make.
It is the why to stay focused on platform capabilities that actually create value. And built the model based on our work with you all across 100s of platforms, and it is proven in practice.
Output vs outcome
So why did Rob’s new platform make such a difference compared to one based primarily around Backstage? Because an interface, a portal, is simply where you “ask”. It doesn’t produce anything itself. It’s just the door. Ask through it, and the platform’s capabilities do the work and hand something back. A list appears, a database spins up, generated code comes out. That’s output. And output alone is not the goal, the goal is getting outcomes.
Outcome, for example, is a feature that ships and brings value, or measurable increases in productivity; it’s money in the bank, etc. A beautiful catalog listing fifty services is just output unless it directly taps into the value stream in a measurable way.
An example you will be immediately familiar with. You have a tool now that produces 10x the amount of code you ever thought possible. Output is up 2x. Have your feature delivery gone up 2x? Metrics, your revenue? Most likely… not.
This difference is fundamental to understanding the importance of successful platform engineering, ESPECIALLY, in the AI era where output is up 2-3x in many organizations.
This is the simple path model from the book. An interface takes the request, a capability delivers on it, and an output comes back.
The interface is where the intent gets expressed, the capability is what delivers and brings the output.
The capability has two layers to it - a promise, stated in outcome language (”provide a runnable test environment”), and an implementation, whatever databases, APIs, or agents currently deliver on it.
Your platform should revolve around those kinds of promises.
Now, looking at capability. A single well-designed capability is still just a capability. Outcome only shows up once you map your paths against a value stream, the actual end-to-end flow of someone’s work. How does providing a runnable test environment faster and more on-demand create real value? That’s something your team needs to know, otherwise, how can you decide whether that capability should be built or maintained?
Here’s what that looks like drawn out, one team’s actual feature-development flow, every point where a path drops in to hand something back.
This is an example feature-development value stream. Paths drop in at each point a team needs something back before continuing. A map like this is also your filter. Some of your paths contribute to real outcome, work that visibly moves the value stream forward. Others only ever produce output, busywork that looks productive but never actually feeds the stream.
The game is about building platform capability around the second kind. Every hour spent polishing a capability nobody’s outcome depends on is an hour not spent on a path that does.
You decide what capabilities to build, or keep building, based on the paths that produce outcome, not the ones that just produce output.
So what do you do with this on Monday?
I’ll let you have the weekend to rest. But Monday, it’s go time. Pick one path. Just one. Ask the question. Does output contribute to the value stream or not? Simply, does it produce an outcome?
If you can’t clearly answer that, then that path is not a good use of platform capability or your time.
Rob’s journey didn’t start with their fleshed-out IDP. It started with a portal, a few hard years of learning what devs needed in the moment they needed it, and a deliberate move from cataloging things to promising outcomes. That’s the whole model, compressed into one LinkedIn comment. The rest is just building it.
As always… thank you, go read Thinking in Platforms to go far far deeper (and wider) & of course stay crunchy 🥐
Quick bites
Highlight of the week
Coder executive forum: Building the agentic enterprise - If you’re in the Bay Area or AI Infra Summit, join us at Levi Stadium this Monday. This is going to be the highest-density information event we’ve ever done!
From the community
Every PlatformCon talk, past and present, is on the Platform Engineering YouTube channel.