Why Platform Engineering Is Essential to DevEx: Understand the Relationship Between Platform Engineering and the Developer Experience

Editor's Note: The following is an article written for and published in DZone's 2025 Trend Report, Developer Experience: The Coalescence of Developer Productivity, Process Satisfaction, and Platform Engineering.

Software engineering continues to be an exciting journey, where use cases not only feed creativity but also allow the underlying intellectual property to thrive. The biggest challenge is to make sure engineers maintain a focus on what allows their solutions to be differentiators in the market. That's where concepts like developer experience (DevEx) and platform engineering come into play.

Let's explore how DevEx blazes the path for engineers to maintain control of their responsibilities and understand the impact of artificial intelligence (AI) and automation. Along the way, we'll define platform engineering and walk through an example implementation. Finally, we'll demonstrate the expected results of improved focus on architecture, productivity, and engineer satisfaction.

Developer Experience

According to Gwen Davis, DevEx is defined as:

"...the systems, technology, process, and culture that influence the effectiveness of software development. It looks at all components of a developer's ecosystem — from environment to workflows to tools — and asks how they are contributing to developer productivity, satisfaction, and operational impact."

The role of the software engineer continues to gain complexity as underlying business objectives mature. It's important to maintain a solid DevEx posture to help individual contributors remain satisfied and challenged… with the right problems to solve.

From a tooling perspective, items like autocompletion, AI-driven suggestions, and static code analysis have improved the process of writing code. Tools like Renovate and Watchtower automate the process of dependency management and container base image updates. There are even pull request (PR) bots, which can do things like auto-approve touch-commit PRs, avoiding the assistance from another engineer. 

There are the social aspects of DevEx that should be kept in mind. Here, focusing on toil reduction is key, i.e. eliminating manual or repetitive tasks that bog down productivity. Making sure engineers have the ability to collaborate with others — especially across team boundaries — often avoids solving problems that already have a proven solution.

Where possible, the use of metrics should be implemented and reviewed at least once during a development iteration (or sprint). Some key metrics that relate to DevEx include:

• Cycle time, the amount of time required to complete a task, keeping in mind the expected complexity
• PR lead time, the amount of time required to review, approve, and merge code
• Deployment frequency, how often code is being deployed to production
• Mean time to recovery, the amount of time required to resolve an unexpected incident or failure
• Change failure rate, the percentage of changes that result in an unexpected incident or failure

With these metrics in place, dashboards can be created, allowing teams to monitor their own metrics while also understanding metrics for all engineers. This can provide early indicators for when DevEx levels are trending low, which could be driven by changes being made that are outside an engineer's control.

Platform Engineering

According to a DZone Refcard, platform engineering is defined as:

"...a discipline focused on creating and managing development platforms that significantly enhance software delivery processes. At its core, platform engineering aims to establish secure environments, automated and self-service tools, and streamlined workflows that empower development teams to write, test, and deploy applications effectively and consistently across various settings without worrying about operational complexities."

In the DevEx section, I mentioned the importance of making sure that software engineers are focused on solving the right problems. Before the concept of platform engineering, individual teams were forced to focus time on solving common problems, like CI/CD and security, in a vacuum. 

Not only did this take away from their ability to enhance their products or services, but it also required teams to create and support tooling that is common to all teams. In fact, a given team's solution might miss auditing, compliance, and security requirements — leading to further refactoring down the road, such as unexpected penalties or fines.

Platform engineering provides benefits across the entire development lifecycle for engineering teams. Three examples can be found with tooling, continuous integration, and continuous deployment.

Tooling Automation

Describing an organization's teams, services, and dependencies is the first step in allowing further automation to succeed. This metadata can be used to grant security and authorization for each team's source code repositories and solutions. 

The repository would introduce all aspects for each team. Every service would be described as well, linking the service to the team and any cloud-based functionality required by the service. This would eventually pave the way for a given software engineer to accomplish the following tasks:

• Introduce future code repositories owned by the team (services, infrastructure as code, etc.)
• Create and maintain the necessary infrastructure required to meet new use cases
• Access and support services and dependencies by logging in with their standard credentials

Continuous Integration Automation

Taking continuous integration (CI) off the list of responsibilities for engineering teams is another key aspect of platform engineering. This removes the risk of a build-your-own DevOps approach and allows engineers to be focused on solving the right problems. 

A proper CI implementation would automatically launch the CI process each time a PR is created. Once the PR is created, the following required tasks could be initiated and managed by platform engineering:

