The most productive three hours of my week look suspicious from the outside. No meetings, no Slack, headphones in, do not disturb. From the inside, it's the only time I'm actually working.
I don't mean "actually working" as a knock on everything else. I mean it's the only time my brain is in the state where hard problems get solved, where the architecture makes sense, where I stop fighting friction and start making progress. Getting there, for an ADHD brain, is not as simple as closing your email client.
This isn't a rehash of productivity tips. I've written about managing ADHD at work before, and that post covers the self-management angle. This one goes somewhere different: the environment. Most software teams are structured in ways that work against how ADHD brains operate. Understanding why is the first step to doing something about it.
Context switching costs more for ADHD brains
Every developer knows context-switching is expensive. You lose your place, reload the mental model, spend time getting back up to speed. The research is solid enough that most engineers have heard the "20 minutes to get back into flow" number.
For ADHD brains, the recovery takes longer. Not because of some motivational deficit. The baseline state is noisier. A neurotypical developer who gets interrupted loses their place. An ADHD developer loses their place and has to spend additional effort quieting the mental static the interruption kicked up. The distraction doesn't just break flow. It triggers a cascade.
Slack pings, someone stopping by your desk, a quick call that runs long, a stand-up that drags — these are normal parts of team life. For a lot of developers they're just friction. For ADHD developers they can wipe out a morning.
The recovery cost is real and it's invisible. Nobody sees the thirty minutes after a ten-minute interruption where you're technically at your desk but your brain is still spinning down.
Hyperfocus is real, and it's complicated
Here's the thing ADHD stereotypes miss: the attention regulation problem runs both ways. Holding attention on something uninteresting is hard. But the flip side is hyperfocus, and in a development context, it's a legitimate advantage.
When an ADHD developer hits a problem that captures their attention, the results can be remarkable. They'll trace a bug through eight layers of abstraction without getting bored. They'll spend six hours on an API design and come out the other side with something genuinely elegant. They'll read three years of git history to understand why a function does what it does, because the mystery has them hooked.
The catch is that you can't schedule it. Hyperfocus is not the same as voluntary concentration. You can build conditions that make it more likely, but you can't tell your brain to lock in at 9 AM on Tuesday for three hours of sprint work. If the work feels interesting, the environment is right, and the friction is low, it might happen. If any of those conditions are off, it might not.
This makes estimation hard. It makes commitment-based sprints complicated. ADHD developers look inconsistent on paper when what's actually happening is that the work varies in how well it matches the cognitive profile.
What the standard dev environment gets wrong
Most software teams, even thoughtful ones, have built environments that create a lot of friction for ADHD brains specifically.
Meeting-heavy schedules break the day into chunks too small for deep work. When your morning looks like stand-up, then an hour, then backlog refinement, then lunch, then a one-on-one — you haven't given anyone a real block of time. For ADHD developers, that schedule might produce almost nothing technically useful, because none of those windows are long enough to get past startup overhead and into flow.
Constant availability expectations treat every notification as equally urgent. When Slack has the same interrupt priority as "production is on fire," you've created an environment where ADHD brains have to work harder to filter signal from noise. Filtering is already one of the harder things ADHD brains do.
Vague or oral requirements are a particular tax. "Just figure out what makes sense" or "we talked about this in the call last week" — when ADHD working memory is shaky, verbal handoffs disappear. Not from lack of effort or interest, but because the encoding didn't stick the way a written ticket would.
Open offices are, frankly, brutal. I've worked in them. The sensory load — conversations, movement, ambient noise — is hard to habituate to when your brain is already running loud. Noise-canceling headphones help. They don't fully solve it.
None of this is intentional. Teams aren't designing environments to disadvantage ADHD developers. The accumulated defaults point in that direction, though. If you're not asking "does this work for different cognitive profiles?" the answer is probably no.
What actually helps
A few things reliably make a difference. Some are individual habits. Some require team-level change.
Protected deep work windows are the single biggest lever. Two or three hours with no meetings and no expected Slack response, where you can actually get into something hard. The rest of the team doesn't lose much. Everyone gains a lot.
Async-first communication reduces the ambient interrupt load. When the expectation is "respond when you're at a good stopping point" rather than "respond now," ADHD developers can work in longer stretches. This isn't about avoiding communication. It's about batching it to points in the day when the context switch is less costly.
Written requirements with specific acceptance criteria are worth the investment beyond the usual reasons. When the definition of done is concrete and written, an ADHD developer can work independently without holding ambiguous verbal context in working memory. "Build the thing, here's what done looks like" is a better task shape than "use your judgment."
Body doubling is underrated. Working in the same space as other people engaged in focused work helps a lot of ADHD brains stay on task. Co-working sessions, focus rooms, even shared silent video calls — these are weird to explain but they genuinely work.
Task chunking that matches interest matters more than it sounds. Breaking "implement the notification system" into small, specific, independently interesting problems gives an ADHD brain more entry points into flow. "Write the webhook handler" is a better task than "work on notifications."
The Scrum Master lens
I've run a lot of sprints, and I've watched patterns that didn't make sense until I started thinking about neurodivergence explicitly.
The developer who commits in planning and delivers inconsistently — sometimes ahead of schedule, sometimes not finishing at all — might not have a motivation problem. They might have an ADHD brain that needs certain conditions to produce, and those conditions aren't always predictable.
The developer who dominates retrospectives but goes quiet in sprint reviews might be better at free-form discussion than structured presentation. The developer who's brilliant in a spike investigation but slow on routine ticket work might be following their hyperfocus rather than the backlog.
None of these are problems to fix in the developer. They're signals that the team structure might need to flex.
A few adjustments that help as a Scrum Master:
- Pair ADHD developers who struggle with routine tasks with ones who specifically want to do that work. Some people have ADHD and like routine. Executive function differences don't all look the same.
- Keep stand-ups short and structured. The roaming discussion format invites tangents that derail ADHD brains.
- Use written sprint summaries and decisions, not just verbal recaps.
- Check in privately before assuming a quiet developer has no blockers. "I'm fine" in a stand-up and "I'm stuck in an unproductive loop and don't know how to name it" can look identical from the outside.
The conversation you might need to have
Whether to disclose ADHD at work is genuinely personal. I'm not going to tell you what to do there. What I will say is that the cost-benefit is different in different environments. Think about it clearly rather than defaulting to either "keep it hidden forever" or "announce it immediately."
What often helps, regardless of disclosure: knowing what you need and asking for it in concrete terms. "I work best with two uninterrupted hours in the morning" is a reasonable request whether or not you frame it in terms of ADHD. "Can requirements be written out rather than just discussed in the call" is a reasonable ask regardless. You don't have to disclose anything to advocate for conditions that help you work well.
If you're in an environment where you trust your team and your manager, knowing can change things. The developer who looks like they don't care about deadlines looks very different when the team understands that interruptions cost them four times what they cost everyone else.
The burnout pattern
This is the part I want to be direct about.
ADHD developers burn out in a specific way. It often looks like a motivation problem from the outside, and sometimes from the inside too. The tell is that it usually follows a long period of masking — compensating for ADHD friction through extra effort, working later, pushing harder, doing the hard invisible work of managing your own brain all day on top of the actual job.
That's exhausting. You can run it for a while. Eventually you can't.
Burnout doesn't announce itself cleanly. It shows up as suddenly not being able to start tasks you used to handle easily. Hyperfocus disappears. The coping systems that used to work go offline. From the outside it looks like a motivation problem. It's actually depletion.
If you're there, pushing harder doesn't help. Usually it's the opposite: find the version of the work that asks less of the parts that are already running empty, and rebuild from there.
If you're a team lead and you see this in someone, approach it as a wellbeing conversation, not a performance conversation. The underlying issue is rarely what it looks like.
The standard developer productivity advice assumes a neurotypical baseline. Some of it works for everyone. Some of it adds friction for ADHD brains in ways you don't notice until you're looking for them. The fix isn't to work harder at the standard approach. Understand the cognitive profile. Build around that.
