Thriving in a Modern World
In recent years of my career, I've spent time with organizations either already on their journey or just starting out with platform engineering. One thing they have had in common is their need to modernize and standardize, usually without being able to create a greenfield environment.
The biggest differences between them have been ambition, mandate, and organizational maturity. There’s no one-size-fits-all, of course, but there are some real common denominators I believe we should be able to identify, structure, and turn into a playbook of sorts. This blog post is my understanding of platform engineering as of 2026, influenced by new and old experience, combined with the great resources already written and published by others. The goal: thriving in a modern world.
To better enable a common understanding of the subject, we all need to know what a platform engineering team's output normally is and how ambition, mandate, and organizational maturity influence the final product.
Platform Engineering Definition
There are as many definitions of any IT buzzword as there are grains of sand in the universe. However, some common understandings do exist. One definition by Microsoft states the following:
Platform engineering is a practice built up from DevOps principles that seeks to improve each development team’s security, compliance, costs, and time-to-business value through improved developer experiences and self-service within a secure, governed framework.
It's both a product-based mindset shift and a set of tools and systems to support it. — Source
The Importance of Developer Experience
Traditionally, two models* of IT operations exist. One where everything is managed by a centralized infrastructure team, making them and their offerings the bottleneck. In the other, infrastructure is the developers’ responsibility. Both come with a lot of problems, but they provide value as well. One of the common challenges is the developer experience. A centralized solution can be experienced as slow and bureaucratic, while the other demands a lot of specialized knowledge of cloud administration, making it an uphill battle for new developers or teams that have no existing infrastructure in place. Both are bad developer experiences.
Platform engineers’ main job is to improve on either model. There should be no need for human interaction to get started creating business value as a developer. This requires a unified experience between operations, CI/CD, security, and governance teams.
asterisk: others do exist, but for simplicity’s sake I’ve highlighted the two edge cases I think make the point.
Different Platforms (Application, Data, Common Components)
A common mistake in platform engineering is that we try to encompass everything that is IT-related. The scope has a tendency to creep before any real work has been done. We cannot treat compute, databases, identities, networks, analytics, etc., as the same type of delivery.
In the next chapter we will talk about organizational maturity, but before we do so, let’s describe a few potential deliveries:
- Application Platform
- Data Platform
- Common Components
Application Platform
The application platform is regarded by most engineers as the biggest carrot in any platform team. Running your own compute is usually the task with the highest amount of operational cost and cognitive load in any development team. Reducing this cost and removing the cognitive load by offering shared compute is a guaranteed way of gaining relevance, adoption, and proving your worth. Equally, it is the service that demands the most of any platform team.
Committing to a shared compute platform requires planning and a lot of stakeholder support.
Data Platform
A data platform can be split into two groups: one is data components such as databases, storage, and queues; the other is what is commonly known as an analytics platform.
Data components are deployments that change infrequently on the management plane, but that change a lot through data modifications by applications. These services often come coupled with any application deployment, and they should have a relationship in terms of self-service, but in existing cloud environments where data products are already widely used, they can be the hardest to integrate into a holistic self-service cloud platform.
An analytics platform is commonly not built by platform engineers; instead, dedicated data engineers take on this responsibility. However, there is often a tight relationship between platform engineers and data engineers as they both try to automate and integrate cloud-based products.
Common Components
A beloved child is known by many names, but in this case we are talking about platform tooling, reusable infrastructure-as-code, and developer experience tools. Examples of this are shared container registries, GitHub, and build workflows/pipelines. These components are often standalone deliveries that either improve upon existing infrastructure or serve as golden paths, together with the central platforms.
Organizational Maturity
One of the largest hurdles any platform team faces is getting people to change.
Change is needed when introducing a centralized platform, and for companies who don't have the option to build a greenfield platform from the beginning, getting people and the organization on board can be an uphill battle. The first step is to gauge the organization and figure out where in the landscape our current way of working is placed.
Microsoft has created a good framework for exactly this task. It divides maturity into 5 stages across 6 categories. These stages serve as a tool to map our maturity using the Platform Engineering Capability Model.
- 1. Initial
- 2. Repeatable
- 3. Defined
- 4. Managed
- 5. Optimizing
1. Initial
At this stage, there is little to no formal platform engineering practice in place. Processes are ad hoc and unstructured, with minimal investment in platform engineering tools or resources. Governance is informal, and there is limited measurement or feedback mechanisms.
2. Repeatable
Basic platform engineering processes are established and can be repeated. There is some investment in tools and resources, and governance practices are starting to take shape. However, interfaces are still manual, and measurement and feedback mechanisms are limited.
3. Defined
Platform engineering processes are well-defined and documented. There is a clear investment in tools and resources, and governance practices are formalized. Interfaces are partially automated, and measurement and feedback mechanisms are in place.
4. Managed
Platform engineering processes are actively managed and optimized. There is significant investment in tools and resources, and governance practices are consistently enforced. Interfaces are largely automated, and measurement and feedback mechanisms are regularly reviewed and acted upon.
5. Optimizing
Platform engineering processes are continuously improved based on feedback and performance metrics. There is a strong investment in cutting-edge tools and resources, and governance practices are proactively adapted to changing requirements. Interfaces are fully automated, and measurement and feedback mechanisms drive ongoing optimization.
Using these categories with the stages above and the Platform Engineering Capability Model you can create a baseline with ambitions that can later be reviewed and used to measure yourself against.
- Investment - Allocate budget and demonstrate an ROI
- Adoption - Choosing services, tools and technologies
- Governance - Security and compliance policies
- Provisioning and management - Define provisioning processes and management practices
- Interfaces - Streamline provisioning and service requests
- Measurements and feedback - Establish feedback loops
Mandate, Ambition, and Business Value
Now that you know where you place in the maturity landscape, it’s time to talk about the three pillars:
- Mandate - what are you allowed to do?
- Ambition - what do you want to do?
- Business value - how do you implement your ambitions without being a bottleneck?
As the platform engineering definition says, your main goal should be to improve your developers’ security, compliance, costs, and time-to-business value.
For you to be able to do this, you need two things: backing from management and ways to prove your value.
What are you allowed to do?
Getting backing from management is easier when you can prove that your work contributes to business value. This means that one follows the other. Gathering feedback to figure out where your services would be an improvement is key.
You must be able to measure if what you create is providing value or if it is a failed experiment. There are many frameworks to do so, but you will need to choose one that focuses on continuous improvement, such as Plan-Do-Check-Act, Lean, or Kaizen.
Launching small experiments to gather feedback and measure value is a great way to get started. This will help prove your worth and get the mandate to do more. Don't reimplement everything at once; instead, focus on small parts that can be improved quickly. With mandate comes the ability to increase ambition.
What do you want to do?
You are allowed to have ambitions, but these are also meant to change. Based on the maturity and capabilities discovered in the model, you can see which areas clearly need improvement and possibly some of the steps needed to get there. As with feedback, you should continuously evaluate your own ambitions and adjust.
To get an idea of where the ambitions tend to lie, here is an extract from the expanded description of what platform engineering entails:
Platforms that developers either use or extend have the power to eliminate toil throughout the development process with highly optimized developer experiences and simplified operations.
These platforms include tools that:
- Help developers be self-sufficient (for example, starter kits, IDE plugins)
- Assist with common tasks
- Encapsulate common patterns and practices into reusable building blocks
- Provide early advice and feedback on problems or security risks
- Simplify operations by managing underlying infrastructure and tools
What this means in practical terms and what kind of business value it brings takes us to the next point.
How do we implement our ambitions without being a bottleneck?
Most companies have a long history in the cloud by now, and many still have an on-premises presence that needs to be considered. The consequences of early adoption of cloud environments are usually a lack of standardization and incomplete target architectures.
These issues can be helped by implementing the ideas from platform engineering, but not in isolation. You will depend heavily on proper implementation of a modern cloud architecture.
Since most are not building a greenfield platform, it is necessary to locate the improvements that can be done now, next, and later that are specific to the point-in-time architecture you already operate in.
I suggest following this four-phase strategy: Stabilize, Standardize, Enable, and Consolidate
- Stabilize - Document the current state, build alignment and trust
- Standardize - Introduce consistent patterns for infrastructure delivery
- Enable - Deliver self-service capabilities
- Consolidate - Gradually move workloads to shared services when the foundation is ready
In the matrix below, you can see a few deliveries and capabilities that might already exist or that can be created by a Platform Engineering team. These are by no means complete or intend to cover all aspects of what a Platform should be, but it gives an idea of the work ahead, choosing to go this route.
| Stabilize | Standardize | Enable | Consolidate |
|---|---|---|---|
| Identify IaC usage | Create shared modules with proper release processes | Surface reusable infrastructure modules and environment templates through a self-service interface | Expand catalog with other core capabilities |
| Introduce reusable IaC modules and pipelines | Define modules for common components | ||
| Identify high-value targets for future standardization/centralization (e.g., K8s) | Run periodic feedback sessions with users | ||
| Map existing environments | Introduce platform metrics (time-to-deploy, onboarding friction, platform adoption rate) | ||
| Identify a small, internal service or low-risk product to test early improvements | |||
| Establish a working model with dependents (e.g., infrastructure teams, security) | Collaborate with dependents to define product-ready templates for new environments (e.g., landing zones) | Integrate policy-as-code into pipelines | |
| Create a lightweight RFC and ADR process for shared decisions | Adopt the automated creation of product-ready environments | Shift from manual review to automated approval | |
| Introduce reusable application deployment pipelines | |||
| Work with product teams to create standardized reusable workflows | |||
| Publish internal documentation as a product, emphasizing quality over quantity and developer experience, not governance | Define migration playbooks for common workloads | ||
| Provide a shared observability stack | |||
| Implement cost dashboards for product teams | |||
| Select a few motivated product teams to adopt the shared platform and co-develop improvements | Migrate workloads incrementally to the shared platform and re-architect the necessary components | ||
The Golden Carrot — Shared Compute Services
On purpose, shared compute like Kubernetes is left out of the phases shown in the matrix above for two reasons:
- Delivering shared compute is very attractive
- It is also very all-consuming and can be difficult to deliver alongside other platform capabilities
Together as a team, you must decide if this is something you should plan to do or if it should be an ambition at a later stage. Most companies have quite a long way to go before it makes sense to provide centralized compute, both technically and in terms of team maturity.
Not to mention the expertise needed in the team to deliver such a complex infrastructure component to a broad set of consumers.
What Creates Business Value?
A factor that needs consideration is how any of the described capabilities adds to the ongoing business value creation inside product teams. The platform must be able to prove its worth at every step of its implementation, and that’s no easy task.
This is also the reason why developer experience trumps enforced governance.
You need teams to choose your products because of their worth, not because a manager told them to do so.
Saying that is easy, but you need to be able to quantify what value is. This responsibility is not wholly on you, but the developers’ success is your success.
Tools like DORA could support you in this.
In the Plan-Do-Check-Act workflow we talked about earlier, Check becomes one of the most important phases. If we can embrace the practice of "failing fast" and create excellent ways of capturing feedback and measuring value in our workflow, the need for developer-specific performance metrics becomes a phase 3 or 4 delivery.
Next Steps
Now that we have covered the basics of platform engineering from a modern perspective, it’s time to get started.
- Make sure that all team members have a common understanding of what you want to achieve and that you speak the same language.
- Agree on what platform engineering and DevOps are in your context.
- Gather stakeholders, engineers, and dependents to map your current maturity using the Platform Engineering Capability Model. Claims should be challenged and new perspectives are strongly recommended. Facts over feelings.
- Based on the capability model and its output, add to or define capabilities and deliveries that make sense for your context in each of the 4 phases.
- Agree on a timeline and get to work!
Bye!
Thanks for reading! If you have any questions or want to discuss platform engineering further, feel free to reach out to me on LinkedIn.
This playbook is meant to serve as inspiration and a starting point for your own platform engineering journey. Adapt it to your organization's unique needs and context.