Developer Experience | Engineering Leadership

Every company wants velocity. Few invest in the engine.

Developer Experience, or DevX, is routinely treated as an internal engineering concern. Organizations talk about faster builds, better development environments, clearer documentation and automated pipelines as though they are simply conveniences for software engineers.

The conversation often starts with a simple premise: engineers are more effective when their tools and processes get out of the way. That is true, but it misses the bigger picture.

The real question is not simply whether developers experience less frustration. It is whether the way an organisation builds software strengthens its ability to compete, execute and deliver value to customers. When viewed through this lens, DevX stops being a developer productivity initiative and becomes a business capability.

A mature organisation should not think about engineering in isolation. Investments in technology, engineering practices, platforms, AI capabilities and ways of working may begin inside the engineering organisation, but their value should not stop there. They should improve delivery, strengthen business outcomes and ultimately create better experiences for clients, customers and end users.

Developer Experience is a powerful example of this connection.

Where most companies get stuck

DevX has a persistent positioning problem. Leadership may hear the term and picture better code editors, expensive platform tooling or engineers optimising pipelines for marginal efficiency gains. But organisations that deliver products quickly and adapt effectively to changing market conditions are not necessarily those with the largest teams or the biggest technology budgets. They are often the organisations with the least unnecessary friction between an idea and a reliable outcome.

When engineering improvements start and end inside the technology team, they can struggle to secure sustained investment. However, when improvements to engineering systems contribute to faster time to market, better quality, more predictable delivery and stronger project economics, the conversation changes. DevX stops looking like an internal cost and becomes an investment in the organisation’s ability to execute.

This distinction is important because many organisations do not lack talented engineers or modern technologies. What they often lack is a deliberate approach to improving the system around those engineers. As teams and systems grow, small inefficiencies begin to compound, reducing the organisation’s ability to turn engineering effort into delivered value.

What scaling without DevX looks like

The failure to address engineering friction rarely causes a sudden collapse. Instead, it creates a gradual and costly degradation of delivery capacity.

A business identifies an urgent client or customer need. Product teams define the requirement, and engineers build the solution. Before that change reaches the customer, however, it may enter a maze of manual steps, fragile environments, slow test pipelines and fragmented documentation. Engineers spend time troubleshooting failed pipelines, requesting access, configuring environments and rediscovering knowledge that exists only in someone else’s head.

Two organisations can employ equally talented engineers and adopt similar technologies. One may provide reproducible environments, reliable automated testing, accessible knowledge and clear system ownership, while the other depends heavily on manual handoffs, slow feedback and individual heroics. The headcount may be identical, but the effective engineering capacity is not. The difference lies in the engineering system around the people doing the work.

Over time, this friction compounds. Release cycles become longer, small changes feel increasingly risky, and engineers spend more time navigating the delivery system than solving meaningful problems. By the time delayed roadmaps and missed opportunities become visible to leadership, the problem is often much larger than a missing tool. The delivery system itself has become increasingly difficult to change.

The true economics of delivery friction

Software creates value because it can change. Market priorities shift, security vulnerabilities emerge, regulations evolve, clients refine requirements and customers provide feedback. The ability to modify software safely and predictably is therefore one of the most important capabilities of a modern technology organisation.

Yet the true cost of a software change is rarely determined by the amount of code alone. It is influenced by the engineering effort required, the complexity of the system and the friction surrounding delivery. A useful way to think about it is:

Cost of Change = Engineering Effort + System Complexity + Delivery Friction

Some complexity is unavoidable, particularly in enterprise technology environments. However, a significant amount of delivery friction is created by the way organisations design their engineering systems, processes and ways of working.

When unnecessary friction is reduced, the benefits can be seen across different delivery models.

Protecting fixed-cost delivery economics

In fixed-cost engagements, the commercial value of the project is agreed upfront. Every hour spent dealing with avoidable environment problems, manual processes or inefficient delivery workflows consumes engineering capacity. That capacity could otherwise be focused on solving client problems, improving quality or responding to changing needs.

DevX helps protect delivery economics by reducing unnecessary internal friction and allowing more of the available engineering capacity to be directed towards meaningful outcomes. The benefit is not simply lower effort. It is a greater ability to convert engineering effort into client value.

Compounding long-term product value

For long-lived products, delivery friction compounds over time. When deployments are painful, teams tend to release less frequently. Larger and less frequent releases can introduce greater risk. When changes become difficult, improvements are postponed, and when feedback is slow, problems are discovered later.

Over time, friction contributes to technical debt, and technical debt creates even more friction. A strong DevX foundation can help reverse this cycle. When changes are easier and safer to make, teams can improve systems continuously rather than waiting for large transformation programmes.

