The Problem
Internal platforms have a graveyard.
Every engineering organization has tools that were built with real investment, announced with real fanfare, and then quietly ignored. Usage metrics plateau. The team that built the tool writes increasingly desperate internal posts. Leadership mandates adoption. Engineers comply minimally and route around the tool whenever they can.
This is the default outcome for internal developer tooling. Most teams treat it as a communication problem or a change management problem. It's neither.
It's a product problem.
The Insight
Resistance to a tool is signal, not noise. When engineers avoid a tool, they're not being difficult — they're telling you that the tool is working against their natural workflow rather than with it.
I've spent years studying where friction actually lives in the developer experience. The answer is almost never where PMs think it is. It's not in the big visible moments — the long build, the major incident. It's in the micro-frictions that compound: the extra click to get context, the mental model switch between tools, the moment where the system asks you to remember something it could remember for you.
These frictions are invisible in aggregate metrics. They show up only when you watch someone work.
The Solution
I redesigned the platform around the natural flow of developer decisions rather than the organizational model of the platform team.
Meet developers at the moment of decision — Instead of requiring developers to go to the platform, I brought platform capabilities to the moments where developers were already making choices: PR creation, failure triage, deployment gates. The tool disappeared into the workflow.
Remove memory requirements — Every place where the system asked a developer to remember something — a flag, a config option, a failure pattern — became a place where the system remembered it instead. Cognitive overhead went down. Adoption went up.
Make the default path the right path — The easiest thing to do was also the correct thing to do. Developers who engaged minimally with the platform still did the right thing, because we designed the default behavior to be right.
The Outcome
Adoption reached 100% of global engineering teams — not because it was mandated, but because the platform was easier to use than to avoid.
The most telling signal: teams that hadn't been targeted for rollout started requesting access before we had planned to offer it.
That's what a well-designed internal tool feels like. It spreads because it's worth spreading.