Enterprise Platform Teams Are Stuck in Day 2 Hell

Editor’s note: This article was written by the author on behalf of PlatformCon.

LONDON — It’s Day 2 for many platform engineering strategies, and many organizations are still striving to achieve Trifork CTO Nicki Watt’s definition of a great internal developer platform (IDP): “A great platform achieves the objectives that the business is trying to do.”

And they’re trying to achieve this while the platform has emerged as an essential enabler of AI impact.

Watt and her panel mates were asked what makes a great platform at PlatformCon 2025 here.

One platform engineering best practice, according to Rickey Zachary, global lead of platform engineering at Thoughtworks, is to treat the platform like it’s an internal Software as a Service (SaaS) product. This is called a platform as a product approach, from ideation and prototyping to deploying and marketing to rapid feedback and roadmaps, where you treat your internal developers as your customers.

Platform team members are essentially product managers, noted  Cornelia Davis, senior staff developer advocate at Temporal Technologies: “They recognize that it’s not just about automation, but it’s about contracts between the platform engineers and the application teams.”

Indeed, these do sound like qualities of a great platform engineer. But they aren’t exactly concrete ideas. And, based on those definitions, only about 10 out of 650 attendees raised their hands to say they think they have great IDPs.

An overarching theme of PlatformCon 2025 was that, as an industry, we are pretty sure we know the what and the why of platform engineering, but now we need to figure out the how. That means platform strategy, accountability, how to measure and iterate on success — all within large enterprises. Read on for some ways to go from patching up roads to laying down golden paths.

How Enterprises Can Get Past Platform Day 1

One way to look at platform engineering is that it’s an enabler for teams to move fast without going off the rails. Because you simply can’t break things, especially in well-regulated industries.

At most enterprises that Eric Paulsen, field CTO at Coder, works with, he’s seeing the same three impediments to platform success:

• A lack of focus on developer productivity.
• Unstructured provisioning and infrastructure drive inefficiency.
• The continued rise of cloud costs.

These factors don’t occur in isolation. As Davis pointed out in the opening panel, digital native organizations — those conceived as cloud native from Day 1 — are winning the platform engineering game. But what about the rest? What about those accidental tech companies — in banking, automotive and health care — trying to compete and move fast in the well-regulated world?

“We are among the largest banks in the world in terms of market cap, but with that comes a legacy. We have tech debt, we have complexity,” Gavin Munroe, CIO at Commonwealth Bank, said on the PlatformCon London stage. “Being a regulated entity, we have a very thorough, overzealous control environment. And obviously, the burden of release and change.

“We realized we had to change everything. You can’t just go and solve the input or the coding. That’s just moving the bottleneck down in the organization.”

Munroe’s organization of more than 15,000 engineers was facing a highly customized stack — or, really, scattered tool sprawl — and a culture of team autonomy that led to at least 100 different paths to production. To lay down platform pathways, he said, his organization had to first pursue standardization.

Then, Commonwealth Bank pursued a cross-organizational platform engineering strategy with automation, traceability, and an agentic AI-based, nondeterministic release path.

Together with humans consistently in the loop, his team was able to increase deployment frequency by more than 20% and decrease mean time to recovery (MTTR) by 40%.

Commonwealth isn’t that unique. No well-regulated industry is. These traditional businesses have to unlock innovation to compete with newcomers, but they also have to prioritize security and uptime.

“I sometimes feel like we in the platform engineering community over-rotate on developer experience and developer happiness,” Davis said, when “there’s a whole host of other challenges that platform engineering can help with.”

One impetus for the rise of platform engineering is a pushback to DevOps’ idea of you build it, you run it. For most highly regulated organizations, that’s too much autonomy. So platform teams must find the right level of abstraction, she said, like how to deliver Kubernetes capacity.

This is first and foremost a security and then scaling concern, before teams should focus on developer experience.

“If security is one of your concerns, then perhaps what you’re looking at there is defining the level of abstraction at the right level so that your platform teams can take your security concerns, instead of the application teams all individually doing that,” Davis said.

Platform as the Foundation for AI

Automotive is another one of those industries that was built about 100 years before the internet, but is very much at the forefront of AI and data in motion.

Boyan Dimitrov spoke at PlatformCon London about his journey over the last decade from director of platform engineering up to CTO at Sixt. Somewhere along the way, this 113-year-old mobility service provider grew into a tech company that ended up building about 95% of its software in-house. And yet, its developers were stuck only releasing once, maybe twice a month.

Dimitrov’s team had to figure out how to more effectively serve 800 engineers, data scientists and AI operators while also serving the regulatory and business stakeholders. All while trying to adapt to become an AI-first organization.

“We have a very complicated business with different requirements that each engineer has to send business while doing stuff, and on top, they have to build, maintain, get CI/CD pipelines in, and figure out how to monitor,” Dimitrov said. “We were thinking, if we can build that abstraction, if we can build those tools that can help in day-to-day and make it seamless, then we can keep our engineers focused on business.”

With such a breadth of software, plus regulations of 105 countries and 5,000 pages of internal business guidelines, evolving the internal developer platform and preparing it for AI came down to starting to make some choices.

“We have to look forward. We have to make sure that anything in terms of efficiency we save, we pass it onto our customers,” Dimitrov said. “It’s not easy to automate, it’s not easy to manage, because there’s just so much of it, and if we let it grow out of proportion, then we lose on that cycle time from complexity,” and things become fragmented again.

As stewards of the platform, he said, his team of 40 platform engineers has to decide what’s good for both the technical and business organizations, making sure technical choices solve problems for more than one team.

