4. Developer experience

Effective software organizations give engineers the support and tools they need to do their best work.

In the previous chapter, we discussed how processes impact developer productivity and how we might measure it. Here, we look at the other side of software development: developer experience. We’ll revisit the table stakes we discussed in previous chapters and explore the aspects of experience that we can measure and set goals around.

What is developer experience?

Developer productivity, as we discussed in the previous chapter, is primarily about the mechanics of delivery: how quickly and reliably your teams move work from idea to production. Developer experience is about something different: how it feels to build software in your organization, and how those feelings influence what your teams can accomplish.

Making this distinction is important because the mechanics can look fine while the experience could be terrible. A team might have reasonable cycle times and deployment frequency while its engineers are exhausted by constant interruptions, frustrated by brittle tooling, and demoralized by the sense that nobody in leadership understands what they’re dealing with. Those feelings don’t only affect retention, either. They erode the quality of decision-making, the willingness to take on hard problems, and the kind of informal collaboration that no process can mandate.

The most useful way to think about it is this: your engineering colleagues are your users, and your product is effectiveness. Just as you’d study how customers experience your company’s product — where they get stuck, what workarounds they’ve invented, what makes them want to keep using it or abandon it — you can study how engineers experience the act of building software in your organization. The same instincts apply: talk to them, observe them, measure what you can, and invest in the things that make the biggest impact.

Classic developer experience challenges

Assessing your developer experience requires looking beyond what the tooling and process metrics tell you. These are common culprits:

• Tooling friction. The tools engineers interact with every day (build systems, CI pipelines, test frameworks, deployment infrastructure, internal platforms, AI tools) are the ecosystem where developer experience happens. When these tools are slow, unreliable, poorly documented, or require workarounds that everyone just knows about, engineers spend mental energy fighting their environment rather than solving the problems they were hired to solve. Tooling friction is especially insidious because it accumulates silently; no single slow build is a crisis, but hundreds of them reshape how people feel about their jobs.
• Unclear ownership and decision-making. When engineers can’t figure out who owns a system, who can approve a change, or how a decision gets made, work stalls in ways that don’t show up in any tracker. People send messages into the void, wait for responses that never come, or escalate things that shouldn’t need escalating. The friction isn’t technical, it’s organizational, but its effects on an engineer’s daily experience are as real as a flaky test suite.
• Inadequate onboarding. How long it takes a new hire to become productive is one of the clearest signals of developer experience health. If engineers are still struggling to set up their local environment after a week, or if the only way to learn how things work is to find the right person to ask, you have an onboarding problem that’s also a knowledge-sharing problem. Poor onboarding doesn’t just affect new hires; it taxes the veterans who have to fill in the gaps.
• Unbalanced support load. In many organizations, a small number of engineers absorb a disproportionate share of support work — answering questions, triaging customer issues, responding to incidents — while the rest of the team works uninterrupted. This often goes untracked and unrecognized, which makes it doubly frustrating for the people carrying the load. Over time, it drives attrition among exactly the experienced engineers you can least afford to lose.
• Lack of voice. Engineers who feel that their input on technical decisions, tooling choices, or process changes doesn’t matter — or that it’s solicited but never acted on — disengage. This is related to the empowered teams table stake from Chapter 1, but it also shows up in smaller ways: teams that aren’t consulted when upstream changes affect their work, or engineers whose feedback on internal tools seems to disappear without acknowledgment.
• Invisible progress. Engineers get satisfaction from seeing the impact of their work. When organizational structure, release processes, or product decisions make it hard to connect what an engineer built to the value it created for users, that sense of impact erodes. This is especially common in large organizations where individual contributions feel like drops in an ocean, and in organizations where work sits in long review or approval queues before reaching anyone who might use it.

The common thread across all of these is that they’re rarely visible in traditional engineering metrics. Cycle time won’t tell you that your best engineer is burning out from support load. Deployment frequency won’t reveal that new hires take three months to feel productive. These problems live in the gaps between what’s measurable and what’s experienced, which is exactly why developer experience needs dedicated attention.

