Introduction

The Platform Maturity Model, drafted by Syntasso and donated to the Cloud Native Computing Foundation (CNCF) for further discussion, was designed to help organizations evaluate their capability for continuous improvement in platform engineering. Mature platform organizations are better able to respond to incidents or errors with appropriate improvements to the platform. According to this model, engineering organizations can become more mature as they align with established best practices in the discipline (such as following a platform as a product mindset) and cultivate the right organizational culture.

In Summer 2023, we asked members of the platform engineering community to respond to a short survey based on a draft of the Platform Maturity Model and our own observations from the community. Our goal was to understand the extent to which organizations follow platform engineering best practices. We received responses from 296 individuals in the platform engineering community.

The results of the survey indicate that most organizations still struggle to implement best platform engineering practices.

About the respondents

The vast majority of respondents (94.1%) reported having some degree of work from home flexibility, with 31.5% having a fully remote setup and 62.6% having a hybrid setup. Only 5.9% reported being fully on-site. The results indicate that, for organizations building Internal Developer Platforms, remote work is here to stay.

22.1% of respondents work in an organization with less than 30 developers, 41.2% with between 30 and 250 developers, and 36.8% with more than 250 developers. The size of the entire organization also varied, with 16.2% of respondents in an organization with less than 50 employees, 28.9% with between 50 and 500 employees, 39.7% with between 500 and 5k employees and 14.7% in an organization with more than 5k employees.

Results

Change readiness

If a company is willing to change, its platform engineering transformation will be easier and more successful. This is because platform engineering isn’t just about technology, it’s also about people, processes, and culture.

Establishing a platform team has an impact on the entire engineering organization. It affects developers by changing (and hopefully improving) their workflows. It also affects ops and DevOps teams, reducing the number of tickets they receive from developers. Building and using a platform means change. Organizations can assume that individuals are willing to improve and are open to change, but this needs to be managed and moderated. Thus change readiness is a prerequisite for mature platform engineering efforts.

The survey found that over a third (36%) of respondents have a strong culture of embracing change with internal change management procedures in place. 26.9% actively want change but have no policies or plans in place. 26.6% actively want change but are struggling due to weak culture around change management. Only 10.5% struggle with an organization incredibly resistant to change with a high level of bureaucracy and red tape.

Organizational buy-in

Developers are not the only important stakeholders. Successful platforms also need sustained buy-in from other areas of the organization, like management and C-suite.

37.4% of organizations reported securing full buy-in across the organization. 33.8% of respondents said one side of the organization remains a work in progress. 14.6% are relying on a single champion team, and 14.2% are relying on a single individual contributor champion.

With roughly two-thirds (62.6%) of respondents lacking full buy-in for their platform, it’s safe to say that platform advocacy is an area where many organizations need to improve.

In his PlatformCon 2023 talk “How to Communicate the Business Value of Platform Engineering,” Gartner’s Manjunath Bhat introduced a framework for platform teams to understand and successfully advocate for platform engineering initiatives:

1. Assess stakeholder priorities and concerns. This will vary depending on the stakeholder group.
2. Identify and define value enablers, or the actions the platform team takes to provide value to stakeholders.
3. Build a value map to connect value enablers to stakeholder impact. Well-defined value stories align with business objectives, address stakeholder priorities, and are easy to communicate.
4. Support the value story through outcome (not output) metrics. Output metrics optimize the flow of work, whereas outcome metrics optimize the flow of value.
5. Communicate the “why” to incentivize mindset shifts. This is what drives platform adoption and impact on the business.
6. Communicate the realized value to the organization. This can include improving customer satisfaction, boosting revenue growth, or reducing time to value.
7. Adjust and iterate.

This process helps ensure that the platform has buy-in across the organization.

Platform team structure

Organizations building a platform should avoid anti-patterns in platform team structure. “That’s an anti-pattern I’ve seen very often, where the platform becomes a bucket for everything, and just becomes a huge mess with lack of ownership, lack of focus and a lot of waste, where teams are overloaded and working on a lot of stuff that’s not really a priority,” explained Team Topologies co-author Manuel Pais with The New Stack. Mature platform engineering efforts require a funded platform team with a clear delineation of responsibility between platform and development organizations.