“We invest heavily in design systems so that we can bridge design, engineering, and platform. All those layers are allowing us to simplify and automate,” Dimitrov said, including 200 cloud infrastructure accounts, Kafka clusters, internal developer portals, scaling pipelines and other foundational activity. Sixt also has a platform engineering insights team looking after application libraries, as well as a team in charge of governance, security, observability, reliability and platform onboarding.

“At Sixt, we don’t stop at the infrastructure layer or the build pipelines or observability pipelines, which is, I guess, what we must think of when we speak platform engineering,” Dimitrov said. “We also have much deeper penetration in our application stacks in terms of instrumentation [and] how we inject certain platform things in our templates, etc.

“There is a team that’s doing that, plus they’re also building all our core services when it comes to service discovery, or how service communication goes, or how we expose things to the internet or internally, so all of that is automated within that space.”

The Sixt internal developer platform is responsible for the foundational path mission entity, encompassing the full backend and back office systems, all with a strong focus on meeting the automotive industry’s needs.

Myths and Paths to Production

The next step is to measure and understand your platform strategy and how it benchmarks with the industry.

Sarndeep Nijjar, CTO of ClearRoute, presented findings from the platform engineering consultancy’s “State of the Route to Live” report. This 2025 report assessed 30 different enterprises against three tiers of metrics:

• End-to-end route to live: Evaluating from ideation to production with six metrics: lead time to production, defect rates, change failure rates, deployment frequency, pipeline reliability and regression testing.
• Team dependencies: Team involvement per change that the outer-outer loop of software development intersects with, including testing, governance, change advisory boards, compliance and cybersecurity, each of which triggers significant delays.
• Individual team bottlenecks: Assessing toil, tooling and developer efficiency against the impact of testing automation, deployment processes, environment and test data management.

These measurements emphasize how foundational software engineering practices need to be laid down before you can scale, especially if you are increasing the size of your codebase with more AI-generated code.

Just about every organization ClearRoute evaluated shared the same challenges:

• Slower time to market with manual gates.
• Brittle test suites that mask defects.
• Issues with environment availability.
• Software teams lack insight into the business value they’re meant to deliver.

All of these cross-company hold-ups are consistent across the software delivery life cycle. The team at ClearRoute uncovered five common myths — and the corresponding realities — that persisted across all enterprises interviewed:

• More process means more safety. In reality, you need better governance, not more.
• More quality assurance means better quality. In reality, organizations need to focus on reliability, with testing automation strategically throughout the software development life cycle.
• Microservices are faster. In reality, a microservices strategy is necessary to avoid just becoming distributed monoliths.
• Software is focused on business delivery. In reality, tech teams are often siloed from business objectives. Organizations need to be more intentional about business alignment.
• Developer experience doesn’t matter. In reality, developer experience (DevEx) is a proven performance lever, not just a perk. The report found that investment in DevEx led to a tripling of deployment frequency.

These are challenges that the platform engineering team typically aims to solve, as it bridges the gap between business and technology. An internal developer platform can be an enabler to debunk those myths, to invest in developer experience, and to build guardrails that make it easier to deploy faster with the right governance and quality checks.

Platform Teams Strive for Balance

“Platform teams are surrounded by other teams that kind of look like platform teams, but are entirely different,” warned Gregor Hohpe, author of “Platform Strategy: Innovation through Harmonization.”

Never without a mile-long backlog, platform engineering teams are faced with broader expectations than most. They are asked to find the use cases to empower reuse and economies of scale, on increasingly tight budgets. But then these teams also need to meet the demands of economies of speed, enabling their internal developer customers to deliver value faster.

Cloud computing providers — as the ultimate hyperscalers (hence the name) and speed enablers, Hohpe said, are the best example of this. But, unlike a cloud provider, a platform team cannot cover all use cases at all companies and shouldn’t — it has just one organization to serve, enabling scale underneath and speed on top.

“It’s all about shrinking the diversity” of services offered, Hohpe said. “And don’t do anything too fancy. Make it simple, make it reliable. You need to counter-steer the temptation to anticipate all needs.”

Otherwise, you risk putting up too many roadblocks that stifle innovation.

“You tell developers that if you want [to get on] the super highway, there will be some guardrails just in case,” he said. “A guardrail is not a steering mechanism. A guardrail is an emergency device that hopefully nobody ever hits.”

But a platform engineering team knows that speed can only come at scale if security and privacy are in place. Not to stifle innovation, but to impede disaster.

Hohpe continued the driving metaphors: “The objective of the platform is to keep the projects on track to keep them in lane. Hitting the guardrail is a success, in a way, because they didn’t go off the cliff, but it’s also a failure because your car was wrecked and the guardrails, [too]. So you want Lane Assist. You want transparent feedback for the teams, early warning signals. You want teams to autocorrect and stay in the lane.”

Finally, Hohpe brought the focus back to the ever-present debate about where to put the abstraction layer, which further differentiates platform teams from other shared-service teams.

“IT services live in the technical domain and platforms deliver a slightly higher domain because they want to make abstractions to reduce cognitive load,” he said. “Platform teams have one big advantage in that you only have to build for your business — you don’t have to build for the whole world,” which makes for a much more surmountable challenge than cloud hyperscalers have to address.

“By understanding your domain, you can start making higher-level services that blend business domain and technical domain,” he added, giving the example of how a platform team can make an organization’s database a shared service that is still unique to your domain, your local regulations, your internal developer customers and your external customers’ data.

Then,  he said, “you really add value.”

And remember, Hohpe said: you are there to enable speed and innovation. “Have your users done something you did not anticipate? That’s what you want.”