How AI is reshaping developer experience

The challenges in the previous section have been around for decades. What’s newer, and what most organizations are still figuring out, is the set of pressures that generative AI tools have added on top of them. These pressures affect the experience of building software in ways that most organizational playbooks haven’t captured yet.

The most visible change is in how work flows through the team. When individual contributors can generate code faster than before, the bottleneck moves downstream. Senior engineers find themselves reviewing significantly more code than they used to, often with the unspoken expectation that review quality and turnaround time should stay the same or improve.

Reviewing AI-assisted code is also different from reviewing code a colleague wrote from scratch: the patterns are sometimes subtly off, the rationale isn’t always embedded in the change, and plausible-looking code can hide issues that only surface under careful inspection. This is real cognitive work, and it’s accumulating on the people who are already most in demand for everything else.

At the same time, engineers are increasingly expected to have multiple things in flight at once. The logic goes something like this: if AI can keep two streams of work moving, why not three or four?

Fragmenting that attention across parallel tracks degrades the quality of each track and leaves engineers feeling scattered rather than productive. This is the team-level table stake about limiting work in progress, showing up in a new form.

Upstream and downstream processes often haven’t caught up to any of this. In most organizations, product and design workflows still assume the old cadence of engineering delivery, which means engineers can find themselves with AI-accelerated capacity but no corresponding acceleration in requirements, specs, or decisions from the people they depend on. On the other side, QA, release processes, and incident response may not have adapted to a world where more code is shipping faster from more concurrent streams of work. The result is a team that can generate output faster than the surrounding system can absorb it, which isn’t actually an improvement in throughput — it’s just a new bottleneck. Goldratt’s Theory of Constraints lives to fight another day.

The picture is particularly hard for engineers earlier in their careers. Many of the tasks that used to make up a junior engineer’s first year — small bug fixes, straightforward feature work, the kind of well-scoped problems that build familiarity with a codebase — are increasingly the tasks that AI tooling handles easily. Hiring for these roles has contracted sharply from where it was a few years ago, and engineers who do land them often feel uncertain about what their growth path looks like. This isn’t a problem any individual leader can fix, but it is part of the texture of the experience for early-career engineers on your team, and worth acknowledging rather than glossing over.

Running underneath all this is another concern: the question of whether any of it is sustainable for the humans doing the work. Engineers at every level are navigating uncertainty about what their role will look like in two years, five years, ten. Some find the shift energizing; others find it destabilizing. Leaders who dismiss the concern — or, worse, cheerfully remind their teams that everyone’s job is on the line — aren’t creating the conditions for people to do their best work.

When leaders develop unrealistic expectations from their own experiments with AI tools, it can add another layer of pressure to engineers. A semi- or non-technical leader who spends a Saturday using an AI coding assistant to build a working prototype, then arrives Monday asking why the production version can’t be ready by Tuesday, has misunderstood what they did. Prototyping something is not the same as shipping it: the prototype doesn’t have to scale, handle edge cases, integrate with existing systems, meet compliance requirements, or be maintainable by someone else six months from now. Expectations set by leaders who haven’t done production engineering work recently — or at all — put enormous pressure on teams and signal that the difficulty of their actual job isn’t understood.

Taken together, these shifts add up to a developer experience that looks materially different from what it was in 2019. The frustrations aren’t new in kind — review load, work-in-progress overload, misaligned expectations, uncertain growth paths — but their intensity and the speed at which they’ve arrived are. None of the tools in this chapter lose their relevance; if anything, talking to engineers, collecting data, and closing feedback loops matter more now, not less. But leaders who haven’t explicitly acknowledged the AI dimension of developer experience are probably operating with an outdated model of what their engineers are actually dealing with.

Understanding your engineers’ experience

The challenges listed above are real, but they’re also generic — every organization experiences some combination of them. What matters is understanding which ones are actually affecting your engineers, how severely, and where the highest-leverage improvements lie. That requires treating the question with the same rigor you’d bring to understanding your customers: gather qualitative signals to learn what’s happening and why, then collect quantitative data to understand the scale and prioritize your response. The three approaches that follow — direct conversations, empirical tooling data, and structured surveys — work best in combination. Each one compensates for the blind spots of the others.

