Developing Success: Seven Pillars of DX to Invest In

Why and where should enterprises invest in improving DX? Find out.

March 17, 2023

If your business relies on technology to enable your product or if you sell technology, then your developers are the engine of your organization. To ensure that your business continues to deliver and scale, it’s imperative that your developers are able to spend as much of their time doing what they were hired to do: develop high-quality business code quickly.  Leo Kraan, director of technology and developer experience at Booking.com, examines how and where companies should invest to improve DX (developer experience).

And although this might seem pretty straightforward, it’s often hard for engineering teams to navigate as development work has become more complex and the role of a developer has in many cases become wider to include additional operational responsibilities. Developers have become so inundated with these tasks that it’s not uncommon for a developer to spend less than half of their workday writing business code. According to a 2022 survey from SoftwareOpens a new window , only ~10% of developers spend more than 2 hours per day coding due to these distractions that divert their focus from their primary job function.  

These distractions can be found across the entire development lifecycle, from bootstrapping a new project to setting up repositories and pipelines to writing and executing tests, building and deploying pipelines, and manually testing. All stages of building, testing and delivering code can add unnecessary friction to the work of developers every day. 

What Is DX? 

Developer experience (DX) is defined as the effectiveness and satisfaction of developers to deliver quality products through quality code. In order to create a positive developer experience, companies need to focus on how developers use tools, languages, and platforms across the entire development workflow, from coding and testing to building and deploying. The goal of DX is to make development as frictionless and enjoyable as possible so that developers can focus on delivering high-quality code.

Companies that are able to prioritize DX are at a great advantage to increase productivity, improve retention, increase speed to market and decrease errors and bugs to ensure a great product. 

Imagine an environment that has 500 services which are all deployed once per week. Shaving off just 30 minutes of manual development work from each weekly cycle can save teams around 1600 developer days or 6 full-time developers per year.

Poor DX slows down the developer lifecycle and workflows, making it harder for organizations to respond to customer needs, make quick product changes or fix errors. Companies that don’t prioritize these efficiencies often result in frustrated, burnt-out developer teams who are falling behind.  

The Seven Pillars of DX

To build a strong DX, I believe there are 7 pillars to follow that will aid your design, decision making and communication. These cover many different domains.

1. Customer-focused culture

The foundation of all DX pillars is a customer-focused culture. The customer, in the context of DX, needs to be at the center of the developer team’s decision-making and the top priority for delivering a frictionless development workflow. In order to understand the customer’s specific pain points and needs, it’s important to build a strong relationship with the customer to build solutions that solve their problems. Giving customers an active role in the design and development of the DX building blocks can create a continuous feedback loop where both the customer and developers are satisfied, and developer teams receive critical feedback along the way. 

See More: Why Being Truly Customer-Centric Will be Essential

2. A shared developer workflow

Another foundation of your DX lies in a shared developer workflow: the framework of processes, tools and best practices used by developers to build software. It covers the entire development lifecycle from writing code to testing and deploying.

A developer workflow is unique to each company and reflects both its engineering culture and development requirements as well as the characteristics of the business and product. A video game, banking system and ecommerce app will likely require different testing and release strategies because of the nature of the product, its lifecycle and regulatory requirements. If a company is built around a more top down structure versus a flat environment, it will also have an impact on the workflow for the organization and freedom of its developers. This shared workflow also provides input and direction for the rest of the pillars, such as the selection of tools, the extent of automation and customization and the metrics used to measure and drive impact.

3. A unified set of tools

The development life cycle is supported by a unified set of tools to ensure consistency in the development process and create efficiency in the learning and collaboration processes. 

When selecting a unified set of tools, it’s important for teams to be intentional about what they build themselves versus what they take off the shelf. Time is the most valuable asset in engineering, so oftentimes, tools are only developed for specific use cases that provide a competitive advantage or when there is no mature solution in the market. The purpose of building a unified set of tools is the ability to leverage automation to cut down configuration and development time and allow for immediate, self-service availability through APIs and UI.

The variety of tools that are made available to a development community must depend on their technological needs but must also be balanced with the amount of support that can be provided. Any tool can lose its effectiveness and create friction if it cannot be properly used and operated.

4. Freedom with guardrails

Another pillar of DX is providing freedom with guardrails – allowing developers to make their own development and technology choices as much as possible while remaining opinionated on aspects that are non-negotiable: such as security, compliance, quality standards, operations and efficiency. Implementing these guardrails should stimulate the community to use best practices, speeding up the configuration of new projects and pipelines.

The best way for leaders to support these guardrails is to provide templates for common workloads that simplify bootstrapping, provisioning, configuration and operations and ensure that best practices and requirements are applied.

5. Metrics

Metrics are an important pillar in DX as they enable developer teams to better understand the effectiveness of their software development workflows and the quality of their output. Capturing these metrics at every phase of the development lifecycle is critical to identify where there are bottlenecks and prioritize DX improvement efforts. 

Not only are these metrics beneficial for developers, they also help leaders to understand the performance of their software delivery so that they can make the right decisions for their development, testing and release strategies. 

6. Embedded security & compliance

Most businesses are required to meet some level of regulatory compliance to ensure the security of their product, technology and environment. It’s essential for developer teams to consider these security and compliance regulations from the beginning of the development process in order to improve the developer experience, development workflow, and overall quality of work. Though some requirements may seem stringent or come with a large price tag, it is best to apply these checks and balances early in the developer workflow to give developers feedback as soon as possible. Tackling issues as early as possible can have a positive impact on the overall duration of a development cycle.

Embedding these requirements in the foundation of the developer workflow and templates will ensure that it’s easy for developers to do the right thing.

7. A culture of leadership

While the foundation of these pillars is a customer-focused culture, a strong leadership culture must be at the top. DX cannot be created only from the bottom up because it requires support from leadership to help drive the needed change forward.

While the designing, developing and operating of the DX for an organization is led by the developer teams, a company’s leadership team will be the ones to sponsor its required budget. Without a strong leadership team that understands its developers, a great DX will not be achieved. The pillars illustrate that there are a lot of different aspects to delivering a good DX, and it requires investment – one that will earn itself back. 

The required change in any organization’s development workflow and tooling can be impactful to the development community. The communication and enforcement of these changes by leadership will make the change more effective. Leadership also drives the culture of the organization and can help cultivate a culture that values and prioritizes the DX for both productivity and developer happiness.

See More: 4 Steps to Create a Strong Leadership Culture in a Startup Environment

The Benefits Will Quickly Outweigh the Costs

A good DX is critical for any organization to improve the output of its developers, which will ultimately improve business performance. Developers are the engine of the organization and one of its most valuable assets. A better DX will improve their happiness and improve retention. 

Wherever you are in your DX journey, whether you are considering investing in this or are already implementing it, these pillars can help you assess and design the approach that suits your developers and organization.

Are your developers happy? How are you improving DX within your organization? Share with us on FacebookOpens a new window , TwitterOpens a new window , and LinkedInOpens a new window .

Image Source: Shutterstock

MORE ON DEVELOPER EXPERIENCE

Leo Kraan
Leo Kraan

Director of Technology, Developer Experience, Booking.com

As Director of Technology, Developer Experience at Booking.com, Leo leads language and workflow tooling teams to improve developer productivity and joy. He was previously at Gamehouse and Ernst & Young.
Take me to Community
Do you still have questions? Head over to the Spiceworks Community to find answers.