How to Build the Best Platforms for Software Engineers

In plain English

Platform engineering means building an internal “platform”: a shared set of tools and shortcuts that lets software developers get their work live without each team wiring up servers, security and deployments themselves. Adnan and Jelmer argue it should be run like a product, with the developers as its customers.

A good platform makes the common path quick and self-service while still letting people step off it when they need to. A bad one adds awkward layers nobody wants, and Jelmer says having no platform at all beats having a bad one.

Three ideas worth keeping

• Start when growth stops paying off, when adding people no longer means shipping more, and begin with one person fixing the single biggest hold-up.
• Measure before and after, for example how long a new starter takes to reach their tenth piece of shipped work, plus a short monthly survey.
• Make everything self-service and let teams add support for their own tools, so the platform team never becomes the new queue.

What it means for your business

Developers spend only a fraction of their time writing code; much of the rest goes on waiting for approvals, tickets and handoffs to get work live. Making the AI write code faster does little if that waiting stays the same.

Ask your team where work actually gets stuck, put a number on it, and fund fixes in small steps that show progress, not a two-year build. Without a baseline you cannot tell whether the spending worked.

What it means for software teams

Tell the platform team about your problems, not your preferred solutions, for example “getting a new service live takes three weeks”. Early adopters and loud critics are the most useful testers, so bring them in first. Keep a clear, approved way to step off the standard path, or people will quietly use unofficial tools instead.

What we found, and what we did

We agree most with their point about measuring first. We once had a 15-task plan to speed up our own pipeline, measured three days of real data instead, and found about 60% of the automated test runs were wasted re-runs, so the fix was two moves, not fifteen (We Were the Bottleneck).

We built our own paved road on our own platform, Mibble: one set of checks for every change, a queue that lands changes one at a time, automatic deploys once a change merges, and a weekly job that re-measures speed against a fixed baseline.

That road has taken us from about 20 changes a day in September to about 45 a day now, with people approving under 10% of them instead of about 70%.

We also learnt to design for real conditions: when the test system shared one busy machine with our agents, a 5-minute check took 53 minutes. Our guide What Platform Engineering Is, and How to Ship Daily sets out the approach.

Worth watching

• 04:31: why a bad platform is worse than none, and the case for escape hatches.
• 18:54: practical ways to measure a platform, including time to a new starter’s tenth pull request.
• 38:08: how self-service and shared code stop the platform team becoming a bottleneck.