Talk to your users

Have as many in-person conversations with small groups of engineers — including both veterans and new hires, product and platform teams — as you can manage. You could do this via a survey, which we’ll discuss shortly, but try to have some of these conversations in person with a few teams; that environment tends to generate usefully divergent ideas.

You can use prompts like these: What could we improve about your tools? What’s an annoyance for engineers today that could become a real risk in the future? What would help the company learn more quickly through rapid feedback?

If you’ve established a high-trust environment, go a step further and shadow engineers while they do their job. You’ll be amazed at the workarounds you never knew people were employing and the things you didn’t realize people were putting up with.

Many of the ideas you’ll come across will have technical solutions, but don’t tune out people, process, and political challenges that merit different approaches. Finding ways to make engineers more effective without consuming engineering time could be a huge win.

Collect empirical data

Your users will suggest plenty of opportunities for improvement — so many, in fact, that you’ll have difficulty choosing among them. This is when it’s essential to have quantitative data to help guide your prioritization and validate the qualitative stories you hear.

It’s relatively easy to build observability into your internal tooling. If you don’t already have a system to record the behavior of internal tools, now might be the time to consider buying or building one. An internal tool should be able to record every invocation and its outcome, along with relevant metadata. Most importantly, it should record how long a developer has waited to get output from the tool.

If you make it easy to capture user experience data from internal tools — say, by providing a standard API that other engineers can use to collect signals that can be stored usefully alongside other tooling data — internal tool authors will capture some metrics.

Run developer experience surveys

Surveys give you something that conversations and tool metrics can’t: a structured, comparable picture of how people across your organization feel about their work. They provide two kinds of value: validation (whether your strategy, tools, and policies are actually working) and discovery (the needs and challenges you might not see otherwise).

Types of surveys

Different surveys serve different purposes.

• Overview surveys are comprehensive questionnaires covering team dynamics, tooling, and culture, typically run quarterly — these are the best place to start.
• Drill-down surveys explore a specific problem area in depth when your overview survey flags something worth investigating.
• Pulse surveys are short, frequent check-ins that track sentiment over time.
• Paper cut surveys make it easy for engineers to report frustrations as they encounter them, rather than waiting for the next quarterly survey.
• Trigger-based surveys are launched at specific events like the first use of an internal tool or completion of onboarding, capturing fresh impressions while the experience is vivid.

Designing good survey questions

The difference between a useful survey question and a noisy one usually comes down to specificity and focus. “In the past quarter, how often did my team depend on other teams to complete its work?” is far more answerable than “How efficient are our team processes?” — the first asks about something observable, while the second invites a dozen different interpretations.

Questions that try to cover too much ground at once create similar problems; if you see “and” or “or” in a question, that’s usually a sign it should be two questions. More generally, questions that focus on observable characteristics rather than personal judgment produce more consistent, actionable data.

The Likert scale (agree/disagree on a five-to-seven-point range) is the most reliable and well-researched approach for attitudinal surveys, with the added benefit of transforming subjective responses into data you can trend over time. If most responses cluster at the top or bottom of your scale, your question phrasing is pushing people toward extremes, and you’re losing resolution.

Getting honest responses

Low response rates and suspiciously positive results are symptoms of trust problems. Don’t reward or punish based on results. Don’t stack-rank teams or evaluate manager performance using survey scores. Be explicit about privacy — explain how responses will be used and reported, and if you say responses are anonymous, make it technically impossible to link a response back to a person. Most importantly, demonstrate that survey results lead to visible improvements. If people don’t see meaningful change between surveys, they won’t bother responding to the next one.

Acting on the results

Survey answers by themselves don’t tell you much. Is an average rating of 3.8 out of 5 for “Our automated tests catch issues reliably” good? You need comparison — across your organization, over time, or against external benchmarks. Open-ended comments provide crucial context for the numbers, because the people experiencing problems have usually thought hard about them.

