Hey there! Welcome to Platform Weekly. Your weekly pour of platform engineering concrete. Every week we take the community's loudest debates, hardest lessons and best ideas and turn them into one email worth your Friday coffee.
Plus… It's your last chance to have a say in what platform teams actually need. Take the survey!
We wrote the book on platform engineering
My book compiling everything we have learned and stressed tested over the last 10 years is out now - Thinking in Platforms!
If the platform is the prerequisite to succeeding in the AI era, which we now know is a fact, then the question is… what do YOU do to enable this? That is the goal of the book. It tells the story of platform engineering, and then goes deep on the frameworks and principles we believe are key to succeeding with it (from IT and beyond)
This newsletter is a snapshot of what we break down in extensive detail in the book.
The wrong way
Every organization already runs a production system, designed or not. My favorite example is with cars 100 years ago. In Detroit, 1903, it’s all ad hoc workshops, one main hot shot guy assembling the car. By 1906 Henry Ford asks the better question. “Why don’t we treat the production system itself the same way we think about the product?” As an evolutionary process that we learn from, evolve and develop continually with feedback. The rest is history.
We can think about our production systems in IT the same way we’ve done in industry. To start down that path, we identified four archetypes of production systems. You will recognize all of them from your org (and your daily life too).
They are artisanal, hero-based, bureaucratic, and platform-based.
Artisanal, all informal coordination and negotiation, think of the workshop where every chair is bespoke and no two use the same screws. Hero-based, where the system relies on that one engineer who owns deployment and can turn up asking you to double his salary. You pay. They leave anyway. Huge disaster. Bureaucratic (*cough the post office *cough), predictable, and failing very predictably, with a compounding cover your ass policy from basically everyone everywhere. Platform-based, where the production line itself is the product.
In your org, you probably have many of these patterns. And some will even rise to resolve the gaps in others. The hero engineer stays up late so the artisanly designed feature can hit the deadline. The leadership team puts in new “bureaucracy” in the form of approval gates to prevent AI compliance issues.
Does that mean then the goal is to assembly line everything? NO. The goal is to standardize freedom of means, but never standardize freedom of output. Let’s zoom in on that.
The right way: paths
You know that a platform is not an interface you can look at. What it is instead is users walking the same routes over and over, like students wearing tracks into a university lawn until somebody pours concrete on the most destroyed one. This is what for years we’ve called the golden path.
A path is one of those routes made deliberate. A user turns up with a single intent and the path serves it end to end. That is the molecular unit of a platform. The input is the ask itself. Think “give me a small Postgres database”. The interface is where the ask goes in, a portal, a CLI, a pull request etc. The capability is what actually fulfills it. The output is the database that gets handed back.
Capability really just means capability. It doesn’t mean specific tool or tech. It could be Terraform today, Crossplane next quarter, but the promise of the capability doesn’t change.
Then you stack them. One path gives you something. Many paths give you an outcome. That is what we define as the paths to outcome model, and it is the first framework that lets you draw your platform and take it forward not just to your boss for funding, but to actually securing adoption, and delivering value.
It also massively shrinks your problem. Teams assume they have 100s & 100s of paths, but it just isn’t true. A database is one path that accepts a few inputs. Count honestly and software regularly lands at 20 or 25 paths. That is a number that is knowable and manageable, and can become an immediate backlog you know will take you where you need to go.
Here is a model of exactly this - and we’ve drawn it for non-IT intentionally to really emphasize. This is NOT about specific tech and tools.
And where does AI play into this?
Well, everyone has seen a super dope day 1 agentic demo, and then right after hit the wall of “how do I actually make it day 100 ready?” If agents are users now (and they increasingly are), they need clearer paths than any human, ever. The agents have to run somewhere, and your role as the platform engineer is to build the platform for them too.
There are “platform engineers”, though they often aren’t called that yet, doing this in all kinds of organizations from marketing to legal, finance and ofc in our world of IT. The framework is exactly the same.
The playbook
This is a lot. I know. So part 3 of the book breaks it all down in detail. It’s roughly 80 pages of practical information. Minimum Viable Platform, then production readiness, then scaling. But mostly it is on helping you subtract. How to ask why until you reach what is actually essential, which is always way less than you originally think it is. How to identify that one team, a few paths, real users.
And to close off here with something I’d always dreamed of saying. You can get my new book Thinking in Platforms here.
As always…thank you & stay crunchy 🥐
Quick bites
Highlight of the week
Coder executive forum: Building the agentic enterprise - for our bay area folks. This is a MUST attend!
From the community
Want to watch the recordings of PlatformCon workshops and talks you weren’t able to attend? We’re uploading more every day on the community YouTube channel.
And that’s a wrap on this week! As always, this newsletter is a community project. So if you have anything awesome to share from the cloud-native world, send it my way.
Stay crunchy 🥐
Luca
Congrats! Just out of curiosity, how much it took to write a book? I always found it challenging to write a book in such a changing times in IT. It feels that as soon as you finish, the book starts to become obsolete 😂