The Declaration and the Reality
Platform engineering has followed the trajectory of DevOps a decade earlier. The concept gained community momentum, produced a body of practitioner knowledge, and attracted sufficient attention from enterprise technology leadership that “we are investing in platform engineering” became a standard answer to questions about development capability strategy.
Also following the DevOps trajectory: the gap between the declaration and the operational reality. Many enterprises that have declared platform engineering as a priority have built platform engineering teams, given them the platform engineering label, and provided them with some tooling and some funding. They have not, in a significant proportion of cases, built the product management capability, the self-service provisioning maturity, or the developer adoption that constitute actual platform engineering capability rather than the label applied to a team that does what the DevOps team did before.
The honest assessment of platform engineering maturity across the European enterprise landscape, based on direct observation of programmes rather than self-assessment scores, is that most organisations are at Level 2 on a five-level maturity model, believe they are at Level 3, and are investing as if they are at Level 4. The gap between self-assessed and actual maturity is not a measurement problem. It is a definition problem: most organisations are measuring the inputs to platform engineering (team exists, tools deployed, golden path documented) rather than the outcomes (developer adoption, delivery velocity improvement, operational overhead reduction).
The Five-Level Maturity Model
The maturity model that CNCF has documented and that practitioner experience validates has five levels. Each is characterised by specific capabilities and specific organisational conditions, and each requires different investments to advance to the next.
Level 1 (Ad Hoc) is the pre-platform-engineering state. Teams build their own infrastructure independently, with no shared platform. The CI/CD pipeline in team A is different from team B’s, the Kubernetes configuration in team C is different from team D’s, and the security baseline is inconsistent across all of them. There is no platform team; there is only the ad hoc accumulation of team-specific infrastructure.
Level 2 (Operable) is where most EMEA enterprises are, regardless of what they call their platform engineering. A platform team exists. There is some standardisation: a common CI/CD pipeline template, a common Kubernetes configuration baseline, a common observability stack. These standards are documented and some teams follow them. Adoption is partial because following the standards requires interpretation and effort, and teams that are under delivery pressure often deviate from or skip the standards. The platform team provides support to teams that ask for it rather than providing self-service infrastructure that teams use independently.
Level 3 (Scalable) is characterised by genuine self-service capability. Development teams can provision environments, deploy services, and access the capabilities they need through a self-service portal without requiring direct engagement with the platform team. The standards are enforced through automation rather than through documentation and expectation. The platform team is spending more time developing the platform than providing support to teams using it. Adoption of the platform is high because using it is easier than building around it.
Level 4 (Optimising) adds product management discipline to the Level 3 capabilities. The platform team has a product owner and a product roadmap driven by developer feedback and usage data. The platform is continuously improved based on developer productivity metrics and developer experience surveys. The platform team knows which of its capabilities are highly adopted and which are underused, and makes product decisions based on this data.
Level 5 (Leading) is the state where the platform is a genuine competitive advantage for the organisation’s development capability. The platform enables development teams to deploy new services in hours rather than days, supports AI workloads, compliance requirements, and scale requirements without custom integration, and has a developer experience that is genuinely preferred to the alternatives. This state is achieved by a small number of organisations globally and requires years of sustained investment.
Where Most EMEA Enterprises Are
The self-assessment bias in platform engineering maturity is consistent: organisations self-assess one level higher than their actual capability. The team that has built some standardised tooling and provides DevOps support believes it is at Level 3 when it is at Level 2. The organisation with a self-service portal that covers sixty percent of developer use cases believes it is at Level 4 when it is at Level 3.
The diagnostic observations that reveal actual maturity are more reliable than self-assessment. The question “how long does it take for a new development team to go from a blank repository to a production deployment?” reveals actual Level 3 capability — hours to a day — versus Level 2 capability that provides templates but requires platform team involvement — several days to a week. The question “what percentage of development teams are using the platform golden path for their new services?” reveals adoption maturity — above eighty percent at Level 3, below fifty percent at Level 2.
The shadow infrastructure rate — the percentage of cloud resources and pipeline configurations that were built without using the platform’s self-service capabilities — is the most honest maturity indicator. At Level 2, shadow infrastructure is common because the friction of using the platform is sufficient to make building independently attractive. At Level 3, shadow infrastructure is rare because the platform’s self-service capability is genuinely easier than the alternative.
What Level 3 Actually Requires
The investment required to advance from Level 2 to Level 3 is not primarily technical. The technical investment in a self-service portal and automated enforcement of standards is significant but tractable. The organisational investment is what most Level 2 programmes underestimate.
The product management capability is the most critical organisational investment. The platform team needs someone who understands the developer experience well enough to design self-service capabilities that developers actually want to use, and who has the product management discipline to prioritise the platform roadmap based on developer need rather than platform team preference. This skill is scarce in most platform teams and is the capability gap that most prevents Level 2 programmes from reaching Level 3.
The governance for platform adoption is the second organisational investment. Self-service capability alone does not produce adoption; development teams need both the capability and the incentive to use it. The governance that creates the incentive is the architectural review gate that validates whether new services use the platform’s golden path, the security policy that enforces the platform’s security baseline, and the cost accountability that makes the platform’s resource optimisation visible to the teams that benefit from it.
The feedback loop between developer experience and platform development is the sustainability investment. The platform that is developed without systematic feedback from its users produces capabilities that the team believes are valuable but that developers do not adopt. The platform team that has established feedback mechanisms, from usage data to developer experience surveys to regular user research, develops the platform in directions that increase adoption rather than in directions that increase sophistication without adoption.
The Investment Adjustment That Real Maturity Requires
The platform engineering programme that is investing in Level 4 capabilities while at Level 2 is making the most common platform engineering investment mistake. Level 4 capabilities — product management dashboards, developer experience measurement systems, sophisticated adoption analytics — require Level 3 adoption to produce value. Investing in Level 4 without Level 3 adoption produces expensive tooling that tells you about the adoption you do not have.
The investment sequencing that works: build Level 3 self-service capability and achieve genuine developer adoption before investing in Level 4 optimisation capability. The adoption is the asset; the optimisation tools are the means of improving an existing asset. Building the optimisation tools before the asset exists is investment sequencing in the wrong order.
The platform engineering programme that makes this assessment honestly and adjusts its investment accordingly will reach the maturity it is targeting faster than the one that maintains the Level 4 investment plan while at Level 2 adoption. The adjustment is uncomfortable because it requires admitting that the current programme is at a lower maturity than declared. It is the adjustment that produces actual progress.