Hey there,
I recently wrote that one of the biggest misconceptions in platform engineering is that it should be single mindedly focused on the developer side of things, often without thinking about how this will holistically impact other teams in your engineering organization.
This kind of thinking leads to terribly ill-designed platforms that nobody uses. For some hard to understand reason a lot of platform teams still think their job is done if they make their way through the mediocre experience of setting up an open source portal. They then set up 10 Terraform template modules and configure the portal to trigger a pipeline that executes them to create a resource. Â
Next they march in front of their colleagues and wait for praises to rain upon them. And sure, those 4 times a year a developer needs the exact template you have in your template gallery the experience of clicking a button and “magic” happening might be delightful. But here’s why this is the tip of a very, very large ice-berg and you are the titanic:
- Every time that developer creates a new resource somebody has to maintain it. By overly optimizing on the developer, without thinking about how it impacts the wider organization, you often end up making the life of infrastructure and operations teams much harder.
- You’re optimizing on day one. That’s cute but assume that service will be around for 4 years or 1460 days. You optimizing day one means you just ignore 99,93% and guess what: the actual painful situations in the life of a developer happen in those 99%.payloads
- Is clicking in a UI “good developer experience”? Not in the world I live in. There is a statistic that always wows me: the Platform Orchestrator can receive payloads from all sorts of interfaces. Platform Teams usually configure it such that users have interface choice. Yet 98% of all requests we’re recording come through code-based interfaces, not through portals. Let that sink in.
So, we should come to the conclusion that you cannot optimize the experience of one group at the expense of another. Developers have pain points, Infra and Ops folks have pain points.
A good way of structuring platform engineering teams with a focus of balancing voices is to have each team send “ambassadors”. Developers send Devex Platform Engineers, I/O teams send Infrastructure Platform Engineers. Together they drive value and ultimately all of them serve the business to ship more features faster and cheaper. If we’re honest there’s even a group missing: security teams. But that’s for another newsletter.
An excellent opportunity to debate all of this is the upcoming PlatformCon which is just 3 weeks out! Check out the watch parties (I’ll be at the one in London if you happen to be around), speakers and talks and join me and thousands of other platform engineers at the largest event of the year!
Kaspar
