Tips for Building a Platform Engineering Discipline That Lasts

Platform engineers do not a platform engineering discipline make. We’ve learned a lot about platform engineering since making it the focus of the Puppet State of DevOps Report for the past couple of years — chiefly, that a healthy, high-functioning platform engineering initiative is the product of sustained support, ongoing care, and continuous iteration.

The 2024 edition of the report, the Evolution of Platform Engineering, shows us that in its ideal shape, platform engineering is a hands-on discipline that creates hands-off efficiencies — but it’s not about providing unlimited flexibility. The best way to build and maintain an internal developer platform (IDP) and the discipline around it is to set the stage with tools, practices, and structure that can sustain a platform for the long term.

Based on our years of research and survey data in our State of DevOps survey, here are some tips we’ve uncovered for platform teams around the world for building a lasting platform engineering initiative.

Map Out Your Whole Software Development Lifecycle

This one is a basic of Agile, DevOps, and CI/CD. A thorough review of the entire software development lifecycle (SDLC) for troublespots and areas of improvement will give you an idea of where your SDLC could benefit most from the practices and tools of platform engineering.

Look at key functions like requirements gathering, coding, testing, deployment, and monitoring. Where are the bottlenecks? Which stakeholders are responsible? What tools do they rely on? It’ll also help you identify the scope of your platform engineering needs by showing you how much of your stack you’ll need to adapt.

Talk to Your Developers

Your SDLC only tells half the story. Metrics and performance can tell you how well a solution is working to achieve business or departmental goals, but it can’t tell you how well that solution is working specifically for developers in their day-to-day. (If that sounds close to product management, that’s because it is. More on that later.)

This is the whole point of platform engineering: finding out what impacts the developer experience (DevX) and building tools that service it. Can developers make requests for the resources they need in ways that suit them (like via self-service APIs)?

In Fact, Talk to Almost Everyone

Ideally, it won’t just be developers and operations using your platform. If you want your platform to drive real value, you’ll need to know how to position it to the rest of your organization. How do you get buy-in from key decision-makers? Once you’ve created and structured tools to benefit developers, how do you explain those benefits to the developers themselves? No one person has the answers to those questions.

Also, keep those lines of communication open even after you’ve got a working IDP underneath your SDLC. If your platform is working, you’ll learn a lot about it through feedback loops and the diverse perspectives of stakeholders on different teams who actually use the platform. Opening channels to senior leadership and decision-makers will also help ensure your platform is developed in line with their objectives.

Hire for Hard and Soft Skills

A great platform engineer is defined both by their ability to create infrastructure and advocate for and guide others (which is where communication skills come in) — especially in the platforms that are maturing today. As far as hard skills go, the platform engineer should have experience in cloud platforms, CI/CD, IaC, security, and automation.

Other roles you’ll need include a product owner to manage platform stakeholders and track KPIs. Our 2024 State of DevOps report found that 70% of respondents said a product manager was important to the platform team – 52% of whom called the role “critical”. To avoid complexity and scaling issues, you’ll also need architects with the vision and skills to help the platform engineering team design and build it.

Start Using the Right Infrastructure as Code

Infrastructure as code (IaC) is version control for your infrastructure. It makes infrastructure human-readable, auditable, repeatable, scalable, and securable.

IaC also lets disparate teams — developers, operations, and QA — review, collaborate, iterate, and maintain infrastructure code simultaneously. Consistency, reproducibility, and collaboration are key principles of platform engineering — and IaC is the only real way to enable all three at scale across teams and environments.

Build Security Right Into Your IDP

Seventy percent of respondents to our 2024 platform engineering survey said security is baked right into their platform. They say that making security and compliance part of the foundation of their platform has helped them lower risk (59%), enabled business growth (50%), saved devs time on compliance (48%), and cut down on audit busywork and prep (42%).

Retroactively adding security to an IDP once it’s in motion is still possible, but it comes with its own set of issues: Integration, access control, training, and testing can all disrupt existing workflows and processes.

Build in Self-Service – Not Unlimited Flexibility

An IDP has many customers, but developer experience (DevX) should drive the tools, structure, and use cases of a platform. Don’t wantonly create self-service integrations that give everyone as much flexibility as possible. Choose tools that make it easier and faster for developers to develop securely.

Interestingly, we’ve found that the self-service capabilities of a platform might be influenced by how and why it was made. In some organizations, platform engineering is a ground-up approach: Developers kick off a grassroots platform initiative supported by stakeholders across the user base (sometimes including ops and leadership).

But other IDPs are created via a top-down structure, where the platform has more direct leadership representation (as 50% of survey respondents do). In our research, we’ve detected a nasty undercurrent in organizations with this top-down approach: The perception of platforms as an “ops takeback” — i.e., operations leadership assuming control of a practice designed to benefit developers.

Depending on where your platform lives, it’ll be important to continuously monitor the needs it’s serving and the business goals it’s meant to serve. Which brings us to our next point:

Keep Communication Channels Open

The quickest way to kill a platform — or, more likely, get stuck halfway to maturity — is to assume it’s done. Ongoing evaluation and continuous improvement are vital to the most successful platforms out there.

Rely on tried-and-true DevOps practices to facilitate open feedback on your platform engineering initiative. Iterate new ways to ‘productize’ your IDP: Conduct surveys, establish an advisory board (with devs, IT ops, and leadership), document and share knowledge specifically for the maintenance and improvement of the platform. And when action is taken on a change to the platform, evangelize it.

From our perspective, platform engineering isn’t a set-it-and-forget-it initiative. Whether it’s championed by developers from the ground up or sponsored from the top down by operations, an IDP needs more than smart APIs and self-service workflows to prove lasting value in the long term.

For more insights that can support your platform engineering, don’t miss Puppet’s 2024 State of DevOps Report: The Evolution of Platform Engineering.