The benefit compounds. An improvement to the engineering system today can make every future change easier.

Transforming speed into quality

Speed and quality are often presented as trade-offs. In a weak engineering system, they can be. Under delivery pressure, teams may reduce testing, postpone automation or take shortcuts that create problems later. That may appear faster in the short term, but the cost has simply moved elsewhere.

A defect that could have been identified earlier becomes a production issue. A manual process that saves time once becomes repeated operational effort. A technical shortcut makes the next change more difficult.

A mature engineering system changes this dynamic. When automated checks, rapid feedback and continuous integration are built into the way teams work, quality becomes easier to maintain without requiring engineers to choose between speed and discipline. Practices such as trunk-based development can reduce the complexity and risk associated with long-lived branches, while feature flags can separate the technical act of deploying software from the business decision to release functionality. Together with automated testing and continuous integration, these practices help teams keep changes smaller, integrate work more frequently and release with greater confidence.

The value, however, is not in adopting a particular methodology, tool or engineering practice for its own sake. The value comes from creating an engineering system where change can move through the organisation safely, predictably and with less friction. That is what ultimately enables engineering speed to translate into business agility and better customer outcomes.

What DevX actually requires

Transforming Developer Experience from an internal engineering topic into a business capability requires deliberate investment across the engineering system, not simply in developer tooling. This includes the environments engineers use, the feedback they receive, the way systems are owned, how software is tested and released, how knowledge is shared, and how engineering outcomes are measured.

AI can accelerate the experience, but it cannot replace the system

AI-assisted development is increasingly becoming part of the modern Developer Experience. Coding assistants and agentic tools can help engineers understand unfamiliar code, generate implementation ideas, improve tests, troubleshoot issues and navigate technical knowledge. Used effectively, these capabilities can reduce friction and shorten the time required to move from a question or idea to meaningful progress.

However, AI does not replace the foundations of engineering maturity. Faster code generation does not compensate for unclear architecture, fragile environments, poor test coverage, slow feedback cycles or unreliable delivery processes. In fact, as AI enables teams to create and modify software more quickly, weaknesses in the surrounding engineering system can become even more visible.

The opportunity is therefore not simply to make engineers produce more code. It is to combine AI capabilities with strong engineering practices so that increased speed can translate into reliable delivery and meaningful business outcomes.

Environment automation helps move teams away from manual setup and inconsistent environments towards self-service, reproducible development environments that engineers can use with confidence.

Rapid feedback cycles reduce the time engineers spend waiting for builds, tests and security checks, allowing issues to be identified and addressed while context is still fresh.

Clear system ownership reduces ambiguity around who owns services, pipelines, platforms and technical documentation, while reliable delivery pipelines move organisations away from fragile and heavily manual release processes towards automated, observable and recoverable workflows.

Accessible engineering knowledge ensures that critical understanding is not dependent on a small number of individuals and can be accessed when teams need it.

Finally, business-aligned measurement ensures that organisations do not stop at measuring internal engineering improvements but also understand whether those improvements are creating better delivery and business outcomes.

The objective is not to accumulate more tools or create another internal transformation programme. It is to remove the constraints that prevent engineering capability from becoming delivered value.

Measuring DevX: from friction to outcomes

If DevX is an investment, its impact should be measurable. That begins with understanding the current state.

Before introducing a new platform, tool or engineering initiative, organisations should establish a baseline. How long does it take for a new engineer to become productive? How long does it take to set up a working development environment? How quickly do engineers receive feedback from builds and tests? How frequently are delivery activities interrupted by tooling or environmental problems? How much manual effort is required for common engineering workflows?

The baseline provides a clearer picture of where friction exists and, more importantly, where improvement is likely to have the greatest impact.

The next step is to define the target state. Perhaps the goal is to reduce environment setup from days to hours, significantly shorten CI feedback time or enable smaller, more frequent and more reliable releases. The appropriate targets will depend on the organisation, its systems and the nature of its work.

The objective is not to chase arbitrary industry numbers. It is to understand where the organisation is today, identify the constraints that matter most and deliberately improve them.

Leading indicators: are we reducing engineering friction?

Leading indicators provide early evidence that the engineering experience is improving. These may include environment setup time, onboarding time, build duration, test execution time, the number of manual steps required in common workflows and the frequency of tooling or environment issues. Developer feedback can also provide valuable insight because engineers experience friction directly and can often identify problems before they become visible through delivery metrics.

However, these indicators are not the final measure of success.

