DevEx Is a Business Concern

At Jimdo, we help solopreneurs and small businesses succeed by making it easier to build, launch, and grow online. But behind every feature and improvement we ship is a team of developers. And what experience do these developers have building our products? It’s not just an engineering topic. It’s a strategic lever.

In this post, we will explain how we have made Developer Experience (DevEx) a priority at Jimdo, not just in engineering, but across the business. This is not a story about frameworks or complex acronyms (though we do use some of those, too). The article refers to how DevEx has become integral to the way the company thinks, plans, and operates in software engineering.

As product companies, we talk a lot about customer experience and solving customer problems. But what about the people who build those experiences?

To put it simply: Happy developers are productive developers. Productive developers create better products more quickly, reliably, and confidently.

But there is a catch: DevEx is something everyone should be responsible for, but no one really prioritises. It gets squeezed between business goals, product deadlines, and technical debt. At Jimdo, we wanted to change that.

When we first started thinking about taking DevEx seriously, it was clear that if we wanted to make it better, we needed to stop seeing it as a side project. We had to make it a top priority.

We started with something simple. We agreed on what DevEx is and what it isn’t. It’s not just faster builds or better ways of managing the software development process. It’s all about the experience of building. We based our work on the research on DevEx from Noda, Abi et al. (2023). DevEx: What Actually Drives Productivity. ACM Queue. https://doi.org/10.1145/3595878.

Three core dimensions of developer experience
*Noda, Abi et al. (2023). DevEx: What Actually Drives Productivity. ACM Queue. https://doi.org/10.1145/3595878

Interruptions kill momentum. If a developer has to wait 30 minutes for a build just to test a fix, flow is gone.

Speed matters. If it takes days to get a PR reviewed, velocity suffers. DevEx means shortening these loops.

Context switching, inconsistent tooling, and tribal knowledge — these all make development harder than it needs to be. Standardization and simplification go a long way.

These three pillars: Flow, Feedback, and Cognitive Load — became the lenses through which we view all software engineering work.

It is important to understand that you want to have a look at the three things mentioned before in a qualitative (how people think) and quantitative (how things are done) way to understand DevEx better in the company. Workflows show you the “what” (e.g., build times, PR cycle time, or deployment frequency), but only perceptions show you the “why” behind developer satisfaction or frustration. This dual lens becomes especially important when comparing experiences across teams.

For example, if Person 1 and Person 2 are cooking pasta, Person 1 wants to cook spaghetti and Person 2 wants to cook farfalle. They both follow similar instructions (e.g., same water, same salt, same boiling point), but use different pots that are suited to their type of pasta. Person 2 uses a wide, flat pot. This means the water boils faster. Person 1 uses a taller pot. This means it takes longer for the water to boil. But both end up with pasta that’s perfectly al dente. If you only looked at the time it took, you’d miss the full story. They each had to work within different limitations, and both results were exactly what they had planned. Ask them how they feel about the result. They’d both say they were completely happy.

That’s why in DevEx, you can’t measure success on its own. You need to look at the workflows and perceptions to know if you’re truly helping to make things excellent.

We quickly realised that DevEx is important for the company, the engineering team and the product team. This meant finding a balance between different options, like innovation and stability, or long-term goals and short-term results.

We got real about it. We didn’t want DevEx to be a vague idea like “make things better.” We wanted a measurable, repeatable impact.

1. Grounded Ourselves in Research

We studied industry models like DORA, the general research on DevEx, and worked to understand how DevEx differs from just measuring “developer productivity.” Our mantra: optimize the system, not the individual.

2. Ran Our First DevEx Survey

We launched a simple internal survey to understand how developers felt about their day-to-day. We combined this with DORA metrics we had at hand to add data to our intuition.

3. Centralized Key Metrics

We brought together both quantitative (e.g. PR turnaround time, deployment frequency, meeting hours) and qualitative data (developer sentiment, blockers). Everything in one place, so we could make better decisions.

4. Started Tracking Flow, Feedback and Cognitive Load

We focused hard on metrics that reflect flow, feedback loops and cognitive loads: Time spent in meetings, review response time, PR sizes, build times.

5. Acting on the findings and problems we found

Collecting and analyzing data is only half the battle. What matters is what you do with it. After extracting the insights from our surveys and metrics, we ensured that each finding was triaged within the teams. The key question was: Can the team address this locally, or does it point to a systemic, organisation-wide issue? This enabled us to act with precision.

For example, we introduced new guidelines regarding PR sizes and reinforced expectations regarding review turnaround times and the time taken for the first review. We also optimised meeting schedules across teams to better protect focus time. On a broader level, we reinforced our product and company strategy narratives to help teams align their day-to-day work with the bigger picture.

6. Made It a Recurring Habit

Every quarter, we repeat our DevEx surveys and ask two simple questions:

• Did things get better in the areas we identified last time?
• What new challenges are emerging and how can we solve them locally (in teams) and on wider scale (e.g. for all of engineering)?

What’s been especially powerful is connecting shared capabilities (such as CI speed, dev environments and design tokens) to a real DevEx metric. It helps us show how investments in platforms (and generally engineering) add up to the impact on developers and, finally, the delivery of products and solving customer problems.

We’ve been on this journey for around 18 months. We’ve seen improvements in flow state, review cycles, and onboarding experiences. But we’re still learning.

DevEx isn’t a project. It’s a practice.

It’s not just something solely engineering should worry about. It’s a business concern. Because when developers have a better experience doing their work, everyone wins: Products ship faster, quality improves, and morale stays high.

If you’re thinking about DevEx at your company, here’s our advice:

• Don’t wait for perfection. Start with a simple survey.
• Don’t aim to measure “productivity.” Aim to understand pain points.
• And most importantly: treat DevEx like a product. With a strategy, ownership, and feedback loops.

At Jimdo, we’re not done yet. But we’re proud to have made DevEx a business priority, not just a buzzword. And we’re happy to keep sharing what we learn along the way.