Over the past year, AI has taken the world by storm. Our industry is innovating at an unprecedented rate, bringing incredible products to market that make life and work easier and more efficient for real people across a wide range of sectors and job functions. Like previous industry shifts—the introduction of the PC, internet, and search—it’s a pretty safe bet that we’ll look back at this moment and see the world before AI, and a world powered by AI. It’s an all-up mindset shift that fundamentally changes how we interact with technology. In the developer space, GitHub Copilot has become the most widely-adopted AI developer tool. With over 1 million paid users across 190 countries, it’s impacting the engineering discipline in a big way. The impact for developers with AI can be accelerated even further when complemented by improving end-to-end developer experience and going beyond DevOps to embrace the practice of Platform Engineering.

The future always starts with developers—it’s developers that determine the speed of innovation. That’s why there is so much energy and emphasis spent on ensuring that the workflows of engineering teams are efficient. As every company becomes a software company, every company’s developer experience becomes essential to their agility and bottom line.

I’ve worked on developer tools and platforms for over twenty-two years, and have ridden the waves of open source, DevOps, and migration to the cloud, and I’ve seen software development change dramatically. When I first started coding, it was pretty simple. You’d set up your local dev machine, install the right IDE and all the SDKs you needed, and copy your binaries onto local servers that allowed you to manually test and debug your application. Saying that now, it practically sounds like the dark ages of development! Simpler times, but it required a lot of digital manual labor.

Confronting Complexity

But over the past two decades, software development has changed dramatically. Building and deploying distributed, cloud-native applications is a lot harder than the classic client/server apps. You have to interface with more tools to facilitate seamless collaboration across an increasingly globally distributed and time-shifted team. Open source has become not just ubiquitous but essential to every project. And each year more and more of the applications and services you build are becoming the target of malicious hackers.

The result is that developers are overwhelmed by complexity, face constant interruption, are expected to become experts in nearly everything, and continually have to context switch between tools, which impacts their cognitive load and ability to focus. We see that even on a good day, most developers only spend 84 minutes coding. Developers use an average of 16 tools per day and it takes 23 minutes to regain focus after context switching. All of this makes developers exhausted at the end of their day. What’s more, it is extremely inefficient for their organizations. And there is a tension there—organizations want their developers to be able to execute fluidly, but they also need to ensure that the software they build is secure, compliant, and hits the quality expectations of the end users.

So, the question becomes – how can the organization optimize the software development lifecycle? The answer is to focus on the developer experience and adopt the practice of Platform Engineering. As the General Manager for Microsoft’s internal engineering systems, essentially the Platform Engineering team at Microsoft, I have a front row seat as we evolve the practice of DevOps with the aim of continuing to improve team collaboration, security, compliance, costs, and time-to-business value with self-service developer experiences within a secure, governed framework.

The best compliance work feels “free.” It’s automated, invisible, and so ingrained in tools and processes that much of it is embedded.

The practice of Platform Engineering is becoming so pervasive that by 2026, 80-percent of large software engineering organizations will establish a Platform Engineering team—an answer to and solution for the increasing complexity of engineering systems, tools, apps, and assets—or technical sprawl and technical complexity, like that of cloud-native application architectures.

As a team of developers who build tools and services for other developers—both inside and outside of Microsoft—we like to think of ourselves as customer zero. Over the past many months of leading Microsoft’s own Platform Engineering effort, bringing a focus on the end-to-end developer experience and a product mindset has the power to eliminate toil throughout the development lifecycle and simplify operations for our dev teams at scale. And as software companies grow larger than ever before—with a need to drive for consistency across their organization for better business agility and customer experience—we are making our learnings available to help orient others who may be interested in setting up a practice of their own, all of which we’ve published and shared on our Learn platform.

The Importance of Developer Experience (DevEx)

Developer experience focuses on the lived experience of developers and the points of friction they encounter in their everyday work. Our research has shown that developers who have significant amounts of time carved out for deep work feel 50-percent more productive, compared to those without dedicated time. What’s more, amongst that group, developers who find their work engaging are 30-percent more productive than those who don’t. While there are some subjective factors to whether a developer finds their work interesting, a few things that we’re able to anticipate and proactively solve for are the reduction of cognitive load, ensuring developers understand the code they’re working with, empowering fast code-review turnarounds, and fast response rates to developer questions, which can reduce technical-debt by 50-percent.

At Microsoft, everything we do starts with the developer experience in mind. What we see is that when we focus on reducing cognitive load, increasing how quickly developers can get in flow, and improving how efficiently they’re able to build feedback loops into the system, we see significant improvements in product and process.

Time and time again, we see that as the demand for developers increases, the demands on developers increase, too. Tasks like onboarding new team members and taking on more operational responsibilities—all while accelerating rates of innovation of delivery—have historically hindered productivity, impact, and satisfaction amongst our internal developer base. Platform Engineering, grounded in the developer tools where developer write and review code, is our solution, and it’s the foundation for an excellent Developer Experience.

Platform Engineering and Building a Paved Path

On a very basic level, Platform Engineering is a set of patterns and practices (not an off-the-shelf product) helping to modernize enterprise software delivery. These patterns and practices, if executed right, can become the glue between development and operations teams—creating more cohesion and flow amongst teams throughout the product-making lifecycle. At its best, Platform Engineering empowers teams to achieve scale and reduce the time it takes to deliver business value—all while eliminating toil, promoting self-sufficiency, and reducing the cognitive load required to meet broader operational and organizational standards. We aim to achieve the design point of self-service with guardrails. To establish a common language, it’ll be helpful to understand these key terms:

