Platform Engineering: Beyond the Trough of Disillusionment

The Reality Check We Needed

If you've been following industry conversations recently, you've likely seen Mark O'Neill's pointed LinkedIn post referencing Jennifer Riggins' article in The New Stack, suggesting platform engineering is headed for Gartner's notorious "Trough of Disillusionment." The Gartner Hype Cycle graphic prominently displays platform engineering perched at that precarious precipice, with a big red arrow pointing downward.

‍

As someone who's been in the trenches with teams adopting platform engineering practices, I can't entirely disagree with this assessment—but I believe it represents a necessary and healthy evolution rather than a death knell.

Why Platform Engineering Is Facing This Moment

The challenges highlighted by industry experts resonate with what we're seeing across organizations:

1. Measurement disconnects: Organizations struggle to demonstrate ROI and business impact, focusing instead on adoption metrics like "number of code-completion suggestions accepted" rather than business outcomes.
2. The "build your own" trap: As Paula Kennedy from Syntasso noted, "Engineers are always going to engineer." This DIY tendency leads to unnecessary reinvention, fragmentation, and ultimately, cognitive load—ironically, the very thing platform engineering aims to reduce.
3. Adoption hurdles: Platform teams build solutions that developers don't want or need, creating sophisticated tools that sit unused while developers find workarounds.

These challenges aren't symptoms of a failing concept—they're growing pains of a maturing practice.

From Platform-as-Technology to Platform-as-Product

What separates successful platform initiatives from those heading toward disillusionment? In our experience working with hundreds of engineering organizations at Harness, the answer lies in the mindset shift from platform-as-technology to platform-as-product.

This shift requires three fundamental changes:

1. Measure What Matters to the Business

ROI calculations for platform engineering shouldn't be rocket science. When we work with customers implementing Harness Platform, we focus on concrete metrics that translate directly to business impact:

• Developer time reclaimed: How many hours previously spent on pipeline maintenance, deployment orchestration, and infrastructure provisioning are now redirected to feature development?
• Time-to-production acceleration: How much faster can teams deliver value from commit to production?
• Reliability and security improvements: How have error rates, rollbacks, and incident frequency changed since implementing platform capabilities?

These metrics create a clear line between platform adoption and business outcomes, making the value proposition obvious to leadership.

Industry standard metrics like DORA and SPACE can also provide good framework for what to measure. In both cases, you are generally not measuing direct business impact but leading indicators of business impact. Platform teams need to have executive buy-in before measuring that this leap from leading indicator to business impact is going to hit the mark for the people approving budgets.

2. Embrace Composability Over Building Everything

The "build versus buy" debate misses the point entirely. The most successful platform teams we work with have embraced composability—thoughtfully selecting best-of-breed tools and integrating them into a coherent developer experience.

Harness Platform was designed with this reality in mind. Rather than forcing teams to build everything from scratch or adopt a monolithic solution, our modular approach allows teams to:

• Start with their highest-value pain points (CI, CD, feature flags, etc.)
• Integrate seamlessly with existing investments
• Expand platform capabilities as needs evolve

This approach dramatically reduces time-to-value while still providing the flexibility engineers crave.

3. Design for Developer Delight, Not Just Adoption

One of the most revealing statements from the panel discussion was Leena Mooneeram's observation: "We're incredibly lucky. We work in the same company as our customers."

Yet many platform teams fail to leverage this proximity advantage. They build platforms in isolation, then wonder why adoption lags. Platform teams fall into one of the classic traps those of us who build tools for engineers are tempted with - "I'm a developer, I know what developers want." Famous last words. Do the hard work of spending time with your teams and seeing what they really need from your platform.

The most successful platform initiatives treat internal developers as true customers:

• Conduct user research to understand pain points
• Create clear documentation and self-service workflows
• Build feedback loops that drive continuous improvement
• Focus on developer experience as a first-class concern

Beyond the Trough: The Platform Engineering Renaissance

Every transformative movement in software engineering has faced its moment of disillusionment. DevOps experienced the same trajectory before emerging as an established, mainstream practice.

At Harness, we believe platform engineering is following this same pattern. The trough represents a necessary correction—a moment for the industry to move beyond hype and establish sustainable practices.

As organizations recalibrate their approach, we're already seeing the emergence of platform engineering 2.0:

• Platform teams with product management disciplines
• Clear business outcome measurements
• Composable architectures that balance flexibility with standardization
• Developer experience as a core design principle

Accelerating Through the Trough

For organizations navigating this transition, Harness offers a proven path forward. Our platform approach enables teams to:

1. Start where you are: No rip-and-replace required. Harness integrates with your existing tools while providing a path to modernization.
2. Deliver immediate value: Pre-built capabilities for CI/CD, feature flags, cloud cost management, and security mean you can show value in days, not months.
3. Scale with confidence: As your platform strategy matures, Harness grows with you, providing the governance and security capabilities enterprise organizations demand.

Conclusion: The Future Belongs to Those Who Build Experience

Yes, platform engineering is likely entering the trough of disillusionment. But this moment of correction is setting the stage for something more valuable and sustainable. We have done the early trailblazing and found that platform engineering really works. The success stories are too plentiful to ignore. However, we have also seen enough stumbles that we are learning to be a bit more careful and disciplined in our approach. We know where the pitfalls are. What a great time time.

By focusing on business outcomes, embracing composability, and truly centering developer experience, platform engineering will emerge from this trough stronger and more impactful than ever.

The organizations that use this moment as an opportunity to refine their approach—rather than abandoning their platform efforts—will be the ones who realize the true promise of platform engineering: delivering business value at the speed of software.