Some problems are best solved locally, while others require organizational action. Empower teams to own their own results — dedicating a retrospective to reviewing survey data and creating an action plan is one effective approach. Problems that affect multiple teams or require structural changes need leadership attention: unreliable CI infrastructure, unclear strategy, inadequate tooling budgets, and misaligned incentives can’t be solved by individual teams. Ideally, you’ll share results openly, since transparency builds trust and helps teams learn from each other.

Even well-designed surveys have their problems. Recency bias means last week’s incident looms larger than persistent long-standing problems. Sampling bias creeps in when certain groups respond at higher rates than others. And when survey scores become objectives, people optimize for scores rather than actual improvement. Surveys are one tool among many; they’re most powerful when combined with conversations, retrospectives, and system metrics.

Measuring developer experience

Beyond what you learn from conversations and surveys, there are a few dimensions of experience worth tracking over time.

• Sources of frustration. Engineers get frustrated when their flow is interrupted — sometimes by a tool, sometimes by a process, and sometimes by another person. These frustrations add up, affecting both satisfaction and delivery. Consider making it easy and obvious to report frustrations to a ticket queue that you check regularly.
• Employee satisfaction and engagement. Regular employee surveys can capture this data. Exit interviews and employee reviews on job websites can offer additional perspectives.
• Employee turnover and regretted attrition. A high turnover rate, especially among high-performing or recently hired individuals, is a sign that something deeper is wrong. An increase in regretted attrition — the loss of employees you didn’t want to lose — is a warning sign that deserves investigation, not just a line in a quarterly report.
• Leadership trust and communication effectiveness. How well leadership communicates directly affects employee satisfaction. Regular surveys can gauge employees’ trust in leadership and the effectiveness of organization-wide communications.

The downside of these metrics is that the data arrives long after the damage is done, and tends to be noisy and nuanced. This is why you need the faster-feedback mechanisms discussed above — conversations, tool observability, and targeted surveys — to complement these lagging indicators.

Improving developer experience

Understanding your engineers’ experience is necessary, but not sufficient. You have to act on what you learn — and be seen to act on it. That requires a framework to decide what to do with what you’ve heard. The improvements that matter most vary by organization, but they tend to fall into a few broad categories.

Review the table stakes

We discussed organization-wide table stakes in Chapter 1 (empowered teams, rapid feedback, and outcomes over outputs), and team-specific table stakes in Chapter 3 (limited queue depth, small batch sizes, limited work in progress).

All of these come into play in developer experience. The absence of any one of them drags down a software engineer’s satisfaction and engagement. And as a leader, you need to honestly evaluate where your team and organization are on this list. If any of these ways of working are missing or built on shaky ground, you and your leadership need to recognize that there’s a ceiling on the improvements you can make until that changes.

Invest in your internal platform

When tooling frustrations surface repeatedly across teams — slow builds, unreliable test environments, painful deployment processes, confusing internal APIs — it’s a signal that your internal developer platform needs investment. This is the most direct expression of the “your engineers are your users” framing: you’re building a product for them, and that product needs the same attention to usability, reliability, and iteration that you’d give a customer-facing one.

For smaller organizations, this might mean dedicating a portion of an existing team’s time to improving shared infrastructure. For larger organizations, it often means establishing a platform team whose explicit charter is to make other engineers more effective. Prioritize the work like product work: based on the severity and breadth of the problems it solves, informed by the data you’ve collected.

Make knowledge sharing structural

Many developer experience problems — slow onboarding, reliance on specific individuals for tribal knowledge, excessive internal support load — are symptoms of the same underlying issue: knowledge lives in people’s heads rather than in systems. Fixing this requires more than writing documentation, though documentation matters. It requires making knowledge-sharing a core part of how teams work.

Every gap, every assumption, every undocumented workaround is exposed within the first few weeks. If new engineers can’t set up their environment, find the relevant documentation, and make a meaningful contribution within a reasonable timeframe, that’s an organizational problem. Invest in onboarding paths that are maintained as living artifacts, not one-time documents that decay the moment they’re written.

