Cognitive Complexity and Developer Burnout

Decision fatigue can commonly accompany burnout, so it has been something that I’ve come across in my coaching practice for many years. However, recently I’ve noticed that AI is contributing an interesting layer to this. I’ve worked with many capable, thoughtful leaders. Their workloads are not always extreme. In some cases, AI and automation have even reduced the volume of manual tasks. On paper, things should feel lighter. However, many of them are describing a different kind of tired. They often describe themselves as feeling “mentally thin”, “disconnected” and “struggling to think clearly” about things they used to hold with ease. 🙄 They find it harder to remember details. 🙄 Prioritising feels more effortful. 🙄 Their motivation dips even when performance looks fine from the outside. 🙄 They feel as though they are constantly responding, reviewing, deciding, but rarely truly engaging. Sitting underneath the surface seems to be decision fatigue accompanied by a quiet loss of ownership. We often talk about burnout as too much work. The volume of work can absolutely be a leading contributor, however so too can be loss of agency and meaning, constant mental switching, as well as high demand with low sense of authorship. AI is an interesting player in this because although it can remove effort, it can also multiply choices. 🤔 Is this summary right? 🤔 Which suggestion do I take? 🤔 Do I trust this output? 🤔 Should we follow this recommendation or that one? Those micro-decisions rarely feel dramatic, but they accumulate. Without time to reflect, process and integrate, people stay in a state of ongoing cognitive activation. The brain never quite settles, thinking quality drops and creativity narrows. We start defaulting instead of discerning. On the outside, work looks streamlined. All the while, on the inside, people feel less present in their own roles. There is a sense of doing the job, but not feeling "connected" to the job. After noticing this pattern, I read a Forbes Coaches Council article by Daria Rudnik on decision fatigue and AI, and it articulated this dynamic so clearly. The risk is not only job loss, i is cognitive loss and the loss of connection to our own thinking, memory and judgement. For me, this feels like an important evolution in the burnout conversation. I don't think sustainable performance in an AI-shaped world will just be about productivity tools. I sense that it is increasingly going to be about protecting human cognition, agency and meaning. I would love to hear what you have been noticing. Has AI genuinely created more mental space for you, or has it quietly added to your cognitive load in ways you did not expect? #BurnoutPrevention #CognitiveWellbeing #FutureOfWork

"Burnout sneaks up when you're doing side projects and sprints - there's no off switch." My view? Your best developers may be struggling, but admitting AI tools create new problems feels risky when everyone expects 10x productivity gains. What I'm noticing in teams using AI: Context switching sucks. Jumping between Cursor, Claude, GitHub Copilot, and your IDE creates mental overhead. Each tool has different suggestions, patterns, and workflows. By the time developers synthesize all the AI inputs, they've lost their original train of thought. Senior devs are becoming reviewers. Despite promises of efficiency, 67% of developers now spend more time debugging AI-generated code than before. They spend too much time examining generated output instead of writing their own. Quality anxiety is spreading. "Am I actually getting better, or just faster?" Developers are shipping more code but losing confidence in what they're building. The documentation void hurts. AI doesn't explain why it made certain choices. Your developers are reverse-engineering AI decisions to understand their own codebase. They're becoming archaeologists in their own repositories. The hardest part: Your craft-focused developers—the ones who care most about product quality and system design—are burning out. Research shows 63% of developers now say leaders don't understand their pain points, up from 44% last year. As a leader at atono that's not what I want! Sunday anxiety about Monday, may not be about the tools failing. It's about trying to maintain engineering standards while managing AI at production scale. What are your teams saying?

