Estimated reading time: 7 minutes
Key takeaways:
- Low adoption can be a trust problem and not just a communication issue.
- Training doesn’t fix broken trust. The real question is ‘what would make a skeptical engineer choose this again?’
- Trust can come back through observing teams, opening the roadmap, and owning the failure, not new features.
Eight months into building an internal machine learning (ML) platform, I asked three senior engineers to show me how they deployed a model. None of them used the platform.
Two had built their own tooling. The third was running notebooks manually against a cloud environment that had not been provisioned for production. These were experienced engineers who understood the risks. They also understood our platform, and they had decided that working around it was easier than working through it.
We had built something technically solid. It offered the controls, repeatability, and shared infrastructure we believed teams needed. Yet the people it was meant to help were avoiding it. I initially treated that as an adoption problem. It was really a trust problem, and recovering from it required leadership changes before it required more platform features.
Your inbox, upgraded.
Receive weekly engineering insights to level up your leadership approach.
The signals we ignored and what we had actually built
Platform adoption rarely collapses in one dramatic moment. More often, the evidence arrives as a collection of signals that are individually easy to explain away.
We had low usage, recurring support questions about core workflows, and engineers asking for help with steps the platform was supposed to make self-service. We interpreted each signal generously. Teams were busy. They needed more training. Their managers had not created enough time for migration. The organization was naturally resistant to change.
The meeting with the three engineers happened eight months into the build. We still spent much of the following year treating behavior as a communication problem instead of product evidence. That experience is not unusual.
In the 2026 State of Platform Engineering findings, 45.3% of platform teams identified developer adoption as a leading challenge. The statistic is reassuring only up to a point. A common problem is still a problem.
Our deeper mistake was that we had built the platform for the people who designed it. The team valued clean abstractions, an opinionated workflow, and strong reproducibility controls. Those were reasonable engineering goals.
However, we had packaged them around how platform and ML engineers thought work should proceed, not around how product engineers were already delivering under deadlines.
For a product team, the alternative was not “our safe, automated platform versus chaos.” It was our unfamiliar workflow versus scripts and tools they already understood. Their workarounds created duplication and operational risk, but they were also transparent, controllable, and available immediately. We were asking teams to absorb several changes at once in exchange for benefits that appeared later.
We had confused technical correctness with user value. Worse, we treated the gap between them as the users’ responsibility.
Diagnosing a trust problem, not an adoption problem
Our first response was predictable: more documentation, more training, more demonstrations, and more announcements. Those interventions can solve an awareness or skills problem. They do not repair a damaged expectation.
The product engineers were not refusing to learn. Many had tried the platform early, encountered friction, and returned to workflows that allowed them to deliver. From their perspective, that was rational. Once engineers expect a platform to slow them down, every new request to try it again carries an additional cost: they must spend time testing whether the platform has changed, while accepting the delivery risk if it has not.
Evan Bottcher writes that internal platforms must be “compelling to use” because they cannot depend on mandates alone. I had understood that idea in technical terms: provide self-service capabilities, useful defaults, and reliable infrastructure. I had underestimated the emotional part of the contract. A platform also asks engineers to hand over control of important steps in their delivery process. They will do that only if the platform has earned confidence.
That distinction changed our questions. Instead of asking, “how do we drive adoption?” we began asking, “what evidence would make a skeptical engineer choose this platform again?” The first question encourages campaigns, mandates, and feature lists. The second forces a team to examine real workflows, prior failures, and the credibility of its promises.
The Cloud Native Computing Foundation’s platform maturity model describes a similar shift from “extrinsic push,” where use depends on directives or incentives, to “intrinsic pull,” where teams choose a platform because it reduces their cognitive load. We were trying to push harder when we first needed to understand why teams had stopped pulling.
More like this
Three leadership moves that rebuilt trust
The recovery did not begin with a relaunch. It began by changing who could define the problem and how the platform team responded to uncomfortable evidence.
First, we embedded a platform engineer in product teams’ sprints – their regular delivery cycles – for six weeks. The assignment was to observe, not to sell. The engineer watched how teams moved from an experiment to a production deployment, where they changed tools, what they did when the standard path did not fit, and when they asked another person for help. This gave us information that support tickets and feature requests could not: the sequence and context around the friction.
The difference between listening and observing mattered. In an interview, engineers summarized their work. Inside a sprint, we saw the tradeoffs they made under time pressure. We could separate inconveniences from genuine blockers and identify why some workarounds were reasonable.
Second, we opened the roadmap and gave product teams a real role in ranking it. We did not ask for feedback on a roadmap we had already committed to. We showed the competing investments and asked teams to order them. Our top three priorities did not appear in their top ten.
That result was uncomfortable, but useful. It showed that we had treated customer input as one signal among many while reserving the important decisions for ourselves. Reordering the roadmap did more than improve feature selection. It demonstrated that participation could change an outcome.
Third, I told the platform team that the adoption failure was partly mine. I had allowed us to celebrate delivery milestones while treating adoption as a downstream change-management task. That framing protected the team from the harder conclusion: if engineers could not reach production successfully through the platform, the platform work was not complete.
Owning that failure was not about assigning blame in a different direction. It reset the success criteria. We stopped asking only whether a capability was shipped, stable, and compliant. We also asked whether a product engineer could use it without requiring the platform team to stand beside them.
From those moves came a different set of artifacts and measures. Engineers who had struggled with the platform and later succeeded helped write an ML Platform Handbook organized around real workflows rather than platform components. Instead of describing every feature, it followed the questions a practitioner faced while moving a model toward production.
We paired the handbook with a concrete milestone: a team should be able to move its first model to production in a day. We also made platform net promoter score (NPS), a measure of whether engineers would recommend the platform, a team metric. NPS alone can become another vanity number, so we considered it alongside the workflow milestone and direct feedback. One measure told us whether the path was getting shorter; the other told us whether confidence was returning.
The handbook was later adopted by another team for onboarding. That mattered because it was evidence of reuse without a mandate. The recovery was not a dramatic surge caused by an announcement. It was a series of voluntary choices that showed the platform had become useful again.
Spotify described a comparable lesson from ML Home. Its initial release did not grow much beyond early participants because users did not see enough depth to leave the tools they already used. After the team deepened the product around real ML workflows, daily active use roughly tripled over the following year. The details differ, but the pattern is familiar: awareness cannot compensate for a product that has not yet earned a place in daily work.
Berlin • November 9 & 10, 2026
Close the gap between what leadership expects and what’s actually possible at LeadDev Berlin.
The gap is a leadership problem
I still believe internal platforms should be opinionated. Without shared defaults, organizations recreate fragmented tooling, inconsistent controls, and repeated operational work. The mistake is assuming that an opinionated platform is entitled to adoption.
If I could advise my earlier self, I would say: do not wait for low adoption to become undeniable. Treat every workaround as evidence. Observe before explaining. Let users influence priorities before asking them to change their behavior. Most importantly, make adoption an outcome owned by the platform’s leaders, not a change-management task assigned to its users.
An internal platform is a product, but saying that is the easy part. Product thinking requires the humility to discover that a technically correct design is wrong for the people it serves. “Shipped” and “adopted” are different success criteria. The distance between them is where leadership begins.
