By Thomas Delaet, Arun Gundurao, Ling Lau, Stephan Schneider, and Lars Schor
For IT organizations that have gone through agile transformations and cloud migrations, the next set of opportunities to unlock engineering productivity is in developer experience (DX). Putting DX at the center of their efforts can help organizations improve employee attraction and retention, enhance security and quality, and increase developer productivity.
Why you should be thinking about DX
Much like employee experience more broadly, great DX makes life easier for developers, which in turn translates into higher performance. Developers today often spend a lot of time fighting against bottlenecks and organizational red tape, sending emails, going to meetings, and chasing people they need just to complete their work. Common tasks that are cumbersome for developers include deploying code to production, creating change requests, ramping up infrastructure, figuring out which tooling to use for things such as security testing, or establishing a new component and integrating it into an existing platform. Organizations that prioritize DX to overcome such common obstacles will generate improvements in several areas:
- Talent attraction and retention. The best engineers in the world want to work for the best tech companies, not only because they have a great brand but also for their robust tech culture and high employee satisfaction. In such organizations, developers can do what they do best—build great software with cutting-edge tools—while avoiding bureaucracy and work that doesn’t add value.
- Productivity and cost savings. Developers who spend less time on handling boilerplate activities and locating the resources they need to do their job can reduce the time it takes from idea to code that solves a customer problem from months to just minutes. This increased productivity requires targeted investments in DX, but such spending has a high ROI: for example, in a population of 500 software developers, the savings produced by reducing each developer’s wasted time by just five minutes a day could support a full team of developers working on standardization.
- Consistency and quality. Standardizing and productizing the entire tool stack for developers contributes to better DX and improves the quality of digital products because building something great based on great components and tools is much easier than doing it with mediocre components and tools. Further, tooling that is easy to find, consume, and integrate lets developers focus on what really matters.
- Security and compliance. When security and compliance are baked into components from the start—for example, when security testing is part of the enterprise-wide continuous integration/continuous delivery (CI/CD) pipeline or default compliance policies are embedded in all cloud environments—required compliance is in place right out of the box, thereby massively reducing teams’ efforts on routine work and meeting the organization’s audit, security, and risk requirements. In addition, compliance procedures are standardized across the organization rather than varying with each team’s knowledge and preferences.
- Speed. By reducing handovers and coordination between teams, eliminating rework through early feedback on quality checks (such as testing, code quality, and controls), and fully automating the path to production, developers can cover far more ground much faster. That enables organizations to achieve deployments multiple times a day instead of once every few weeks or months.
What does distinctive DX look like?
Great DX can be enabled by a platform that serves developers’ needs across several elements:
- Readily available platform, infrastructure, and development tooling that includes structured and clear documentation, such as tutorials, demo environments, and curated learning paths. Fast self-service onboarding with one-click deployment, for example, enables developers to create new instances with prebuilt components, receive API keys, and get user access—without emails, meetings, or waiting time. In addition, a set of tools and bots can help developers by automating standardized tasks to deliver code to production.
- One-stop shopping for all developer needs. In many organizations, developers have to sift through 20 different tools to find what they need, which is time consuming. A central DX platform can house all documentation, APIs, and infrastructure products, among other elements, in an app-store-like environment based on a structured service catalog.
- Reduced complexity. When developers can select app patterns (such as an API microservice, front-end journey) and deploy them within minutes (including environments, a pre-integrated DevSecOps pipeline, monitoring, and fully automated change and release processes), they can avoid weeks of repetitive work before actually starting to write code. This standardized technology stack results in built-in security and quality by design, with reusable components.
- Asset transparency through centralized tracking of the status and versions of software, APIs, and infrastructure services currently in use. A real-time view promotes adherence to architecture standards, security controls, and patching status of security and audit issues. Bots can support this effort by automatically suggesting changes to source code to address code “smells,”1 patching, and library upgrades. These changes can be presented to developers via pull requests.
- Key performance indicators (KPIs) and FinOps dashboards. Self-service onboarding can equip teams with standardized dashboards to measure and compare their performance along KPIs such as velocity, tech debt, error rate, mean time to recovery, and infrastructure cost. Standard tooling in use across the organization, such as backlog, pipeline, and monitoring tooling, can pull these metrics automatically.
DX in action
A leading software as a service (SaaS) provider was on a multiyear journey to transform into a technology innovator through DevSecOps, hybrid cloud, and site reliability engineering (SRE). To deliver code through its CI/CD pipeline, developers were spending 20 to 30 percent of their time integrating such disparate services as firewall changes, domain name system (DNS), and security access in order to enable an end-to-end testing environment, and coordinating multiple manual steps, such as change orders, approvals, and quality evidence. The CIO initiated a holistic DX program, which involved setting up platform teams with true product managers to provide developers with a common, secure CI/CD pipeline and unified security services. A best-in-class experience portal, APIs, and GitOps for developers enabled these services to be offered in real time.
Adoption was systematically rolled out to more than 2,000 developers using a structured engineering capability-building program. This approach included culture change, inner-source contributions, and data-driven visibility into the pace of adoption across teams through gamification. The impact of the DX program was significant: developer productivity rose 10 to 20 percent, critical incidents dropped by up to 20 percent, and security vulnerabilities were cut by 15 to 20 percent. Further, these services received top-quartile scores from developers for customer satisfaction.
Ten steps to ensure great DX
IT organizations should seek to weave ten principles into a coordinated effort to enhance DX:
- Focus on the user. The most important customers of a developer-experience platform are developers. The platform needs to provide a golden path, not a golden cage. Developers need to be heavily involved in the design, prioritization of features, and testing to make sure the platform is fit for purpose and fully self-service. Focusing on creating a usable design that addresses the real needs of developers will make all the difference.
- Treat the platform like a product. Establish a small central team that owns the DX platform and is responsible for adapting it, making sure it is easily consumable, and ensuring it fulfills developers’ needs.
- Decentralize the contribution model. A central team fully owning the development does not scale, nor does it allow organizations to source the best of the enterprise. The central team that owns the platform needs to make sure the contribution model allows for decentralized, continuous development where everybody can share plug-ins and propose changes—like an open-source model, but within the organization (inner-sourcing).
- Define success as usage. A key indicator of success is an organization’s ability to drive traffic to the platform and entice developers to use it daily. This requires careful planning and implementation of features; an emphasis on change management, including an exciting minimum viable product (MVP); and tracking usage, such as contributions from other teams and number of daily users. In short, developers should use the platform because they want to, not because they have to.
- Measure impact. Be clear what the organization is trying to improve and measure KPIs from day one. For instance, Salesforce tracks the duration of the process from idea to code that solves a customer problem (with the goal of less than one hour), and Spotify measures new developers’ productivity by, for example, seeing how long it takes for them to complete their tenth pull request (with the goal of less than 20 days).
- Get the most from existing capabilities. Use tools that have already been productized and adopted by the organization (such as backlog management, CI/CD toolchain, and container platform) and let the existing team pursue integration through plug-ins into the platform. Where applicable, organizations should use open-source tooling and a cloud-native approach.
- Build capabilities from day one. This effort is not about attracting a set of great platform engineers to build the platform but about building a critical mass of platform engineering capabilities. Organizations should seek to define curated learning paths—for consumer teams on how to make the best use of the platform, for example, and for provider teams on how to handle integrating their products into the platform via plug-ins.
- Evangelize the platform. Promote an engineering culture and practices to drive adoption in your DevOps teams. Some options to create excitement include plug-in hack days and demo days. In addition, organizations can identify dedicated champions until the DX platform becomes part of the organizational culture.
- Manage change. DX is not just about the technology but also all prerequisites that need to be in place to support platform adoption and usage. Change management typically requires strong governance, a collaborative and high-performing engineering culture, and changes to the operating model.
- Think big, act small. To ensure the platform delivers value from day one and can also scale, the MVP scope should be limited to the first customer or use case. However, an up-front design sprint with more stakeholders can be conducted to future-proof the technology choices.
Achieving better developer experience is the critical next step for organizations to unlock IT engineering productivity. Standardization of application and infrastructure stacks (defined as code), extreme automation, and a one-stop shop for all developer needs help developer teams deliver better-quality software at a significantly faster pace.
Thomas Delaet is a partner in McKinsey’s Brussels office, Arun Gundurao is an associate partner in the New York office, Ling Lau is a partner in the New Jersey office, Stephan Schneider is an associate partner in the Copenhagen office, and Lars Schor is an associate partner in the Zurich office.
1 Any characteristic in a program’s source code that suggests a deeper problem.