Beyond onboarding, look for patterns in your internal support data. If the same questions come up repeatedly, the answer should be findable without asking a person. Self-serve solutions — clear happy paths for common tasks, searchable internal documentation, well-designed error messages that point to next steps — reduce interruptions for the experts and build self-sufficiency across the team. AI-powered search tools can help here, but only if the underlying documentation is accurate and current; otherwise, you risk scaling misinformation.

Knowledge sharing also occurs through how teams collaborate on code. Practices like rotating code reviewers, pairing on unfamiliar parts of the codebase, and writing architectural decision records all distribute understanding more broadly. The goal is to reduce the organizational risk that comes from concentrating critical knowledge in too few people.

Close your feedback loops

The single most important thing you can do for developer experience might also be the simplest: when engineers tell you something is broken, show them what you’re doing about it. This sounds obvious, but most organizations are surprisingly bad at it. Engineers fill out surveys, raise concerns in retrospectives, file tickets against internal tools, and mention problems in one-on-ones or town halls — and then nothing visibly happens.

The result is as you would expect. People stop providing feedback — not because the problems went away, but because providing feedback started to feel pointless. Once that happens, you’ve lost your best signal about what needs improving, and you’ve confirmed the suspicion that leadership doesn’t care about the day-to-day experience of building software.

Closing the loop doesn’t require solving every problem immediately. It requires three things: acknowledging what you heard, being transparent about what you’re choosing to work on and why, and showing progress on the things you committed to. A shared document or dashboard that tracks identified problems, planned actions, owners, and status is sufficient. The mechanism matters less than the visibility.

This applies at every level. At the team level, it means following up on retrospective action items rather than letting them drop off the radar. At the organizational level, it means publishing what you learned from surveys and what you’re doing about it. When improvement efforts are visible, people will keep participating.

Manage interruptions as a systemic problem

Uninterrupted time is the building block of flow, and in most organizations, there’s no shortage of things competing for it. The useful distinction isn’t between “important” and “unimportant” interruptions — it’s between interruptions that warrant the break in focus they cause and those that don’t. A production outage demands immediate attention. A question with a well-documented answer does not, even if it feels urgent to the person asking.

Meetings are the most common offender, and the cost of each one extends well beyond its duration — a scattered handful of meetings can fragment an entire day into blocks too short for sustained concentration. Require agendas, default to 30 minutes, share outcomes so people can stay informed without attending, and audit recurring meetings periodically. For ICs, aim to protect at least four hours of focused work on four days each week. Where decisions need to happen asynchronously, structured templates for design reviews, API proposals, and similar artifacts give people a clear format for input without requiring everyone to be in the same room, virtual or otherwise, at the same time.

Support load — both internal and external — is another category that tends to be disorganized, ad hoc, and invisible to leadership. The most effective response involves eliminating categories of requests entirely. The knowledge-sharing investments discussed above — self-serve documentation, clear happy paths, tooling that doesn’t require tribal knowledge to operate — are the primary lever here. If your support volume is high, that’s a signal to invest there rather than to staff up a help desk.

Production incidents can’t be declined, but how you handle them determines whether they disrupt one person for an hour or the entire team for a day. A team drowning in incidents is usually experiencing the downstream effects of problems discussed throughout this book: insufficient time for technical work, inadequate testing, pressure to ship without addressing known risks. Track your incidents, but don’t stop at the incident itself; trace backward to what conditions allowed it to happen. And be cautious about incident metrics — teams measured on incident counts learn to reclassify, teams measured on resolution time learn to close tickets prematurely, and teams that feel blamed learn to hide problems entirely.

Team-level vs. organizational improvements

Just as with productivity, some developer experience improvements are within a team’s own control, while others require organizational action. Knowing which is which is important, because misattributing a problem leads to frustration in both directions: teams feel powerless when told to fix things they can’t control, and leadership feels ignored when teams wait for someone else to solve problems they could address themselves.

