Platform Engineering: From rainbow team to mature platform
A survey of platform experts shows how the Platform Engineering Maturity Model supports teams in practice.
(Image: Wallenrock/Shutterstock.com)
- Julia Hahn
With the Platform Engineering Maturity Model, the Cloud Native Computing Foundation (CNCF) aims to provide concrete support to organizations on their way to a developer platform that functions as desired. The motivation and theory behind it have already been explained in the article Platform Engineering: Fitness plan for developer platforms. In the following, various platform experts comment on how well the model is implemented in practice.
During KubeConEU 2025 in London, I conducted a survey on the practical application of the Platform Engineering Maturity Model in order to find out what current challenges and trends the participants currently see in platform engineering. Further questions on the core aspects of the Platform Engineering Maturity Model (Investment, Adoption, Interfaces, Operations and Measurement) were intended to show which goals platform teams are striving for and which maturity levels (Provisional, Operational, Scalable and Optimizing) they are concerned with.
Videos by heise
The results of the non-representative survey provide a picture of the mood and give a rough impression of the status quo of platform engineering in many organizations.
Platform teams struggle with excessive demands and a lack of clarity
One central challenge emerges time and again: platform teams are overloaded with all the tasks that pile up around them because they are responsible for too many functionalities. "I heard a platform engineer say that he calls his team the rainbow team because they unite all the colors under the sun, so to speak. What he means by that is they have too many different tasks and they still try to do everything right. But they end up getting trapped and stuck working on the platform as well as maintaining it," explains Abby Bangser, Principal Engineer at Syntasso. She is part of the group that developed the Platform Engineering Maturity Model.
The large number of platform functionalities leads to considerable additional work for the responsible teams. Till Adam, Cloud Platform Engineer at dmTech, for example, cites "too much operation (Ops)" as the biggest challenge currently facing his platform team. A decisive factor here is – as described in the Platform Engineering Maturity Model – the platform interface for providing functionalities. Although some interviewees are already working on a self-service approach, they often still retain dependencies on the platform teams due to manual steps within their provisioning processes.
(Image:Â CNCF)
Another complicating factor is the aspect of the adoption strategy. Often, only the platforms provide infrastructure for application teams. This means that the platform inevitably has to offer more functions and support more users. Gabi Beyer, Sustainability Engineer at re:cinq, is certain about the adoption strategy of her platforms: "The application teams have no other choice. The platform is already firmly integrated into their workflows."
For Abby Bangser, one reason for the many platform functions for which she is responsible is the unclear definition of the term platform: "the confusion that has arisen because the terminology and marketing and language around platforms all seem very similar. But when people actually pick up the products, they suddenly look very different. There is therefore uncertainty about what exactly platform engineering is, which products belong to it and how they work."
Lack of willingness to invest and lack of success metrics for platform teams
While platform teams complain about too many different responsibilities on the one hand, they also lack the necessary investment on the other. "Companies are usually unwilling to invest [in platforms] and see no benefit in them, preferring instead to outsource, for example," Philip Welz, Cloud Solution Architect at White Duck, is convinced. Gabi Beyer has also had similar experiences in previous platform projects: "When I joined the project, there were not enough resources. There was only a separate CI team (Continuous Integration) with two employees and a platform team with two employees."
One reason for the lack of willingness to invest may be that many platform teams still find it difficult to measure the success of the platform. Although they usually collect metrics on an ad hoc or consistent basis, as described in the Platform Engineering Maturity Model, there is often no agreement on what exactly needs to be measured in order to check the successes of the platform that are relevant to the business area. Till Adam admits: "We conduct a survey once a year to find out how satisfied users are. But that is of course relatively anecdotal if you ask people: How satisfied are you? Then five people come forward who are satisfied. Then everything is great."
Even if the will to invest more is there and the organizations solve the problem of too small platform teams, another challenge remains: know-how. "One of our biggest challenges at the moment is scaling our team and hiring people who are not only cloud-native but can also code – because that's what we're looking for in our platform team," says Miles Bryant, Staff Engineer Platform at Monzo.
Artificial intelligence as both a solution and a problem
In order to solve the problem of too small platform teams in the long term, many organizations are adopting a general trend in the IT industry: Artificial Intelligence. Platform teams are increasingly trying to incorporate AI into their work processes. Miles Bryant also confirms the trend towards the increased use of AI, but also warns of potential dangers: "We're starting to differentiate between companies that are simply incorporating AI wherever they can, just because they think they need it, and companies that are thinking a little more deeply about how they can make the best use of AI."
In the former case, companies risk only tackling the symptoms caused by platform teams that are too small. On the other hand, AI can also help to further escalate the underlying problem. According to Abby Bangser, it also expands the scope of responsibility of platform teams: "We should then no longer just provide AI to developers as platform functions, but also introduce the ability to host AI applications and the associated tools." In this case, the trend towards greater use of AI paradoxically places an even greater burden on platform teams, as the knowledge and skills for this usually have to be built up first, without there being more staff.
Platform-as-a-Product as a bridge to the business unit
To solve the problem of a lack of investment readiness in platform teams, some organizations are taking a path that is derived from the maturity levels of the investment aspect of the Platform Engineering Maturity Model: the product approach (see Figure 1). Gabi Beyer at re:cinq, for example, has had good experiences with this: "Part of our work involved [...] transforming the platform team into a product team so that it can be treated like a product – in line with all other product teams. We've found that it's much easier to get the business on board with platform development when it's a product because you can plan things better and get all the other teams more involved. You still need more man hours and human resources, but that commitment makes it easier to align the budget."
The trend towards Platform as a Product also reflects a change in the way teams view their platforms. It is no longer primarily about providing a collection of tools; instead, the platforms should deliver clear added value for users. Till Adam is convinced that the focus on product understanding also helps to popularize the platform within the company, for example. The added value of the platform thus becomes a decisive factor, but one that also needs to be measured. However, the metrics also benefit the team when communicating about its platform – to business unit managers, for example. This can also lead to greater internal appreciation.
At best, this appreciation even goes so far that users see themselves not just as customers, but as part of the platform. In the Platform Engineering Maturity Model, this corresponds to the "Adoption Participatory" strategy (see Figure 1). "Everyone at Monzo can contribute to many of the higher-level, user-oriented aspects such as tools, interfaces or dashboards," says Miles Bryant. "We have an open code base that anyone can use to view and extend the code. And in fact, many of the best tools we have on our platform were originally just a side project of an application team, but then became a company-wide tool."
With courage and joy to greater maturity
The survey of platform experts makes it clear that many organizations share the same or at least similar challenges along the maturity levels of the Platform Engineering Maturity Model. Most of the respondents were found to be in the second or third maturity level across the individual aspects. As one of the authors of the model, Abby Bangser expresses her delight about this: "I find it exciting that many people placed themselves in level 2 – and did so with pride, or at least with joy. This proves that many are using the model to honestly understand where they stand, and not just to prove that they are better than everyone else."
However, the survey also suggests that many companies and teams are not yet satisfied with the level of maturity they have reached and are striving to reach the next level. Above all, this requires clear responsibilities, user-centered thinking and measurable added value. Progress is visible – but it takes time, the courage to focus and, above all, a shared understanding of what "good platform work" actually means. The Platform Engineering Maturity Model helps with this.
(map)
