Platform engineering: It’s about culture, not tools

Over the past decade, we’ve seen significant changes in how development organizations structure their teams. Traditional operations teams gave way to Google’s Site Reliability Engineering (SRE) model, which aimed to modernize operations and better define interfaces with software developers. This was a move away from the “throw it over the wall” approach that often ended in blame contests when things went wrong.

DevOps emerged as a slightly different approach to the same problem, bringing developers and operators into a single team focused on delivering business value. This model proved successful — bringing people together is always a good idea, and aligning them to business outcomes helped get features out the door faster.

However, challenges emerged as organizations attempted to scale DevOps. Having developers and operators in every team became expensive. Teams also focused on local optimization, making their tools and processes efficient for their specific needs, sometimes at the expense of global organizational goals. Corporate policies, security requirements, and governance often got lost in the shuffle.

Enter platform engineering: the next step in this evolution.

What is platform engineering?

Platform engineering represents a balance between the structured interfaces of SRE and the collaborative spirit of DevOps. At its core, it involves creating a centralized platform team with a well-defined interface to decrease developers' cognitive load, approaching internal tooling as a product rather than a service.

The product mindset is central to platform engineering. Platform teams build services for consumption, treating them as products and the developers as customers. This means:

• Engaging with developers to understand their needs and pain points
• Designing the platform based on user research and feedback
• "Marketing" the platform’s value to increase adoption
• Continuously improving based on usage metrics and customer satisfaction
• Creating documentation and enablement materials that speak to developer needs

Unlike traditional IT service models built around tickets and wait times, platform engineering teams build self-service capabilities that development teams want to use. Their Internal Developer Platforms provide "golden paths" with all essential components for building reliable, secure software so developers can focus on writing code. That translates into more efficient software delivery and faster time to market.

A key difference from DevOps is that platform engineering acknowledges how large organizations tend to be structured. Rather than trying to put operators on every team (which becomes expensive and creates inconsistency), it creates a specialized team that serves the broader organization — but with a product mindset rather than a service desk approach.

The human side of platform engineering

The secret to platform engineering success isn’t choosing the right technology stack — it’s rooted in empathy. Effective platform teams deeply understand what a day in the life of a developer, security engineer, or operations specialist looks like. They know the pressures these teams face, their performance metrics, and the challenges that frustrate them most.

This empathy leads to a core principle: make the right thing the easiest thing. We are all fundamentally drawn to the path of least resistance. If security scanning is painful and slow, developers will try to work around it. If deployment pipelines are cumbersome, teams will build their own.

Security and compliance should be features of your business, not obstacles. This mindset shift changes everything. Think of it like car brakes — they aren’t there to slow you down; they’re there so you can confidently drive faster. You’d drive much more cautiously without good brakes or avoid driving altogether.

Optimizing process through collaboration

When I’m helping a platform team consider the process behind their platform, I like to look at their approval steps and ask, “When was the last time this approval step resulted in a rejection?” I’m always blown away by how many approval steps never result in a rejection. This is a clear sign of a process that’s not adding value.

So, how can organizations start to critically examine existing development processes with an eye toward optimization?

One of the most powerful tools in platform engineering isn’t a tool at all — it’s a workshop. Path to Production (or value stream) workshops bring together everyone involved in releasing software, from developers and security specialists to compliance and product teams.

The format is simple: Get representatives from each team in a room with sticky notes and an empty wall. Chart out exactly what happens to go from an idea to production code. Understand what each team does, how handoffs work, and how long each step takes.

For many organizations, this might be the first time these teams have all been in the same room discussing how they work together. Good things happen when people come together — this time helps everyone understand functional requirements and emotional pain points in the process.

This collaborative approach should extend to your platform team’s day-to-day work. Successful platform teams regularly engage with finance to help them understand technology investments. They build relationships with security teams to automate compliance rather than block progress and create feedback loops with platform users to continually improve the platform based on real needs.

Measuring success beyond adoption rates

For most organizations, one of the top priorities of a platform engineering initiative is improving developer experience. However, developer experience is subjective, so how can organizations measure the success of their platform teams? Adoption rates are a good start, but you’ll need to dig deeper to get a complete picture.

Good metrics should be:

1. Tied to business outcomes, not just technical capabilities
2. Small in number but broad in what they measure
3. Used to understand trends within teams, not compare across teams
4. Clear about why they’re being measured

Organizations often jump straight to frameworks like DORA when measuring platform engineering success. DORA is a great place to start because it boils everything down to four metrics: deployment frequency, lead time for changes, change failure rate, and time to restore service. However, one thing to be mindful of when using DORA metrics is to avoid comparing metrics across teams. For any metric to be useful, you need to consider it in the context of a specific team with specific goals. For example, deploying many times a day might be great for a web application, but less desirable for a complex backend finance tool.

More importantly, metrics should always be used to measure teams' performance, not individuals’ performance. The very act of recording metrics will change behavior. Software engineers are problem solvers by nature — if you measure their performance based solely on deployment frequency, they’ll find ways to deploy more frequently, whether or not that’s beneficial to the organization.

Also, keep in mind that perception matters as much as reality. A deployment process might only take 15 minutes, but developers will perceive it as slow if it feels painful and frustrating. User interfaces that are unresponsive, require duplicate data entry, or demand unnecessary approvals create a perception of friction even if the actual time impact is minimal, so a high-performing platform team should always be looking for ways to understand whether they need to change the speed of the system or change the perception of the system.

A cultural shift, not just a technical one

Platform engineering represents an evolution of DevOps that acknowledges both the value of bringing people together and the reality of how large organizations operate. However, its greatest potential lies not in its technical approach but in its cultural impact.

By fostering collaboration across teams, treating developers as customers, and making security and governance features rather than obstacles, platform engineering helps organizations deliver better software faster — not by adding new tools, but by helping people work better together.

The most successful platform teams understand they’re building bridges, not just tools. They focus on making the right thing the easiest thing, balancing developer autonomy with organizational governance, and measuring success in ways that drive positive behavior.

As you evaluate your organization’s approach to internal platforms, ask what technologies you’re using and how you’re bringing people together around them. That’s where the true power of platform engineering lies.