{ "version": "https://jsonfeed.org/version/1", "title": "platform engineering on Coté", "icon": "https://avatars.micro.blog/avatars/2025/42/8457.jpg", "home_page_url": "https://cote.io/", "feed_url": "https://cote.io/feed.json", "items": [ { "id": "http://cote.micro.blog/2026/04/21/let-them-tinker-hacking-developer.html", "title": "Let them tinker - hacking developer resistance to sound enterprise architecture and platforms", "content_html": "

Developers need to tinker or they’ll reject your platform. That is a lesson that people who build tools and platforms for developers learn. The more ambitious your platform is in scale, the more tinker resistance you encounter - you want it to be the platform that 10,000’s of developers at a bank use, for example.

\n

What if you could give the tinkers what they wanted and also put a standardized, enterprise-wide platform in place? The enterprise architects (EAs) of the world will chortle at that notion as they slide back into their whiteboard palaces muttering “good luck storming the castle…” But, maybe there’s hope.

\n

They’re fine with opinionated platforms, so long as the opinions are theirs

\n
\n

Platform teams typically approach their work from a perspective of standardi[z]ation and reliability. They’ve dealt with the fall-out from inconsistent deployments, security incidents, and audit failures. Their natural response is to reduce variability. A single, perfect, golden path for everyone to follow.

\n

Developers, meanwhile, are optimi[z]ing for something completely different. They’re focused on solving specific problems in the fastest way possible. Creative autonomy is core. And, any mandate to work in a particular way becomes the problem, separate from the technical merits of what you’ve built.

\n

Individual teams making rational decisions create organi[z]ational fragmentation.\n– Bryan Ross, 2025.

\n
\n

This tinkerer-resistance comes through when you hear objections to platform adoption like “we need to customize this,” or, “this platform is too opinionated.” My absurd rendering of it: “we could develop that in a weekend.” (And vibe coding will add weight to that claim.)

\n

Platform people have a fair counter-question: how different can the needs of a development team at a bank really be from the tens of thousands of other development teams at other banks? Should developers (or any of us!) be building a platform on a platform, or, like, writing applications that customers and employees use?

\n

With a platform, every customization is a long-term ownership commitment. Today’s must-have customization becomes tomorrow’s legacy code - the stuff sitting in the modernization queue, slowing down feature work. The customizations were thought to be useful, and certainly necessary, when they shipped. And now, people are looking around asking “why do we have this?"

\n

There’s numerous reasons why building your own platform is a bad idea - at least seven. Most of them revolve around the lack of ongoing commitment people have to taking on the responsibility of a new product, that bundle of customized stuff that resulted in their DIY platform. There’s also just totally under-estimating the scope of a platform.

\n
\n

We’re rightly proud of the work that’s been done on GOV.UK PaaS since its launch in 2015. The team who built and run the service are passionate, committed and quite brilliant. It was the right product at that time. Our web hosting service has enabled more than 60 departments, agencies and local authorities to support 172 digital services.

\n

It has enjoyed uptime of 99.95%, and suffered only one major incident in its 7 years. All this while tenants deployed services more than 122 times a day, made up of 3,200 applications.

\n
\n

Sometimes, you might even have a platform that everyone acknowledges works well, keeps the business running, and that is beloved by developers. A platform that just works and achieves your enterprise strategy and goals.

\n

Tinker don’t care.

\n

One could fall down a cynical hole here.

\n

And yet: the developer is the customer…

\n

Let the tinkers tinker

\n

I like the (unintentional?) experiment Syntasso has going on for this problem. Their approach is not to come with a bundle of pre-built, unchangeable, opinionated platform. Instead they have something a developer will find familiar: an abstraction layer, an API, a schema, a standard (whatever we’re calling things like where you use yaml, json, whatever, to describe the capabilities some technology has, its data model, and also execute stuff - you know, an “API” us olds would say)…for platforms.

\n

If you, the tinker, just so happened to want the stock platform provided, that would be cool. But, sure, you can customize it too! The tinkers often want their own layer, yes, custom fit to their unescapable needs that no one else has.

\n

A tinker loves to put layers on layers, like a giant rainbow cake. There’s a similar pervasive pattern people do with CI/CD pipelines and even things like the Spring Framework: they layer their own layer on-top of those layers.

\n
\n \"a\n
A delicious platform
\n
\n

Long-term the layers on layers on layers (layers^n+1?) strategy is terrible. Now you need to maintain your layer in addition to the off-the-shelf layer. For example, a new version of the Spring Framework comes out with fancy new AI things. You could just download it and use it - even getting full enterprise support.

\n

Sadly, with a layers^n+1 approach, that doesn’t work. Now you need to update your layer on the layer (and Spring is, you know, really a layer over multiple different things, many of them also layers, trying to unify all those different services into one, unified, easier to use layer…which you then add your layer on) - and that tends to get deferred in favor of the actual applications you’re writing to run the business.

\n\n

Anyhow. Why not let the tinkers tinker?

\n

First, you need to set expectations ahead of time that, now, the tinkers own day two:

\n
\n

That’s the shift that matters. When you provide the right level of abstraction, you don’t just make systems easier to use; you make them easier to own. Engineers can take responsibility for the parts of the platform that matter to them, evolve those capabilities independently, and own their flow of value.

\n
\n

The DevOps world was all about this shifting-left. DevSecOps was all over shifting-left. You can offer to shift-down, but the tinker always wants to shift-left.

\n\n

Christmas Puppy as a Platform

\n
\n

You’re not just the owner of a single puppy on Christmas morning. You have a mega litter. These puppies are running rampant around your entire organization and they’re completely unsupervised. You need to track them down each time you want to introduce a new feature, each time you need to patch a CVE. So, as a platform engineer, you don’t get to be high leverage as an engineer. You’re a full-time puppy parent, but you don’t even get the Insta photos. You don’t get the snuggles. Abby Bangser, KubeCon NA 2025.

\n
\n

Inevitably, the platform team will inherit this tinkering despite any social contracts established by a long-lost Confluence page years ago. But, maybe if the platform-building system you have starts off as tinker-friendly, that future instance of the “not my mistake, but now my problem” ops anti-pattern will be less painful.

\n

I like watching what Syntasso and Kratix are doing here (and elsewhere). I don’t think it’s intentional per se. They’re genuine in their efforts to build a new type of cloud native application platform. But there’s an interesting natural experiment going on: what if you build a platform to be both tinker-friendly and enterprise-wide?

\n

PaaS gets a bad rap because it’s supposedly anti-tinker. In truth, most every platform can be tinker friendly. It’s just a matter of how they’re positioned and perceived over time, and if the means of customization match the tinker’s aesthetics.

\n

Harness the tinker kingmaking

\n

Here’s other examples of being tinker-friendly.

\n

The entire DevOps toolchain was tinker-friendly from the beginning, and that helped that community harness a lot of kingmaking energy.

\n

Kubernetes subsisted on the tinkers for many years, despite some comments to the contrary later in that community’s history and continual pleas to look elsewhere if you wanted to use Kubernetes for a platform.

\n

What I like about the Syntasso/Kratix experiment in platforms is the potential for sociotechnical hacking. Is it possible to give the tinkers what they want and still build an application platform that achieves all the centralization benefits in a large enterprise? “Technology is easy, people are hard”…“containers won’t fix your broken culture,” etc. So, maybe this is some good culture-hacking.

\n

Eagerly awaiting results!

\n

P.S.: This is just in time too because, you know, now we have an entirely new platform that the tinkers are salivating at right now: the enterprise AI platform. You can feel the tinker’s fingers start to twitch. “You know, we don’t need to use AI PLATFORM VENDOR X, Y, or even, Z…I could probably implement that in a weekend…"

\n\n", "date_published": "2026-04-21T10:51:04+02:00", "url": "https://cote.io/2026/04/21/let-them-tinker-hacking-developer.html", "tags": ["tech","platform engineering"] } ] }