TCP #112: The single question that predicts platform team success
Why “can a stranger deploy without help?” predicts adoption better than NPS or toil charts.
You can also read my newsletters from the Substack mobile app and be notified when a new issue is available.
If you run a platform or infra team, you only need one question:
Can a developer I’ve never met deploy a production service without asking anyone for help?
That is it.
Not “what is our deployment frequency?”
Not “what is our platform NPS score?”
Not “how much toil have we eliminated?”
Those metrics matter. But they are lagging indicators. They tell you what your platform did last quarter.
This question tells you what your platform is, right now.
WHERE THIS CAME FROM
I started asking this question after a specific pattern repeated itself across three different organizations.
Each team had strong DORA metrics. Deployment frequency was high. Lead times were short. On the surface, the platform was working.
Then we’d onboard a new team and watch what happened. Engineers would read the documentation, hit a wall, open a ticket, wait, get an answer, try again, hit another wall, open another ticket.
Two weeks of this and they’d either give up on the platform or build their own path around it.
The metrics hadn’t lied. They reflected what existing users could do after months of accumulating tribal knowledge.
They did not reflect what the platform actually offered to someone arriving cold.
WHY THIS QUESTION PREDICTS WHAT METRICS MISS
The deployment frequency metric measures how often your most experienced teams ship.
The platform NPS score measures whether developers who already use the platform are satisfied with it.
The toil reduction metric measures how much manual work you eliminated for teams that were doing it manually before.
All three measure existing behavior in existing users.
The question “can a developer I’ve never met deploy without asking anyone for help” measures something different.
It measures the platform’s legibility to a stranger.
Legibility is the real test. Not performance. Not satisfaction. Not throughput.
If a new engineer can’t even find the path, it doesn’t matter how fast your existing teams can run it.
Not performance. Not satisfaction. Not throughput.
A platform that requires tribal knowledge to operate has a known failure mode that it hasn’t solved. Every new team that joins the organization will pay the onboarding tax. Every engineer who moves between teams will pay it again.
The tax compounds quietly. It shows up as a two-week onboarding period that should take two days. It shows up as a Slack message that interrupts a senior engineer at 2 pm. It shows up as a ticket queue that the platform team treats as normal operational load, when it is actually evidence that the platform has not done its job.
WHAT TO DO WITH THIS INSIGHT
Run the test literally.
Find a developer who has not used your platform before. Give them your documentation and nothing else. Watch where they stop. Watch what they search for. Watch what they eventually ask a human to explain.
Every stopping point is a design failure, not a user failure.
The goal is not a platform that experienced engineers find fast. The goal is a platform that a new engineer can navigate to a first successful deployment without human intervention.
That bar is higher than most platform teams think it is. Most teams build for their current users, optimizing for the paths they already know. New users are left to discover the path themselves.
RUN THIS CHECK
What to do this week:
What to do this week (30–60 minutes):
• Identify one engineer who joined your organization in the last 60 days.
• Ask them to walk you through their first deployment experience: where they got stuck, who they had to ask for help.
• Count the number of human interventions between “first commit” and “service running in production.” Each intervention is a platform gap, not a developer gap.
• Set a target: zero human interventions for a standard service deployment and track it alongside your DORA metrics.
Reducing new-engineer onboarding time from two weeks to two days returns compounding capacity across every hiring cycle. The teams that run this test consistently report that the gaps it surfaces are more actionable than any NPS survey because they are specific, reproducible, and owned by the platform team, not the developers experiencing them.
Every platform I have seen struggle with adoption had the same root cause. It was built for the people who built it. The documentation assumed knowledge that the documentation was supposed to provide. The golden path was golden for the people who paved it.
If you’re serious about how your platform serves new users, this is exactly what the Paid version of this newsletter is for.
Paid subscribers get the full Platform Team Scorecard: nine capability areas, a copy‑paste audit worksheet, and example questions you can run with your teams to find the gaps that block new engineers from shipping. You also unlock the back catalog of scorecards and implementation guides, so you’re not inventing your own framework from scratch.
If you want to go beyond reading and actually instrument your platform, upgrade to Paid and run the Scorecard with your team in the next week.
Whenever you’re ready, there are 2 ways I can help you:
Free guides and helpful resources: https://thecloudplaybook.gumroad.com/
Get certified as an AWS AI Practitioner in 2026. Sign up today to elevate your cloud skills. (link)
That’s it for today!
Did you enjoy this newsletter issue?
Share with your friends, colleagues, and your favorite social media platform.
Until next week — Amrut
Get in touch
You can find me on LinkedIn or X.
If you would like to request a topic to read, please feel free to contact me directly via LinkedIn or X.