• Perform static/code quality analysis, making sure corporate standards are being met
• Validate that zero, high, or critical vulnerabilities are being introduced as a result of the changes
• Update all base images when container images exist
• Automate signed deployment artifacts

Additionally, when PRs are merged to the primary branch, the same tasks would be executed again, validating that the code being merged also maintains the same level of compliance.

Continuous Delivery Automation

It is important for platform engineering to assume responsibility for continuous deployment (CD) to standardize how deployments work across all individual teams. Doing so can eliminate the common toil-based task of making sure the engineer who modified the code is not the person deploying the code. 

By taking this approach, platform engineering's control over CD can introduce additional benefits. Here are some examples:

• Health-mediated deployments allow the deployment process to integrate with the observability platform, therefore halting deployments that impact established service metric thresholds.
• Integration with change management and application lifecycle management solutions tie deployments to the tickets related to a release and launch approval workflows when management approval is required.
• Rules can be introduced to make sure teams are adhering to software development lifecycle (SDLC) standards, like making sure a given deployment is deployed in all expected lower environments before being deployed to production.

By using platform engineering for the separate CI and CD processes, teams can be assured that the code or container being deployed is the same signed image as the lower environments.

DevEx and Platform Engineering Together

Now that we have a strong understanding of DevEx and platform engineering, let's understand the impact these two concepts have when working together.

DevEx is the more mature concept and is something software engineers have embraced for quite some time, long before the term was introduced. Engineering managers and directors have long wanted to understand the productivity across teams, leading to metrics being established. What wasn't known at the time was the strong relationship to job satisfaction levels.

Platform engineering is certainly a corporate investment, which has its own budget expectations. Once corporations see the benefit of platform engineering, doors will open to implement the necessary tooling and CI/CD improvements. Once teams have onboarded to platform engineering, the following benefits will be realized by the entire organization:

• Reduced risk from an audit, compliance, and security perspectives due to a standardized and centralized SDLC
• Deployments less prone to issues related to inadequate code coverage
• Deployments free from significant vulnerabilities or code quality issues
• Improved metrics:

• Cycle time improves due to engineers being focused on solving the right problem

• PR lead time increases to allow reviewers to focus on proposed changes

• Deployment frequency improves due to automation and platform engineering tooling

• Mean time to recovery improves due to engineering focus from tooling and automation

• Change failure rate improves due to the automation and platform engineering tooling, plus the benefits from engineers being focused on solving the right problem

• Improved job satisfaction levels due to software engineers being laser-focused on the role they accepted

While it is possible to implement one concept without another, platform engineering is key to maximizing DevEx.

Conclusion

This exploration demonstrated how DevEx tooling removes tedious tasks from daily work and reduces toil along the way. The ability for teams to collaborate is key to understanding the lessons learned by others. Finally, the use of metrics can help individuals, teams, and organizations as a whole gain insight into key performance indicators.

Platform engineering allows engineers to focus on solving problems and enhancing products by centralizing aspects common to all teams. In doing so, the wonderful side effects of auditing, compliance, and security concerns can be kept in check. 

When DevEx and platform engineering are combined, engineers are able to keep up with established objectives, focusing on solving the right problems and remaining engaged — all leading to increased job satisfaction. I can personally attest to these results as I've been working in this utopian environment for the last two years.

My readers may recall my personal mission statement, which I feel can apply to any IT professional:

"Focus your time on delivering features/functionality that extends the value of your intellectual property. Leverage frameworks, products, and services for everything else."

The use of platform engineering is an example of how individual teams can leverage a common solution to allow them to extend the value of the products and services they own. DevEx ultimately measures the job satisfaction for individual contributors and their ability to work on the right tasks. As you reflect on this mission statement, consider how you would answer the following questions:

1. Is your organization adhering to this mission statement?
2. What is the overall impact by not adhering?
3. How could adhering to this mission statement impact your bottom line?

Have a really great day!

Additional resources:

• "Developer experience: What is it and why should you care?" by Gwen Davis
• Platform Engineering Essentials by Apostolos Giannakidis and Kellyn Gorman, DZone Refcard
• Mend Renovate CLI
• Watchtower — a process for automating Docker container base image updates 

This is an excerpt from DZone's 2025 Trend Report, Developer Experience: The Coalescence of Developer Productivity, Process Satisfaction, and Platform Engineering.

Read the Free Report