Three Forces That Quietly Shape How Developers Work

Max Kanat-Alexander breaks down why cycle time, focus, and cognitive load determine whether your engineering team thrives or burns out

Recently I watched Max Kanat-Alexander’s talk on developer experience, and it resonated deeply with me.

Max has spent his career thinking about what actually makes developers productive, from leading the Bugzilla project to working on code health at Google, developer productivity at LinkedIn, and now leading developer experience at Capital One. His perspective is refreshingly direct: when you strip away all the complexity, there are really only three things you need to optimize for in developer experience. Not ten. Not twenty. Just Three.

Cycle time, focus, and cognitive load. That’s it. Everything else either falls under these three categories or isn’t actually about what developers directly experience.

But here’s where it gets interesting. These aren’t independent metrics you optimize separately. They’re deeply interconnected forces that, when misunderstood, create the exact opposite of what you’re trying to achieve. And once you understand them, you realize the hardest problems in developer experience aren’t technical at all. They’re human.

Cycle time: the fractal nature of developer work

The first principle is cycle time, the time between when a developer has an intention and when they experience the result of that intention. This sounds simple until you realize that developer work is fractal. Every large cycle is composed of smaller cycles, and those smaller cycles break down into even smaller ones.

At the smallest scale, you have something like: I intend to write one line of code, and now I’ve written it. At the largest scale: I’ve observed a problem in the world, and now there’s a successful product solving it. Between those extremes are hundreds of cycles: gathering requirements, writing a PR, getting code review, deploying to staging, fixing that one weird test failure, deploying to production.

When engineering leaders want to speed things up, the instinct is to focus on the big cycles. You want to take that three-month feature delivery down to two and a half months. So you go to the team and say the magic words: “Just go faster.”

Obviously, this fixes nothing. What you actually get is a decrease in quality in exchange for an increase in velocity. And most of the time, you don’t even get the velocity increase because the quality decrease itself slows down the development team so much that it ends up taking the same amount of time it would have taken if they hadn’t cut any corners.

The insight that matters here is that whenever you investigate why a larger cycle takes time, it’s always because something is wrong with one of the smaller cycles. Every single time. It’s never some abstract problem with “how we’ve structured the entire large cycle”. It’s concrete and specific: our code review process is slow because reviewers treat it as a lower priority than writing new code. Or PRs are too large. Or developers spend 30 minutes trying to understand a cryptic test failure instead of getting immediate, actionable feedback about what broke and why.

This is where most organizations go wrong. They measure the big cycles—time to deploy, time to ship a feature—and then wonder why their expensive new CI/CD system didn’t move the needle. They optimized the wrong cycle.

The observe-decide-act loop that determines everything

Every cycle, whether large or small, follows the same pattern: observe, decide, and act. You receive data, make a decision based on that data, and then act on that decision. In the large sense, you observe a problem in the world, decide to make a solution, and deliver that solution. In the smallest sense, you observe the last line of code you wrote, decide to write the next line, and write it.

Here’s what most people get wrong: they worry about the “act” part. They obsess over how long developers take to actually type code into the IDE. That’s almost never the bottleneck.

The slowest part of this cycle is almost always observe. How long does it take to gather the information needed to make the right decision?

Think about the difference between these two scenarios. In the first, a test fails with a message like “AssertionError: expected true but got false” and a stack trace pointing to some deep internal framework code. You spend 20 to 30 minutes trying to figure out what this actually means, stepping through code, adding print statements, reconstructing what must have happened. In the second scenario, the test failure tells you exactly which line of your code caused the problem, shows you the expected versus actual values in a readable format, and even suggests what might have gone wrong based on common patterns. The second scenario takes almost no time. You see it, you understand it, you act on it.

This observation bottleneck shows up everywhere. Unclear requirements mean developers can’t make decisions confidently, so they either guess (and often guess wrong) or constantly ask for clarification. Bad error messages from tools cause long observation times. Incomplete documentation means every integration takes three times longer than it should because developers have to reverse-engineer the intended behavior.