Internal Developer Platform

As you might expect, an Internal Developer Platform is focused on a company’s internal development practices that are designed to optimize developer experience and simplify operations by encapsulating common patterns and practices into reusable building blocks, provide early advice and feedback on problems or security risks, and manage underlying infrastructure and tools.

Paved Paths

As part of an Internal Developer Platform, one defines a set of recommended and supported development “paths to production” and incrementally “paves” a way through them with an internal platform. Paved paths within an Internal Developer Platform are designed to guide developers through critical requirements and standards without sacrificing velocity. There may be more than one paved path in an organization, and some can be more well-established and well-worn than others. Whether you call them paved paths, or golden paths, or happy paths doesn’t matter—what does matter is that they reduce cognitive load and bureaucratic hurdles for both developers and operations. Adopting a product mindset means you’re trying to ensure the customers for your internal developer platform are happy, and that the business goals of the stakeholders are met.

As we continually improve our Platform Engineering practice at Microsoft, our mission is to centralize and scale specialized knowledge across the entirety of our development and operations lifecycle by reducing and eliminating cognitive load and manual steps. Applying a product mindset and learnings from DevOps and DevSecOps, we continually track our progress, share with stakeholders, and establish a core set of building blocks to grow from.

Our Learnings

1. Think of developers as your primary customer when building an Internal Developer Platform but do collaborate with critical stakeholders (like experts in specific sub-systems, operations, security, compliance, and architecture) to codify collective expertise and best practices into templates and system capabilities. Learn more.

2. Prioritize the sections of the “paved path” that should be created first, and ensure each includes approaches to streamline onboarding, moderation, and advocacy for internal use. Learn more.

3. Measuring success can be tricky—especially when measuring success of a mindset shift. Establishing consistent metrics to ensure your platform is effective and helps you retain talent is critical. Measuring speed, product quality, ease of use, and whether your internal customers say they’re satisfied and thriving will help you determine how much specific investments affected your overall numbers. Learn more.

4. Agency is important. Aiming to deliver self-service within guardrails can empower development teams to make their own decisions within a set of well-defined parameters that have been established and agreed to by stakeholders. This allows developers to work independently while ensuring security, compliance, operations, standards, and costs are properly managed. (And, using “Infrastructure as Code” (IaC) and GitOps tools is an important part of enabling self-service.) Learn more.

5. Get clear on the Internal Developer Platform product and adoption motions. “Start right” application templates can be used to bootstrap your defined paved path. Controls and governance through policy and security scanning over the course of a project lifecycle that is then shifted-left into your developer experience can ensure that code and infrastructure with “Stay right.” And as the scope of your paved path increases, you will to need to leverage auditing and reporting to move existing code, applications, and infrastructure onto your paved path. Learn more.

6. Prioritize your automation. What you choose to automate first will depend on your organization. It’s critical to plan and prioritize to meet your organization’s needs, and there’s more than just one starting point. For example, you may use something as simple as a wiki page to track how each element relates to one another. But documentation ages quickly, so alternatively, you may consider a relationship graph to power user interfaces and traverse these relationships in your inventory, or a catalogue of templates and other inventory contents. Learn more.

7. Pay attention to sprawl and waste. As you scale, you may find duplicative efforts because one team doesn’t know about another. Be mindful of technical sprawl and waste by improving discovery and relationship tracking. Having an inventory can not only help track these items, but also improve security, promote reuse, and generally make discovery easier. Learn more.

8. Meet developers where they are – in their workflows. It may be tempting to start with a unified portal to everything in your Internal developer Platform, but this may not be the best approach. Meeting developers where they are in their own workflows—in the code editors and code collaboration tools they use day-to-day—is critical for building up a Platform Engineering practice that delivers the best developer experience. These are a developer’s “existing centers of gravity,” so starting small is key to a good platform engineering user experience. Evaluate whether you can improve existing screens and surfaces through plugins or extensions before building new custom experiences from scratch. Learn more.

Striving for Impact and Satisfaction at Scale

There are over 100,000 people in the engineering profession at Microsoft – spread out across 300+ organizations, working in over 20,000 repos, and submitting over half a million pull requests each month. We have really large projects like Windows, Office, or Azure, our cloud offering, but there are also 100s of small and mid-size projects. Reducing technical debt at scale is critical to our organization, and this applies to all software organizations at large. By focusing on improving productivity through start right, stay right, and get right motions, we’re actively working to get developers in flow fast.

Developer Happiness and Customer Love

At the end of the day, this is all about developer happiness and customer love. When our tools, services, and systems support efficient ways of working at scale (without compromising privacy, security or compliance), developers are freed up to apply their ingenuity to the more creative aspects of collaborating and product making. Enterprises get the impact they’ve invested in, end-customers get products they love and trust, and the developers who deliver that impact and build those products feel more purposeful and satisfied than ever before. All’s possible with Platform Engineering. It can take work to establish a practice, but the payoff is worth it, and we’ll be here to share more learnings along the way.

Want more info on how your team can leverage platform engineering for impact at scale? Check out our tutorials, trainings, and related documentation on Microsoft Learn and watch my session on Productive and secure end-to-end developer experiences powered by AI and the Platform engineering Q&A with the Microsoft platform engineering team at Microsoft Ignite.