Developer Experience Is Broken: Who’s Responsible for Fixing It?

Developers lose an entire working day every week to inefficiencies, slow CI, broken local environments, missing documentation, endless context switching. Based on insights from over 2,100 developers and engineering leaders, a hidden crisis exists: developers lose an entire day each week to inefficiencies. The tools exist to fix this. The knowledge exists to fix this. What is missing is clarity on whose job it actually is. That ambiguity is the real problem, and it is costing organisations far more than they realise. The Day That Takes a Month to Ship The single sharpest symptom of bad developer experience is famous: you can write the code in a day, but ship it in a month. That gap is not a coding problem. It is a systems problem, slow CI, flaky tests, missing docs, review bottlenecks, and interruptions that stretch a one-day change into a four-week saga. Every developer reading this has lived that month. You know exactly what fills it.Waiting 40 minutes for a CI pipeline to tell you whether your 10-line change broke anything. Onboarding a new team member and discovering that nobody has updated the local environment setup docs since 2023. Submitting a pull request that sits unreviewed for three days because the senior engineer whose approval is required is in back-to-back meetings. Spending Tuesday afternoon hunting for the right Slack channel to ask about an internal API, finding three different channels with conflicting information, and eventually DMing someone directly. None of these are hard problems technically. The CI pipeline could be faster with better caching and test parallelisation. The onboarding docs could be maintained if someone owned them. The PR review process could be restructured. The internal knowledge could be indexed and searchable. They persist not because the solutions are unknown, but because nobody is clearly responsible for implementing them. A developer experience gap is delaying application deployment, according to a survey of over 500 platform teams and application developers at enterprises. High-quality developer experience has become a critical priority in software delivery, with 58% of software engineering leaders reporting that developer experience is very or extremely critical to the C-suite. Fifty-eight percent say it is extremely critical. Yet the lost day persists. Something is not connecting between the executive priority list and the actual conditions developers work in every day. This article is about that gap, what causes it, who is actually responsible for closing it, and what fixing it concretely requires. What Developer Experience Actually Is Before arguing about who should fix it, we need to be precise about what we are talking about. Developer experience gets used as a catch-all term for everything from "we need better laptops" to "we should rewrite the monolith." Most of those conversations go nowhere because the term is too broad to produce clear action. Developer experience is the day-to-day friction developers feel turning an idea into shipped, running software, formalised as a measurable discipline in a 2023 ACM Queue paper that distilled 25 sociotechnical factors into three dimensions: feedback loops, cognitive load, and flow state. These three dimensions give us a framework sharp enough to actually diagnose problems and assign responsibility: Feedback loops: how quickly does a developer know whether what they just did worked? The fastest feedback loop is a type error caught in the IDE as you type. The slowest is a bug discovered by a customer in production two weeks after deployment. Everything in between, unit test execution, CI pipeline completion, PR review turnaround, deployment verification is a feedback loop with a speed that someone designed, intentionally or by neglect. Cognitive load: how much mental overhead does a developer carry to do their work? Reading an unfamiliar codebase with no documentation. Holding twelve browser tabs open because information is spread across multiple disconnected systems. Remembering which of the three very similarly named microservices handles payments. Trying to understand a CI pipeline that has grown organically over four years without anyone designing it holistically. Frequent interruptions, unclear priorities, excessive bureaucracy, and slow feedback cycles all create friction. That is why simplification matters, clean code, consistent patterns, accessible documentation, and intuitive tooling help reduce mental overhead. Flow state: how much uninterrupted time does a developer get to actually think? Flow state is what happens when a developer can work with deep concentration on a meaningful task. In that state, work tends to move faster and with higher quality. The problem is that flow is fragile. Meetings, messages, context switching, and random interruptions can break it quickly. Every developer experience problem traces back to one of these three dimensions. CI pipeline too slow? Feedback loop problem. Too many tools with no clear workflow? Cognitive load problem. Constant Slack interruptions during focus hours? Flow state problem. Once you can name which dimension is broken, you can name who is responsible for fixing it. The Responsibility Gap Why Nobody Fixes What Everyone Knows Is Broken Here is the uncomfortable truth that most developer experience conversations dance around: developer experience problems persist primarily because responsibility for them is diffuse, contested, and structurally unclear in most organisations. Consider the CI pipeline that takes 45 minutes. Who owns it? The engineering team that wrote the tests? Their job is to write good tests, not to optimise the pipeline infrastructure. The DevOps or platform team? Maybe, if one exists, but their backlog is full of infrastructure work, and "make CI faster" competes with "migrate to the new Kubernetes cluster" for sprint allocation. Engineering management? They care about it in principle but rarely have the technical context to prioritise it correctly against other competing work. The CTO? They just read that 58% of engineering leaders consider DevEx critical. They send a Slack message asking "how are we doing on developer productivity?" and receive a carefully optimistic response. Nobody is wrong. Nobody is lying. The CI pipeline is 45 minutes because the problem falls into the gap between several teams' areas of responsibility, and gaps do not get filled unless someone decides to own them regardless of formal scope. Too many tools. No clear ownership. Automation that hides problems instead of solving them. This is not an accident of organisational design. It is the predictable outcome of treating developer experience as a desirable property that emerges naturally from good engineering, rather than as a product that must be built, owned, measured, and continuously improved by someone whose job specifically depends on it. The Five People Who Should Be Fixing This (And What Each One Is Actually Responsible For) The answer is not "everyone is responsible", which in practice means nobody is. The answer is that different dimensions of developer experience have different natural owners, and the fix requires making that ownership explicit. 1. The Platform Team Owns the Infrastructure of Development Platform engineering should be treated like a product. DevEx in 2026 includes AI integration workflows. Cognitive sustainability matters. If your organisation has a platform team, they are the primary owner of the feedback loop dimension. CI pipeline speed. Local development environment reliability. Internal tooling consistency. Deployment pipeline design. These are infrastructure problems, and infrastructure is the platform team's domain. The onboarding as a DevEx metric framing is the one more platform teams need to adopt. Teams hit the wall running a stack across a dozen-plus services and watching new hires take two weeks to get a local environment running. The fix was not a better README, it was treating the local dev environment itself as a product with an SLA. One-command bootstrap, shared environment schema, trunk-based dependency contracts. Thirty-minute onboarding is not aspirational in 2026, it is a signal that the platform team is doing its job. The specific accountability the platform team should own: Onboarding time. How long does it take a new developer to make their first commit to production? If the answer is not measurable, that is itself the problem. Thirty minutes to first commit is achievable. Two weeks is a broken developer experience. CI/CD pipeline performance. Median pipeline duration. P95 pipeline duration. The percentage of pipeline runs that fail due to infrastructure issues rather than test failures. These should be tracked like production SLAs, because from a developer's perspective, they are production SLAs. Local environment parity. Does the local development environment behave the same as staging? If a developer's code works locally but fails in CI, the cause is almost always environment parity breakdown, and environment parity is a platform team responsibility. Internal tooling cognitive load. How many different tools, portals, and systems does a developer interact with in a typical working week? Every additional tool is cognitive overhead. The platform team should be actively reducing this number, not adding to it. 2. Engineering Management Owns the Meeting and Interruption Problem Flow state is destroyed by interruptions, and the primary source of interruptions in most software organisations is the meeting schedule. This is squarely an engineering management problem. A developer who has their calendar blocked into three-hour focus windows in the morning and meetings clustered in the afternoon has a fundamentally different daily experience than a developer whose calendar looks like a game of Tetris where every hour has something in it. The code is the same. The tools are the same. The developer experience is completely different because one manager understands what flow state requires and the other does not. The specific accountability engineering managers should own: Protected focus time. Core coding hours with no meetings scheduled, agreed at team level, enforced by the manager when someone from outside the team tries to book across them. Meeting hygiene. Stand-ups that are genuinely daily and genuinely brief. Retros that produce actionable changes, not just discussion. Sprint ceremonies that are efficient enough that developers do not resent them. The manager who allows meeting culture to expand until it consumes most of the working day has made a developer experience decision, even if they have never used the phrase. On-call burden. Flat teams with broad responsibilities sound empowering but often leave engineers shouldering operational, security, compliance, and on-call duties without backup. The result is a constant feeling of being slightly behind in everything. Burnout is expensive. Teams with high burnout report higher defect rates, slower delivery, and turnover that costs roughly 1.5 to 2 times annual salary per departure when recruiting, onboarding, and lost productivity are included. On-call rotation design- who is on call, how often, with what escalation path, and with what expectation of daytime interruptions during on-call weeks, is a developer experience decision that engineering managers make, whether they think of it that way or not. PR review turnaround. A pull request that sits unreviewed for three days has a cost: the developer has context-switched away from it, the branch has diverged from main, and when review finally happens, the feedback requires more effort to incorporate than it would have 24 hours ago. Establishing and enforcing a PR review turnaround SLA, 24 hours for initial review is a reasonable starting point, and a management decision about developer experience. 3. Senior Engineers Own the Cognitive Load Problem in the Codebase The cognitive load dimension of developer experience lives primarily in the codebase itself, its structure, its documentation, its consistency, and how navigable it is for someone who did not write it. Senior engineers, as the primary authors and reviewers of the most critical code, are the primary owners of this dimension. A senior engineer who writes a 500-line function with no comments, inconsistent naming, and dependencies that are not obvious from the function signature has made a developer experience decision. The developer who has to debug that function at 11 PM during an incident will feel that decision acutely. The specific accountability senior engineers should own: Code reviewability. Is the code being merged clear enough that someone unfamiliar with this part of the system can understand what it does and why it makes the choices it makes? This is a higher standard than "does it work", it is "would someone else maintain this safely?" Senior engineers set this standard through the code they write and the feedback they give in reviews. Documentation as a deliverable. That gap is not a coding problem. It is a systems problem, slow CI, flaky tests, missing docs, review bottlenecks, and interruptions that stretch a one-day change into a four-week saga. Missing documentation is not incidental to the code, it is a missing deliverable, the same as a missing test. Senior engineers who treat documentation as optional or as someone else's job are making a choice that adds cognitive load to every future developer who touches their code. Architecture decision records. Why was this architectural decision made? What alternatives were considered? What tradeoffs were accepted? This context evaporates within months of the decision being made, unless someone writes it down. Senior engineers are the people who have this context and therefore the only people who can capture it. Complexity ownership. When a codebase is genuinely complex, and some complexity is unavoidable, senior engineers should be the ones who understand it most deeply and who take responsibility for making that complexity as navigable as possible for everyone else. This means investing time in understanding the system as a whole, not just the components they personally built. 4. Product Management Owns the Prioritisation Problem Developer experience improvements are investment decisions that compete with feature delivery for engineering time. In most organisations, that competition is structurally biased against developer experience, because feature requests come from customers with business context and urgency attached, while "make CI faster" comes from engineers with technical context that does not translate easily into business priority language. Product management is the organisational function that resolves prioritisation conflicts. When developer experience improvements consistently lose in prioritisation, it is partly because product managers do not have a framework for evaluating them against feature work. The specific accountability product managers should own: Developer experience in the sprint. A team that allocates zero sprint capacity to developer experience improvements will see those improvements never happen, regardless of how many times engineering leadership says they are a priority. Making space in the backlog, a real, recurring allocation, not "we'll get to it eventually", requires product management buy-in. Business translation for DevEx work. Faster CI pipelines are hard to prioritise against a customer-requested feature. "Reducing our average time-to-merge from 4 days to 1 day, which we estimate will increase our feature delivery rate by 25%" is easier to prioritise. Product managers who work with engineering to translate developer experience improvements into business impact language change the prioritisation dynamic. Sustainability over velocity. Quality outcomes degrade as engineers stop pushing back on poor decisions or skip thorough reviews to keep up. Innovation suffers too. The product manager who consistently pushes for faster delivery without accounting for the maintenance and quality debt that creates is making a developer experience decision, one that trades short-term velocity for long-term fragility. Sustainable pace is a product decision as much as a technical one. 5. The C-Suite Owns the Structural Conditions 58% of software engineering leaders report that developer experience is very or extremely critical to the C-suite. The C-suite knows it matters. The question is whether that knowledge translates into the structural conditions that make improvement possible. Dedicated investment. Does a platform team exist? If not, if developer experience improvements must compete for time against feature delivery in the same team's backlog, they will consistently lose to the more immediate, more visible demand. Creating a dedicated function whose explicit job is developer experience is an executive decision. Measurement. Each one-point gain in DXI score correlates to 13 minutes per week of developer time saved. Developer experience is measurable. Organisations that measure it, through the Developer Experience Index, DORA metrics, regular developer surveys, and onboarding time tracking, can show progress and justify investment. Organisations that do not measure it cannot defend investment in it. Creating the measurement framework is an executive decision. Culture of improvement. Engineers who identify developer experience problems and invest time in fixing them rather than living with them need to be recognised and rewarded for doing so, not quietly penalised for spending time on "non-feature work." The culture that makes this behaviour safe and valued is set at the top. The Measurement That Makes It Real Without measurement, developer experience discussions stay in the realm of qualitative frustration, developers feel like things are slow and broken, but "feels slow" does not compete with a customer feature request backed by revenue data. Start with DX Core 4 to balance speed, effectiveness, quality, and impact. Measure flow efficiency to understand where time is wasted. Track AI impact separately using the DX AI Framework. Pair quantitative and qualitative data, metrics plus surveys. Monitor code churn closely as AI adoption increases. Here are the five metrics worth tracking from day one:Time to first commit: how long does onboarding take before a new developer merges their first meaningful change? This single metric encodes the health of documentation, local environment setup, access provisioning, and onboarding process. A good target: under 30 minutes for a senior hire, under two days for a junior hire. Median CI pipeline duration: how long does the average CI run take? Track this over time. Watch what happens to it as the team grows and the codebase expands. A pipeline that grows from 8 minutes to 45 minutes over two years without anyone noticing is a failure of measurement, not engineering. PR cycle time: the time from a pull request being opened to being merged. This encodes review culture, PR size discipline, and the health of the team's collaboration patterns. A healthy target for most teams: under 24 hours for median cycle time. Developer satisfaction score: a simple quarterly survey: on a scale of 1-10, how productive do you feel in your current environment? What is the single biggest thing slowing you down? This qualitative signal catches problems that metrics miss and points directly to where to look next. Deploy frequency : from DORA: how often does the team successfully deploy to production? Low deploy frequency is almost always a symptom of developer experience problems, heavyweight processes, fear of deployments, or slow feedback loops that make frequent deployment feel risky. Translate DevEx and productivity data into business outcomes that matter to your leadership team: ROI, efficiency, and cost savings. While developer experience focuses on how developers interact with and navigate their work environment, organisations also need to track business outcomes and system performance. The AI Acceleration That Makes This Urgent Developer experience has always mattered. In 2026, it matters more than it ever has, because AI has changed the calculation in a specific way that most organisations have not yet fully understood. DevEx is the discipline of finding and removing the friction between an idea and shipped, running software, measured across feedback loops, cognitive load, and flow state. In the AI-agent era, the stakes only rise, because the same friction that slows humans also slows AI agents. Clean, fast, well-documented systems make both humans and agents dramatically more effective. When AI coding assistants generate code faster than humans can review it, the bottleneck shifts. The constraint moves from "how fast can developers write code" to "how fast can the organisation integrate, validate, and ship code." A slow CI pipeline that was annoying when a developer submitted one or two PRs per day becomes genuinely production-critical when that developer is using AI assistance to submit five or ten PRs per day. AI has lowered the barrier to producing code. It has not lowered the barrier to producing good systems. Teams that design for clarity, control, security, and cognitive sustainability will outperform teams that chase tools without structure. The organisations that invest in developer experience now, fast pipelines, low cognitive load codebases, protected flow state, clear ownership, are not just making their developers' lives better. They are building the infrastructure that allows them to leverage AI acceleration effectively. The organisations that do not are building the bottleneck that will choke AI-assisted development velocity before it can deliver its promised productivity gains. What Fixing It Actually Looks Like The Six Practical Changes Theory is useful. Here is what the fix actually looks like in a real organisation: Change 1: Name an owner. Pick one person who is responsible for the developer experience scorecard. Not a committee. Not "the platform team in general." One person whose name is attached to the metric and who has authority and budget to act on it. This is the single highest-leverage change, everything else depends on it. Change 2: Measure three things, starting this week. Onboarding time. CI pipeline duration. PR cycle time. If you do not have these numbers, get them. If you have them but they are not reviewed regularly by engineering leadership, start reviewing them. You cannot improve what you do not measure. Change 3: Add developer experience to the sprint permanently. A recurring sprint allocation of 20% is a reasonable starting point, for developer experience improvements. Not "we'll get to it," not "next quarter," not a separate track that never gets prioritised. In the sprint, every sprint, alongside feature work. Change 4: Audit the meeting calendar. Identify every recurring meeting on the engineering team's calendar. For each one: does it need to exist? Does it need to be as long? Does it need all of the people currently invited? Protect at least one four-hour block per day per developer from meetings. Make this a team norm, not an individual's fight. Change 5: Treat onboarding documentation as a product. Assign someone ownership of the internal developer getting-started guide. Run a new hire through it every quarter and watch where they get stuck. Update it immediately when it is wrong. The test: can a senior engineer join your team and be productive within 30 minutes using only the documentation? Change 6: Create a developer experience feedback loop. A quarterly survey, five questions, five minutes, reviewed by engineering leadership, with visible action taken on the results. The survey is not the point. The visible action is. Engineers who report problems and see nothing change stop reporting problems. Engineers who report problems and see them fixed start seeing themselves as stakeholders in the system rather than victims of it. Who Is Actually Responsible To answer the question in the title directly: Everyone named in this article is responsible for part of it. The platform team for the infrastructure of development. Engineering management for the meeting culture and interruption problem. Senior engineers for the cognitive load in the codebase. Product management for the prioritisation problem. The C-suite for the structural conditions that make improvement possible or impossible. But diffuse responsibility is effectively no responsibility. The single specific change that has the highest leverage is not technical, it is an organisational one: naming a person who owns the developer experience metric, has authority to act on it, and is evaluated on it. Most companies focus on measuring developer output, but the real blockers, inefficient processes, unclear documentation, and unnecessary complexity, often go untracked. Track them. Own them. Fix them. The lost day per week is not inevitable. It is a choice, made by default rather than deliberately, and it can be unmade the same way. References [1] DX Research / ACM Queue. Developer Experience (DevEx): Dimensions and Outcomes. 2023. https://getdx.com/research/developer-experience/ [2] DX Platform. State of Developer Experience Report 2024 — 2,100 developers, 1 day lost per week. https://getdx.com/report/state-of-developer-experience-report/ [3] Taskade / Dawid Bednarski. What Is Developer Experience (DevEx)? Complete 2026 Guide. June 2026. https://www.taskade.com/blog/developer-experience-devex [4] Austin Wdigital / DEV Community. Developer Experience (DevEx) in 2026 — The Real Competitive Advantage. February 2026. https://dev.to/austinwdigital/developer-experience-devex-in-2026-the-real-competitive-advantage-2996 [5] Kodus. Developer Experience (DX): What It Is and How to Measure It in 2026. July 2026. https://kodus.io/en/the-complete-guide-to-developer-experience-devex/ [6] DevOps Digest / Gartner. 58% of Engineering Leaders Say DevEx Is Extremely Critical to C-Suite. 2025. https://www.devopsdigest.com/hot-topic/devex [7] DevX. The Developer Burnout Crisis: What 2026 Data Reveals About Mental Health in Tech. June 2026. https://www.devx.com/uncategorized/developer-burnout-crisis-mental-health-tech-2026/ [8] Zylos Research. Developer Productivity Metrics 2026: From DORA to DevEx and Beyond. February 2026. https://zylos.ai/research/2026-02-07-developer-productivity-metrics/ [9] GetDX. Developer Experience Index (DXI) — 13 minutes per week saved per DXI point gain. https://getdx.com/blog/developer-experience/ [10] DORA. Accelerate State of DevOps Report 2024. https://dora.dev/research/2024/dora-report/ Emmanuela Opurum is a Solutions Architect and Cloud Engineer building AI-native cloud tooling and contributing to open-source projects in the CNCF ecosystem. She writes about platform engineering, cloud architecture, and developer experience.GitHub: Cloud-Architect-Emma