Improve Developer Experience: Boost Engineering Velocity Step by Step

Developer Experience – or DevEx or DX for short – is often misunderstood. It’s not about comfort, not about nice tools, and not about the well-being of individual developers as an end in itself. Developer Experience is a productivity factor.

Specifically, Developer Experience means: How much cognitive load do developers carry that has nothing to do with the actual problem they are supposed to solve? How much time is lost daily to configuration, environment setup, and administrative tasks – things that are invisible in the business results but genuinely cost time and motivation?

A developer must engage with the platform – that is unavoidable. But they don’t need to know every detail of a Kubernetes deployment just to test a feature. If that is the reality, it’s not a competence problem. It’s a Developer Experience problem.

There’s a phrase every development team knows: “It works on my machine.” Meaning: locally, in their own environment, with their own configurations. In production – or on a colleague’s computer – it looks different.

The “It works on my machine” syndrome is not an isolated problem or a coincidence. It is a symptom. A sign that development environments are not standardized, not reproducible, and not production-like. Recognizing it early can help you counteract it – before it leads to actual production outages.

Stagnation is rarely caused by technical problems alone. Most often, it’s assumptions – about roles, responsibilities, and the question of who has to adapt to whom. These assumptions are deeply rooted in many organizations and are rarely explicitly stated. That is precisely why they are so effective.

This belief is widespread – and it is wrong. Developers must familiarize themselves with a new platform, adopt new ways of working, and learn. That is correct and reasonable. But they don’t have to be a different person overnight.

A platform is not an end in itself. It is a tool – and a tool must adapt to the people who work with it, not the other way around. A platform that forces developers to completely reorient themselves before they can be productive has missed its actual goal.

The right approach reverses the perspective: Developers should find a platform on which they can work productively. This is not a question of comfort – but of effectiveness.

The most underestimated factor is cognitive load. Recent years have brought a massive increase in complexity to many engineering organizations – more tools, more layers of abstraction, more responsibility for developers. This complexity was often simply passed on without being structured or reduced.

The result: Developers carry a cognitive load that has nothing to do with the actual problem they are supposed to solve. They have to understand Kubernetes deployments, configure CI/CD pipelines, and make infrastructure decisions – in parallel with their actual development work.

Another underestimated point is the introduction of platforms themselves. Too often, demos and YouTube videos are referenced, showing how simple everything is – without considering that the foundation must be solid before building upon it.

Knowing what to do and knowing how to start are two different things. The Engineering Velocity Framework is not an all-or-nothing approach – it is an iterative path that begins with a clear first step.

Step 1: Inventory – Evaluate Tool Landscape

The first and most important step is an honest inventory. Not in isolation with the platform team, not in isolation with the developers – but together. Where is time lost daily? Which tools work, which create friction? Where do waiting times arise, and why?

This inventory provides not generic answers, but concrete, prioritized insights – tailored to your own infrastructure, your own teams, and your own bottlenecks. Only on this basis can meaningful next steps be defined.

Step 2: One App, One Team – Start Focused Instead of Broad

The most common mistake at the start: taking too broad an approach. Company-wide rollouts that try to change all teams simultaneously fail due to their own complexity.

The right approach is the opposite: one specific application, one specific team. Think through the process there, optimize it, and get it running – and then scale. Always from simple to complex. What works in one team can be transferred to others. What is introduced in a big bang has no second chance.

Step 3: Quick Wins That Immediately Build Trust

Trust in a new platform is not built through promises – but through experiences. That’s why early quick wins are crucial, not because they solve the problem, but because they show that it is solvable.

Two areas are particularly suitable for this: first, the standardization of environments, because it is immediately noticeable – onboarding is faster, setup problems disappear. Second, the Inner Dev Loop, because a measurably shorter feedback time is perceived daily in everyday work.

When developers suddenly enjoy their work again – because things simply work – platform acceptance increases. And with acceptance, adoption increases. This is not a pleasant side effect. It is the goal.

True Engineering Velocity is not shown in dashboards – it is shown in daily work. Environments become more stable. Deployments become more predictable. And the platform team is needed less often for routine tasks because developers can handle them themselves.

The costs of stagnation are real – they are just hard to see. No production outage is labeled “caused by poor Developer Experience.” No quarterly report shows how much development time was lost to configuration and waiting.

But the biggest risk is another: the shadow team. Developers who permanently bypass the platform build parallel structures that are never tested in a production-like environment. Eventually, deployment must happen – and then what was hidden for months becomes apparent.

In addition, there is a structural problem: those who do not invest in Developer Experience today will struggle with turnover tomorrow. Good developers don’t just leave for salary. They leave when they feel they are fighting more with tools than with real problems. In a market where developers are scarce, this is not an abstract risk – it is a concrete threat to delivery capability.