Reducing a build from twenty minutes to five minutes is an improvement, but the purpose is not simply to have a faster build. The real question is what that improvement enables. Does faster feedback improve engineering flow? Does it allow teams to validate changes more effectively? Does it contribute to better delivery performance?

Leading indicators tell us whether we are improving the conditions in which engineering work happens.

Lagging indicators: are delivery outcomes improving?

The next level of measurement looks beyond the engineering experience itself and asks whether improvements to the engineering system are producing better delivery outcomes.

This is where software delivery measures, including the DORA metrics, can provide useful insight. Lead time for changes can help organizations understand how efficiently software moves through the delivery process. Deployment frequency can provide insight into the ability to release changes. Change failure rate can help assess the reliability of those changes, while time to restore service provides insight into how effectively teams recover when something goes wrong.

These metrics do not directly measure Developer Experience. They measure outcomes from the broader software delivery system. They are therefore best used alongside DevX-specific leading indicators rather than as a substitute for them. For example, an improvement in deployment frequency is meaningful only when considered alongside whether engineers can make changes safely, whether change failure rates remain healthy and whether the additional delivery capacity is translating into meaningful business outcomes.

DevX is one part of that system, alongside architecture, engineering practices, team structure and organisational processes.

A mature approach is therefore not to search for a single DevX metric but to measure the chain of impact.

DevX Investment → Reduced Friction → Improved Engineering Flow → Better Delivery Performance → Business and Customer Outcomes

The final part of that chain is where the business case for DevX becomes most meaningful.

The ultimate measure: did the investment create value?

The impact of engineering improvements should eventually be visible beyond engineering.

For a product organisation, DevX improvements may contribute to faster time to market and a greater ability to respond to customer feedback. For a technology organisation delivering client projects, they may contribute to greater predictability, reduced rework and more effective use of engineering capacity. For fixed-cost engagements, they may help protect project economics by reducing the amount of capacity consumed by avoidable internal friction.

For customers and end users, the impact may be experienced through more reliable products, faster improvements and better overall experiences.

This is why both leading and lagging indicators matter. Leading indicators help us understand whether we are improving the engineering experience and reducing friction. Lagging indicators help us understand whether those improvements are creating the delivery and business outcomes we intended.

Together, they provide a more complete picture of whether engineering investment is creating real value.

Engineering maturity means looking beyond engineering

Engineering maturity is often associated with modern technology, sophisticated architecture or the size of an engineering organisation. Those things matter, but maturity is also reflected in how an organisation connects internal engineering capability to external outcomes.

A less mature organisation may depend heavily on individual knowledge and heroics. A more mature organisation increasingly turns repeated knowledge, processes and capabilities into reliable systems. Manual activities become automated, recurring problems are solved once and made reusable, and knowledge held by individuals becomes accessible to the wider organisation. Fragile environments become reproducible, while quality checks become integrated into the delivery process.

The organization becomes less dependent on people overcoming the limitations of the system and more capable of delivering consistently through the system itself.

Developer Experience is part of this evolution. However, DevX should not be an end in itself, and neither should engineering productivity. The work may start inside engineering, but the value should continue beyond it.

An engineer benefits from reduced friction. Engineering teams benefit from better flow. The organisation benefits from improved delivery capability. The business benefits from greater speed, quality and responsiveness. Clients and customers benefit from better outcomes.

Ultimately, end users experience the value through the products and services they use.

Final Thoughts

Developer Experience is often discussed as something that matters primarily to engineers. At Avlyon, we believe its impact reaches much further.

The work to improve DevX may start with engineering leadership and involve better automation, stronger platforms, clearer ownership, accessible knowledge, AI-assisted capabilities and improved ways of working. The initial progress may be visible internally through faster feedback, reduced friction and a more effective engineering experience.

But that should not be where the story ends.

The real value of Developer Experience is realised when improvements inside engineering create better outcomes outside it. Reduced friction can help a business bring ideas to market faster, while better feedback and automation can improve software quality. Stronger engineering capabilities can provide clients with greater predictability and confidence and help technology teams respond more effectively to changing customer needs.

Ultimately, the value is experienced by the people who use the products and services we build.

This is how we see engineering maturity at Avlyon.

Engineering excellence is not an isolated objective. Technology, engineering practices and internal capabilities are valuable because of what they enable for the business, clients, customers and end users.

Developer Experience is one example of this principle. It may begin as an investment in the way engineers work, but its success should ultimately be visible in the outcomes the business achieves and in the experiences of the people who depend on the technology we build.

Because the work may start inside engineering.

But the value should not stop there.

To explore how stronger engineering practices and delivery capabilities can support better business outcomes, connect with Avlyon.