The best platform engineers I’ve worked with built things nobody used. Not because the tech was bad — it was often genuinely excellent. Because adoption was never the plan.
Platform teams have a specific failure mode that product teams don’t: they can succeed technically and fail completely. A product team that builds something nobody uses knows they failed. A platform team can build something nobody uses and genuinely believe they did good work — because the architecture is sound, the APIs are clean, the tests pass.
The platform trap
Most platform teams are rewarded for technical output: services built, APIs shipped, infrastructure provisioned. Not for adoption. Not for developer satisfaction. Not for the velocity improvement in the product teams they’re supposed to enable.
This creates a trap. The team optimises for what it’s measured on — technical quality — and loses sight of the actual job: making product teams faster.
Platform success is a product problem
When I built the platform organisation at slice, the first question I asked wasn’t “what should we build?” It was “what is slowing product teams down right now, and how do we know?”
We ran structured interviews with every product team. We asked about their friction points, their workarounds, their hidden costs. We treated engineers like users — because they are.
The list we got back was humbling. Half the things we were planning to build weren’t on it. Several things we hadn’t considered were urgent. One team had built their own internal tooling to work around something we’d shipped six months earlier because it didn’t fit their workflow.
The metrics that actually matter
Time to production for a new service. If you’ve built a great platform, this number should be falling. Measure it.
Platform adoption rate. What percentage of teams are using each platform primitive? If it’s low, that’s your problem to solve — not theirs.
Developer satisfaction. Not a survey. A conversation. Ask product engineers directly: is the platform making your job easier or harder this quarter?
Running a platform team like a product team
The structural change that made the biggest difference: I started treating platform features like product features. User stories. Acceptance criteria. Defined by the need, not the implementation. Each platform primitive had a defined audience, a problem it solved, and a success metric that wasn’t “we shipped it.”
Platform work is fundamentally a product management problem wearing infrastructure clothing. The teams that figure this out build things that actually get used. The teams that don’t build technically impressive things that sit in internal documentation nobody reads.
Your platform’s success metric is not the platform. It’s the velocity of the teams it enables.