The best technical leaders I know are accidentally burning out their highest performers. They call it "optimization." Their teams call it Sunday night anxiety. After coaching 40+ engineering leaders, I can spot it: your metrics are green, but your people are quietly breaking. Here's the invisible system running your team: Your monitoring stack tracks everything except what actually matters. → CPU usage gets alerts ↳ Cognitive overload goes silent → Latency has dashboards ↳ Emotional exhaustion doesn't → Deploy frequency shows green ↳ Sunday night anxiety isn't instrumented You're optimizing your team like a distributed system. More throughput. Higher velocity. Maximum coverage. But humans aren't microservices. They don't auto-scale when you add load. They don't fail gracefully with circuit breakers. They accumulate stress debt until they crash - usually by quitting. And when they quit, it's not just the company that pays. Your skip-level asks why you can't retain talent. Your next promotion includes "leadership concerns." The team that's left wonders if they're next. You're recruiting constantly, your roadmap keeps slipping, and you can't figure out why building great systems isn't enough. The leadership operating system you didn't know you were running: You inherited "high performance culture" and implemented: Sprint velocity tracking that gamifies exhaustion On-call rotations prioritizing coverage over recovery "Efficient" standups that killed human connection Your intention: build excellence. Your impact: build burnout factories disguised as engineering teams. The gap between those two is invisible in your dashboard. Here's what changed for one VP I worked with: He lost two senior engineers in one month. Both cited burnout. Metrics up 30%. We debugged his leadership operating system. He treated "sustainable pace" like tech debt: fix later, after shipping. We recoded three things: Added instrumentation for human systems → Weekly 1-on-1: "What's draining your energy that's not on the board?" → Tracked emotional debt like technical debt Scheduled recovery windows like deployment windows → Post-deploy recovery became non-negotiable Shifted identity from optimizer to protector → High performance isn't maximizing throughput → It's sustaining excellence without breaking people Six months later: zero attrition, two internal promotions, team engagement up 40%. Same roadmap pressure. Different leadership operating system. The shift isn't about being nicer. It's about debugging the systems burning out your people. Most technical leaders don't see this until their best people leave. If your A-players are going quiet while metrics look great, you're running this system. I'm having private discussions with engineering leaders debugging this pattern right now. If you're seeing the signs, let's talk. ♻️ Share this if you've seen metrics go up while morale goes down. 🔔 Follow Dan Tudorache for leadership identity insights.

18 inches of snow today. 6 AI agents running. And I’m more exhausted than ever. This morning, in the middle of a noreaster, I was operating like an AI air traffic controller. Pandemic PTSD. By 10am: • Created a video in NotebookLM • Iterated on prompts in Cowork to extract unstructured data from CIMs • Prepped for a client call • Had Grok to summarize frameworks for understanding Saas multiples (from X), and identify differences • Iterated on a zap that identifies high priority tasks for AI to support/ augment for my clients • Ask Claude in Chrome to analyze someone's responses in Typeform Objectively? I was wildly productive. But my nervous system felt like it was 2020 again. We talk constantly about AI leverage. “Run agents in parallel.” “Do the work of 10 people.” “Automate everything.” And it works. Employees using AI report up to a 40% productivity increase 78% of organizations are already using AI in at least one function But here’s the part no one is talking about: Ambient AI creates ambient cognitive load. When agents are always running, your brain is always partially engaged. You’re not doing the work. You’re supervising it. And supervision across 6 or 7 (yes, I said that) cognitive threads is exhausting. Here’s what I’m noticing: • Less deep work, more orchestration • More micro-decisions per hour • Constant context switching • Harder transitions into true rest It feels productive. It also feels manic. Ten minutes here. Ten minutes there. Spin something up. Let it run. Come back. Adjust. Switch again. The fatigue isn’t from typing. It’s from tracking. This is the AI productivity paradox. AI magnifies output. But it also magnifies optionality. Optionality → more decisions More decisions → more cognitive load More cognitive load → burnout (if unmanaged) We’re entering the era of ambient intelligence. Always-on copilots. Background agents. Parallel workflows. The companies that win in AI will redesign how humans work alongside it. Because AI integration is necessary. But not sufficient for winning If you’re feeling both supercharged and strangely fried… You’re not behind. You’re early. The real question now isn’t: “How do we use more AI?” It’s: “How do we protect deep work and nervous system health in an AI-first world?” Curious: are you feeling this too? This my daughter and dog in 18 inches of snow today:

As our tech stacks become increasingly complex, we're facing a crucial challenge that often goes unaddressed: the mounting cognitive load on developers 🤯 Think for a second, today's developer have to juggle with: - Migrations - Build failures - Code reviews - Task planning - Technical debt - Alignment meetings - Security requirements - Incident management - Fragmented documentation - Monitoring 10+ metrics dashboards - Multiple programming languages and frameworks and on top of that, engineering orgs run performance reviews and surveys to understand how the teams are doing! It not only impacts productivity but also causes burnouts! The most productive engineering cultures aren't just about coding faster—they're about creating environments that respect cognitive limits. - Limit meetings, let devs block time for deep work - Standardize workflows - Rely on automation wherever possible - Leave space for innovation, hackathons, and off-sites to foster creativity Let the fires burn - not every problem need to be solved, not every system need to be perfect! We should learn to prioritize, and maintain a trash can for everything else! #SoftwareDevelopment #DeveloperProductivity #Engineering