However, less than half (38.1%) of respondents have a platform team in line with this best practice. 26.3% have team members with platform responsibility who do not work as developers but work within operations contexts. 26.6% have some platform knowledge with responsibility divided between multiple team members in full-time development positions. 15% reported little or no platform knowledge with operations being done by developers in full-time development positions.

Platform product management

Like any other product, Internal Developer Platforms are optional to use, should be designed to be easy to use, and evolve as technology changes. Mature organizations follow a platform as a product approach to identify what features to build, when to build them, and how to get the rest of the organization on board. This includes conducting user research, creating a product roadmap, and marketing the platform internally to secure stakeholder buy-in.

This 2017 Thoughtworks Technology Radar article was the first to establish the need for platform product management. Team Topologies authors Manuel Pais and Matthew Skelton popularized a platform as a product approach a few years after. Platform product management is now regarded as so essential that Gartner VP Analyst Manjunath Bhat included it in his three key pillars of how and why to build an Internal Developer Platform: “Platform engineering teams treat platforms as a product (used by developers) and design the platform to be consumed in a self-service manner.”

This survey explored three aspects of the platform as a product approach: Identifying features, strategy for driving platform adoption, and organizational buy-in.

Identifying features

The survey found that just under a third (32.3%) of respondents follow a platform as a product approach to identify new features. 28.1% of respondents take an evolutionary approach, wherein the scope of work is defined in collaboration with users. An evolutionary approach can look like the platform team building for individual users before optimizing for wider use. 26.1% of organizations take a reactive approach. 11.6% of respondents identify new features by following a set, infrequently updated list of priorities and requirements.

A product mindset is what ensures platform teams build a platform developers actually want to use.

Many organizations believe they’ve embraced a platform as a product approach. However, as OpenCredo’s Nicki Watt illustrated in her 2023 PlatformCon talk “Why is it so hard to create a great Platform-as-a-Product,” most still fall short in important ways. For example, many organizations make more assumptions about what their internal users know, want, and need than they would about users for external products. Mature organizations treat internal users with the same care. Another common pitfall Watt identified was to mandate platform adoption. Making the platform mandatory closes off the feedback loops platform teams need to gauge the success of their efforts.

Strategy for driving platform adoption

No matter how innovative and user-friendly an organization’s Internal Developer Platform may be, “build it and they will come” is not a viable strategy for driving platform adoption. Instead, successful organizations drive adoption through specific developer advocacy and support roles.

Just over a quarter (25.1%) of organizations reported establishing platform advocacy to drive platform adoption. 20.9% reported relying on internal champions, 17.1% mandated platform usage, and 36.9% took a “build it and they will come” approach.

Developer experience

The options your organization provides for developers to interact with and consume the platform have a big impact on developer experience (DevEx). Successful Internal Developer Platforms enable true developer self-service while reducing cognitive load. They accomplish this through golden paths, or any procedures in the software development life cycle that a user can follow with minimal cognitive load and that drive standardization.

This was an area where respondents struggled the most. Not even a fifth (19.1%) of organizations reported leveraging golden paths to their fullest extent, using them to reduce cognitive load and enforce best practices. In contrast, 22.6% still force users to manually submit a request to a ticket queue.

When building golden paths, organizations should not only have day one in mind. In “Build Golden Paths for Day 50, Not for Day 1,” Humanitec CEO Kaspar von Grünberg explained that too many organizations prioritize golden paths for a simple scaffolding use case of a new service or resource. However, such golden paths only cover day one of a service that will be around for hundreds of days. Organizations should also build golden paths for day 50 and beyond.

A valuable way to evaluate best practices

The Platform Maturity Model can become a valuable tool for organizations to evaluate which platform engineering best practices they still need to meet. The model is still a work in progress. Organizations can learn from and contribute to future iterations of the Platform Maturity Model through the working group.

Our survey found that most organizations have a long way to go before they are fully aligned with best practices and have the right culture. However, the journey is worth the effort as organizations aligned with best practices can get more from their Internal Developer Platform.

What comes next? The Platform Engineering community is your hub for the best, free platform engineering resources. Dive into practitioners’ stories and expert insights on the Platform Engineering YouTube channel.

‍