Product or Plumbing? The Platform Team’s Dilemma | by Karl Isenberg | Jul, 2026 | MediumSitemapOpen in appSign up<br>Sign in

Medium Logo

Get app<br>Write

Search

Sign up<br>Sign in

Ambiguity gets you product expectations on a plumbing budget.<br>Nobody Ever Asks for TLS<br>Product Standards, Plumbing Budget<br>Nobody Throws a Parade for the Water Main<br>Your Users Are Tenants, Not Customers<br>Domain Driven Productization<br>Get It in Writing<br>Invoice the Silence

Product or Plumbing? The Platform Team’s Dilemma

Karl Isenberg

11 min read·<br>1 day ago

Listen

Share

Yes.<br>Press enter or click to view image in full size

Ambiguity gets you product expectations on a plumbing budget.<br>This one goes out to all the platform engineers: the ones keeping the clusters, the registries, the CI, and everything else running that gets taken for granted. And to the people who hire, fund, and support them — odds are, a platform engineer requested this tune for you. I’ve spent more than a dozen years building platform teams at five different companies. The dilemma below followed me to every one of them.<br>Platform teams start as an act of mercy. Some app team is drowning (a team can’t prioritize well when it owns too many domains), so the dependency gets externalized. They focus on their deliverables. You take the plumbing: a never-ending well of problems, bugs, and feature requests that was distracting them from shipping.<br>Then the platform team succeeds, which is how the trouble starts. Other teams need the same thing, so you take on more tenants. Scope creeps. At first you did plumbing for one team you shared a skip-level with; pretty soon you’re doing it for a dozen teams with no shared management chain at all. Each re-org is a priority shift with a new skip level, a different charter, and a new way of doing things. It’s chaotic, and the shit rolls downhill.<br>So here’s the deal you’ve signed: when the platform works, it’s thankless, unless you manage up relentlessly, report your successes, and quantify your impact. When it breaks, it’s your fault. You can point at the infra team below you, the cloud provider, the upstream tool owner, or the tenants holding it wrong. Doesn’t matter. It’s still your problem. But capitalism is the voluntary exploitation of labor, and you volunteered.<br>And yet I keep signing up for another tour. That’s the part that needs explaining.<br>Nobody Ever Asks for TLS<br>Tenants running GPU jobs and CI pipelines do not ask for TLS. The occasional web app team needs it for their site, sure, but the end-to-end encryption requirement almost always arrives from InfoSec, not from anyone who’d call themselves a user. Nobody has ever churned off of TLS.<br>What tenants actually ask for is a Harbor registry, local to every cluster, to use as a pull-through cache, because image pulls are slow and egress is expensive. A totally reasonable request.<br>What they don’t know is that Harbor is a beast: a highly available, scalable, distributed system all by itself. And it wants TLS. Technically it runs over plain HTTP, but then every container runtime on every node needs an insecure-registries override: a fleet-wide config push that trades a cert problem for a man-in-the-middle problem. InfoSec would like a word. “Local to every cluster” means a new Harbor in every environment. And when you run a dozen clusters across a dozen datacenters and clouds, provisioning certs for all of them through ServiceNow tickets gives you a headache just thinking about it. So does rotating them yearly. Or on-demand, every time something leaks. InfoSec already has TLS infrastructure, but it wasn’t designed with another layer of tenancy in mind. So you start designing your own, and suddenly you’re neck-deep in certificate authority chains, debating whether you need a signing ceremony and a safe for the root keys.

Press enter or click to view image in full size

But the tenants wanted the cache yesterday. So you ship a single Docker registry in a pod on a persistent volume, self-sign the cert, and push it to every client node with Ansible, because that’s way easier. The pain is relieved. The debt is borrowed. Everybody forgets about it. Which is exactly what a time bomb sounds like before it goes off. Besides, you’ve got bigger fish to fry: the tenants need an object store, to cache from S3 and dodge the egress bills. That one needs encryption in flight and at rest, by the way.<br>Nobody ever asks for TLS. Everything they ask for is made of it.<br>Product Standards, Plumbing Budget<br>Here’s the dilemma, named: platform teams are held to product standards on a plumbing budget. The expectations are real product expectations. Docs like Stripe’s. Onboarding like Heroku’s. A roadmap, a support rotation, adoption dashboards, maybe an internal NPS survey if somebody just got back from a conference. Actual product teams generate those things with PMs, designers, tech writers, developer advocates, and a marketing budget. You get six engineers, a pager, and a Confluence space named...