But you can also cause observation problems by flooding developers with too much information. If your monitoring dashboard shows 200 metrics and none of them are clearly labeled as “this is the problem”, you’ve made it harder to observe, not easier. The goal is to provide developers the information they need at the moment they need it and no other information.

Here’s a safe rule: ask yourself how you could make it so that developers never have to think or guess about what their next step is. Not because they’re incapable of thinking, but because you’ve eliminated the friction that comes from uncertainty and context gathering.

Focus: the flow state that actually produces value

The second principle is focus. Developers need long, uninterrupted blocks of time to do their best work. This isn’t controversial, and yet we’ve somehow built workplaces that make sustained focus nearly impossible.

Max’s framing is direct: we’re trying to compress large amounts of thinking down into tiny blocks of time. It doesn’t work. Real progress happens when developers can maintain flow state, that mental condition where they’re holding multiple mental models in their head simultaneously, seeing connections between different parts of the system, and making meaningful progress toward solving a hard problem.

I’ve written before about the problem of interruptions, and the research here is clear. When you interrupt someone doing deep work, they don’t just lose a few minutes. They lose the entire mental structure they’d built up, sometimes over hours. It’s not like pausing a video, it’s more like someone shaking an Etch A Sketch. The whole picture disappears, and you have to rebuild it from scratch.

But here’s where the organizational challenge comes in. We’ve normalized constant availability. We’ve created cultures where being responsive is valued more highly than being productive. Slack channels where messages arrive every few minutes. Meeting-heavy schedules that fragment the day into 30-minute chunks. “Quick syncs” that derail whatever you were working on because someone else’s urgency became your priority.

None of this is usually malicious. The person sending that Slack message probably isn’t thinking “I’m going to destroy this developer’s flow state”. They’re thinking “I have a question and this person probably knows the answer”. The manager scheduling another meeting isn’t actively hostile to deep work, they’re just trying to coordinate across teams. But the cumulative effect is devastating.

The cost here compounds in ways that are hard to measure but impossible to miss if you’re paying attention. Developers start working nights and weekends because that’s the only time they can get uninterrupted focus. They become frustrated and cynical because they feel constantly behind despite working long hours. The best ones start looking for other jobs where they can actually do the work they were hired to do.

Cognitive load: the invisible constraint on everything else

The third principle is cognitive load, how much mental capacity developers need to expend just to accomplish their tasks. This one is subtle but absolutely critical.

Every decision a developer has to make, every piece of context they need to maintain, every tool they need to understand, all of it uses mental bandwidth that could otherwise go toward solving the actual problem. When cognitive load is high, everything else suffers. Cycle time increases because decisions take longer. Focus becomes harder to maintain because there’s so much to keep track of.

Max draws a clear line here: we need to be very intentional about what decisions developers should make versus what decisions we should make for them. Most developers don’t want to make infrastructure decisions that have nothing to do with the task they’re trying to accomplish. They don’t want to decide how CI jobs should run or what deployment patterns to use or which logging framework the company should standardize on.

Now, there’s a loud minority that will push back hard on this. But here’s the uncomfortable truth: when you’re building developer experience for a large organization, you’re not here to accelerate one individual developer. You’re here to accelerate the business as a whole.

When you allow one developer to make infrastructure choices that slow down everyone else—now or in the future—you get net negative productivity for the company. This is where things get spicy, but it needs to be said.

Good restrictions versus bad restrictions

So how do you know what decisions to restrict and what decisions developers genuinely need to make? This is where gathering requirements becomes essential. You need to really understand developers and learn what they actually need to do based on their real workflows.

It’s very easy to create overly restrictive systems that don’t let people make the choices they need to make. That can become one of the worst developer experience barriers in your company. But it’s equally easy to create systems with too much freedom that lead to chaos, fragmentation, and mountains of technical debt.

Good restrictions are usually things most people don’t want to spend time on. A single CI system, because most product teams don’t want to set up their own CI, that’s not a good use of their time. One monitoring and alerting system for the company. One log storage system for production logs. When you’re trying to resolve a production incident in a complex ecosystem, these standards become lifesavers.