Teams can typically improve their own meeting discipline, code review turnaround times, internal documentation practices, onboarding support for new members, and working agreements about focus time and interruptions. These are improvements that compound over time, and they don’t require permission or budget from anyone. Encourage teams to own these and give them space to experiment.

Organization-level improvements involve shared infrastructure, cross-cutting policy, or resource allocation: CI/CD reliability, internal tool investment, on-call load distribution, meeting culture norms that apply beyond a single team, and the decision to fund platform work at all. These require leadership attention, prioritization, and sometimes difficult tradeoffs with other organizational goals. They’re also the improvements with the most leverage, because they affect every team rather than just one.

The most common failure mode is treating everything as an organizational problem, which creates dependency on central teams and learned helplessness at the team level. The second most common is treating everything as a team problem, which leaves systemic issues unaddressed and makes teams feel like leadership has abdicated responsibility. Getting the balance right — and being explicit about which category a given problem falls into — is one of the more important things a leader can do for developer experience.

Setting goals around developer experience

Setting goals for developer experience is inherently harder than setting productivity goals, because the signals are fuzzier and the causal chains are longer. But that doesn’t mean you shouldn’t try.

Start with what you’ve learned from conversations, surveys, and empirical data. Identify the highest-impact frustrations — the things that affect the most people or that disproportionately affect critical workflows — and set concrete improvement targets around them. If your survey data shows that engineers across multiple teams rate CI reliability poorly and your tool metrics confirm a 20% flaky test rate, improving that reliability is a clear and measurable goal.

For interruption-related improvements, track the metrics that correspond to the specific problem. If meetings are the primary concern, measure hours of uninterrupted focus time per engineer per week. If internal support load is the issue, track the volume and resolution time of support requests. If incidents are dominating, track incident frequency and the total engineering hours consumed per incident (including post-incident work).

As with productivity goals, be careful about setting targets before you understand the problem well enough to know what “good” looks like. Watch for perverse incentives: a goal to reduce incident count can lead to reclassification rather than improvement; a goal to improve survey scores can lead to gaming rather than genuine change. Set goals around the outcomes you actually want — engineers having enough focus time, being able to find answers without interrupting colleagues, trusting that their feedback leads to action — and measure the proxies thoughtfully.

What’s next?

In this chapter, we looked at developer experience and the things that influence it, including how to listen to your engineers through conversations and surveys, how to measure the dimensions of developer experience, and how to think about interruptions as a systemic challenge rather than an individual one. In the next chapter, we’ll look at how to put the lessons of this and previous chapters into practice.

Further reading

• Drive: The Surprising Truth About What Motivates Us, by Daniel H. Pink. Explores the core elements of motivation and how they can be applied in a work environment, including for software developers.
• Flow: The Psychology of Optimal Experience, by Mihaly Csikszentmihalyi. Discusses in detail how uninterrupted focus allows people to reach a state of heightened efficiency and satisfaction in their work.
• Peopleware: Productive Projects and Teams, by Tom DeMarco and Timothy Lister. A classic in the software development field, focusing on the human side of software development and team dynamics.
• Deep Work: Rules for Focused Success in a Distracted World, by Cal Newport. A guide on how to achieve focused and productive work, particularly relevant for developers dealing with complex tasks.
• Agile Retrospectives: Making Good Teams Great, by Esther Derby and Diana Larsen. Provides tools and techniques for effective agile retrospectives, emphasizing continuous improvement and problem-solving.
• Site Reliability Engineering: How Google Runs Production Systems, by Niall Richard Murphy, Betsy Beyer, Chris Jones, and Jennifer Petoff. An in-depth look at Google’s approach to incident management and production systems.
• The Field Guide to Understanding “Human Error”, by Sidney Dekker. Highly regarded in the Learning From Incidents community, offering insights into how to understand and learn from human errors in complex systems.
• 35 Questions to Ask in Your Developer Experience Surveys, by Miikka Holkeri. Details the ten categories of developer experience survey questions that Swarmia provides out of the box, and the specific questions inside them.