As organizations invest in platform engineering, the challenge is no longer simply building internal tools. It is creating platforms developers actually want to use — systems that reduce friction, improve governance, and help teams ship software faster without working around approved processes. In this Q&A, Syntasso Co-Founder and Chief Operating Officer Paula Kennedy discusses what it means to treat internal platforms as products, how leaders should measure value, and why AI-assisted development could make strong platform foundations even more important.
With over 20 years of experience in tech working for VMware, Pivotal, CloudCredo, and more, Paula is part of the organizing committee for DevOpsDays London, Kubernetes Community Days UK, FastFlowConf, and the London Platform User Group. Paula is also an Ambassador for Open UK, a Team Topologies Advocate, and a regular speaker at several conferences and meetups. In her spare time, Paula enjoys walking her dog and training for half-marathons.
When organizations say they are investing in platform engineering, what should that mean beyond building internal tools?
Platform engineering is much more than building internal tooling. The real goal is creating a sustainable operating model for software delivery. An internal platform should reduce cognitive load for developers, improve governance and security by default, and enable teams to deliver value faster without reinventing the same infrastructure patterns over and over.
The most successful organizations treat platform engineering as an organizational capability and not simply a tooling exercise.
What are the clearest signs that an internal developer platform is being treated “as a product” rather than as a one-off engineering project?
One of the clearest signs is that the platform team behaves like a product team. They actively research developer needs, prioritize based on user feedback, publish roadmaps, measure adoption, and continuously improve the experience. Platforms should solve problems for the platform users so that they genuinely want to use the platform instead of it just being a company mandate.
How should platform teams measure value in ways that matter to both developers and business leaders?
Platform teams need to connect developer productivity improvements to business outcomes. Metrics like reduced lead time to production, faster onboarding, lower operational overhead, improved reliability, and stronger security compliance all help demonstrate value.
Developer satisfaction is also important because poor developer experience often becomes a hidden cost to delivery performance and retention, and can lead to developers working “around” the platform and using shadow IT.
What are the most common gaps organizations discover when they try to move from traditional DevOps practices to a more formal platform engineering approach?
DevOps practices haven’t gone away; they have simply evolved. Developers are still writing and running their code, and the platform just abstracts away some of the complexity that they previously had to handle. And platform engineers are also writing and running their code as they build and develop the platform.
One anti-pattern we’ve seen as organizations try to implement platform engineering practices is the “portals and pipelines” approach. This is where teams try to coordinate their existing tooling by building or buying a portal that promises to integrate with everything, but it quickly becomes a thin veneer over the underlying tooling, policy, and processes that need proper enterprise orchestration.
The most important takeaway from a strategic platform engineering standpoint is planning not just for day one of the platform, but also day two and day 2,000.
What role should developer experience play in platform engineering decisions, and how can teams avoid assuming they know what developers need?
Many platform teams assume they already know what developers need since they’re engineers building for engineers. Effective teams continuously gather feedback through interviews, usage data, internal communities, and direct observation of workflows.
We’ve also seen great success when platform engineers and developers try to “walk a mile in another person’s shoes,” either through short-term team rotations or pairing. Building empathy across the teams enables deeper understanding, and treating developers as customers improves the quality of the platform.
What mistakes should organizations avoid when launching or scaling an internal platform?
One of the biggest mistakes is trying to solve every problem at once. Successful platforms typically begin with a focused use case that addresses a clear developer pain point and demonstrates value quickly.
Another common mistake is prioritizing technical sophistication over usability. Developers adopt platforms that reduce friction and make delivery easier.
How should leaders think about adoption? What makes developers choose to use a platform rather than work around it?
Adoption should be viewed as a platform-as-a-product challenge, not a compliance exercise. Developers choose platforms that save time, reduce operational burden, and improve day-to-day workflows. Strong onboarding, self-service capabilities, reliable documentation, and responsive support all contribute significantly to long-term adoption and trust. Leaders should focus on making the right path the easiest path.
Looking ahead, how do you expect platform engineering to change as AI-assisted development, automation, and increasingly complex cloud-native systems reshape software delivery?
Platform engineering will become even more important as AI-assisted development accelerates software creation. In fact, my colleague, Daniel Bryant, recently posted about this on LinkedIn, highlighting how AI is likely to dramatically increase the volume and speed of software delivery, but also the operational complexity that comes with it.
In a nutshell, AI tools may boost developer output, but that also increases the need for strong operational guardrails, governance, and standardized delivery workflows. Internal platforms will need to provide the secure, observable, and compliant foundations that allow organizations to scale as if they had suddenly employed hundreds of productive new engineers.
As a result, platforms will need to be self-service (via API, MCP, etc.), policy-aware, and fleet-managed by design. They will also need to support collaboration with and contributions from both humans and AI systems.
The pace of learning and iteration throughout an AI-enhanced organization will come as a shock to many. The platform will need to evolve rapidly to support this.
This Q&A is excerpted from “Platform Engineering and DevOps,” published by TechRepublic’s sister site, DZone. Download the free report to read more expert insights on how internal platforms, developer experience, and modern DevOps practices accelerate software delivery, or explore our DZone archives.
Read the full article here