Bad restrictions prevent people from solving problems effectively. The clearest example: mandating a single programming language for all use cases. Every language has contexts where it excels and situations where it becomes the wrong tool entirely. When you force teams to use the same language for high-level application code and low-level systems work, you create situations where developers spend more time fighting their constraints than building solutions.

The same pattern emerges with development tooling. Standardizing on one text editor sounds reasonable from a support perspective, but the productivity loss is real and measurable. Developers build muscle memory and workflows over years. Force someone to abandon their primary tool, and you’re not just asking them to learn something new. You’re dismantling an entire system of efficiency they’ve constructed. Their accumulated expertise becomes technical debt overnight.

The key is understanding developers and what their problems really are, so you can let them solve the problems they need to solve while you solve the other problems they don’t need to solve. And once you’ve restricted choices by providing infrastructure, you need to continue maintaining that infrastructure. Requirements evolve over time. You can’t just build it once, throw it over the wall, and abandon it. Over time it will start to restrict people’s ability to do the things they need to do as the world changes.

Why everything we’ve talked about is actually a people problem

So we understand the three principles now: cycle time, focus, and cognitive load. These cover pretty much all of the technical aspects of what developers directly experience. But here’s the reality Max emphasizes at the end of his talk: we don’t know everything about developer experience now. Not even close.

The real challenges? They’re not technical. They’re about people.

First up: you probably don’t understand your developers as well as you think. Most organizations are working off assumptions they haven’t checked in years. Maybe ever. You need to actually know what developers do all day, their real workflows, what pisses them off, where they get stuck. Without that, you’re just guessing at what to build.

Then there’s the change thing. People hate change. Even good change. You could deliver the perfect solution and someone will still complain because it’s different from what they’re used to. It’s not rational, but it’s real, and you need to be ready for it.

The ROI question never goes away. How do you know your DevEx work is actually worth the investment? If you can’t show that you’re delivering more value than you’re costing, your budget disappears. It’s that simple.

Here’s one people don’t talk about enough: learning to say no. Once you’re working on developer experience, everyone wants something from you. Every team has requests. Every developer has ideas. If you say yes to everything, you’ll drown. But saying no is hard, you need to figure out what matters, how to prioritize, and how to tell people no without making them hate you.

And the hardest part? Changing culture. You can’t policy your way into better culture. You can’t make people care about code quality or respect focus time or write good docs. That stuff comes from shared values, and building those takes time and intention. How do you actually shift how people work without just mandating it from above? That’s the real question.

What this means for your organization

If you’re leading a DevEx team or thinking about developer productivity as an engineering leader, here’s what actually matters. The technical stuff? Solvable. Faster CI/CD, better observability, improved tooling, these are engineering problems with engineering solutions. Hard, yes. But knowable.

The people problems are where you’ll struggle. Understanding what developers actually need versus what they say they need. Building enough trust that they’ll tell you the truth about what’s broken. Creating psychological safety so people can admit when they’re confused without it hurting their career. Establishing norms around focus time that stick. Getting buy-in for changes that help the many but annoy the vocal few.

The starting point is recognizing that cycle time, focus, and cognitive load are all people problems dressed up in technical clothes.

Your CI/CD pipeline doesn’t care about cycle time. Your developers do. Your calendar doesn’t care about focus. Your engineers trying to solve hard problems do. Your architecture doesn’t care about cognitive load. The people trying to navigate it every day do.

The question isn’t whether you have the right tools. It’s whether you’ve built a culture and practices that let developers actually experience those three things—fast cycles, protected focus, low cognitive load—in their daily work. Everything else is secondary.

---

While We’re Here

If you’re wondering how I stumbled across Max’s video, it’s because I’ve been on a mission to stay up to date with everything happening in the Developer Experience space. To make that easier, I built DX Radar, an auto-aggregated but hand-curated list of the latest articles and videos from around the web.

Check it out at radar.pragmaticdx.com and discover what’s happening around DX right now.