Platform engineering rarely stalls due to technology; it stalls because of change management or because organizational misalignment prevents platforms from getting started.
If the platform is built without user research or empathy for the application developers, it solves problems that don’t exist while ignoring the ones that do, leading to poor adoption.
Donnie Page, solutions engineer at Itential, notes that system complexity and learning curve are common non-technical reasons internal platforms fail to gain adoption.
“Traditionally, platform tools require users to learn a specific language to provide the most impact or are overly complicated, where only a small subset of the organization can use the platform effectively,” he says.
Page adds that platform ownership within a specific domain can also limit the adoption of the tool within the specific domain.
“Inconsistent standards or patterns across the organization can lead to ineffective patterns or pattern bloat depending on the number of teams involved,” he explains. “Standards and patterns should provide effective guardrails to 80% of the use cases within an organization.”
Starting small, proving value with pilot teams, and treating developers as customers are what drive organic adoption in large enterprises where mandates don’t scale.
Mandates, Top-Down Rollouts Backfire
Dmitry Chuyko, performance architect at BellSoft, points out that even well-designed platforms face human resistance.
“Developers are opinionated,” he says. “Some have a ‘we know better’ mindset and refuse to adopt standards. Others fear losing familiar tasks and autonomy.”
When these individual blockers combine with organizational dysfunction, adoption fails regardless of technical quality.
Pasha Finkelshteyn, developer advocate at BellSoft, says mandates can also sever the feedback loop between the platform builders and the users, as leadership making platform decisions often lacks the low-level technical context regarding technical trade-offs and legacy constraints.
“Without that feedback loop during planning, rollouts hit walls the leadership did not anticipate,” he cautions.
Furthermore, mandates strip engineers of their autonomy. This typically leads to shadow IT or malicious compliance, where teams technically use the platform but hack around it to get their actual work done.
“You end up with the worst of both worlds: the platform’s overhead plus the workarounds’ technical debt,” Finkelshteyn says.
Kevin Reeuwijk, principal architect at Spectro Cloud, says it’s important to remember that launching an internal platform is like any change management.
“Your users need lots of communication and enablement, way more than you might expect — a single email, Slack message or Confluence page won’t cut it,” he says.
Identify the Right Pilot Groups
Reeuwijk suggests selecting a handful of teams to work with first, getting their buy-in, letting them become champions to evangelize for you, and getting some proven success metrics–time saved, pain avoided–that can be used to catch the attention of other teams.
“Expecting organization-wide adoption overnight is naïve,” he says.
Finkelshteyn recommends starting with early adopters who have high pain tolerance and a genuine need, teams actively struggling with problems the platform solves.
“Choose carefully,” he adds. “You want representative workloads running real production code, not toy projects, that won’t stress-test the platform.”
Crucially, the pilot team should be vocal and willing to provide tight feedback loops to iterate on the product.
Page recommends allowing teams to utilize tools they are familiar with that are standard in their domain without forcing them to learn new tools.
“Building an organizational structure that allows input from architects, creates cross-domain standards that are vetted and incorporates domain expertise into a platform team that can be the voice for those specific domains,” he says.
Speed Wins First
When lead time drops from days to minutes, when code-commit reaches production in a coffee break instead of a sprint, developers adopt voluntarily.
“They want their features shipped faster,” Finkelshteyn says. “Speed wins first.”
He adds quality of life wins second—this means fewer production incidents, reduced after-hours pager duty, faster incident resolution with less required staff.
“When platforms eliminate issues that bothered teams forever, even skeptics pay attention,” he says. “Less distraction means better satisfaction.”
Reeuwijk points to time-to-onboard and the reduction of incidents as metrics that have a strong resonance with a skeptical team.
“If the platform enables new employees to deploy code more quickly or reduces the burden of on-call work, the news spreads quickly,” he says.
Success stories related to the usage of the platform, such as the reduction of deployment time by 50% or the reduction of debugging time by half, generate real momentum.
“For the developers themselves, rather than senior leadership, it’s all about quality of life and enabling them to focus on code, not infra plumbing,” he says.
A key indicator is also the quality of support. If people can ask someone a question when they get stuck, with enough ambassadors available to get people going in the early stages, this prevents people from giving up in frustration.
“People can be open to try something new, but trust is fickle in the beginning and having someone close to the user group that can answer early adopter questions makes all the difference,” Reeuwijk says.