Manu's Vault

NADD

3 min readStatus:Seedling

Core Idea

NADD (Nerd Attention Deficiency Disorder) is a trained multi-channel attention pattern common in engineers — valuable for interrupt-driven work but costly when deep focus is required, making it a management environment problem rather than an individual engineer problem.

NADD

NADD (Nerd Attention Deficiency Disorder) is Michael Lopp’s deliberately tongue-in-cheek term for the multi-channel, high-frequency attention pattern common in software engineers: simultaneously monitoring an IDE, Slack, a browser, email, and a build pipeline — switching between them fluidly and, often, productively.

What NADD Is (and Isn’t)

NADD is a reframe: what looks like distractibility from the outside is a trained adaptation to the information density of software engineering. NADD-fluent engineers scan many streams in parallel, detect relevant signals quickly, and context-switch efficiently across short-horizon tasks.

This matters for managers: NADD-fluent engineers are not broken. They are well-adapted to interrupt-driven work — triage, on-call response, code review, exploratory debugging. Pathologising this attention style misses what makes it valuable.

Where NADD Serves and Where It Fails

  • Where it serves: exploratory phases, on-call, triage, coordination-heavy situations requiring rapid context shifts
  • Where it fails: sustained creative work requiring uninterrupted focus over extended periods

Gloria Mark’s field research found that after an unplanned interruption, workers take an average of 23 minutes to fully return to a prior-depth task. Each NADD-mode context switch is low-cost only because the tasks are already shallow. The moment work requires depth, the same switching behaviour imposes heavy cognitive penalties.

The Management Implication

Lopp frames NADD as a management problem, not an engineer problem. The manager’s job is to:

  • Recognise when depth is required — architecture design, novel problem-solving, complex system reasoning
  • Protect the Zone — the uninterrupted focus state where deep work happens (see Nerd-Cave-and-Deep-Work)
  • Redesign the environment — interrupt-free blocks, async communication norms, Maker Schedule principles

Treating NADD as a discipline failure while simultaneously fragmenting engineers’ time with meetings and interruptions is the most common and most costly management error related to this pattern.

Sources

  • Lopp, Michael (2019). Managing Humans: Biting and Humorous Tales of a Software Engineering Manager, 3rd ed. Apress. ISBN: 978-1-484-23712-4.

    • Chapter 32: NADD — original framing as an adaptive rather than pathological trait

  • Mark, Gloria, Daniela Gudith, and Ulrich Klocke (2008). “The Cost of Interrupted Work: More Speed and Stress.” Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (CHI ‘08). ACM, pp. 107–110. DOI: 10.1145/1357054.1357072.

    • Field study finding average 23-minute recovery time after workplace interruption

  • Czerwinski, Mary, Eric Horvitz, and Susan Wilhite (2004). “A Diary Study of Task Switching and Interruptions.” Proceedings of CHI ‘04. ACM, pp. 175–182. DOI: 10.1145/985692.985715.

    • Knowledge workers switch tasks ~50 times per week; returned-to tasks are the most complex ones

  • Newport, Cal (2016). Deep Work: Rules for Focused Success in a Distracted World. Grand Central Publishing. ISBN: 978-1-455-58669-1.

    • Frameworks for protecting depth; the high-value complement to NADD’s default shallow-mode scanning

  • Graham, Paul (2009). “Maker’s Schedule, Manager’s Schedule.” Paul Graham Essays. Available: http://www.paulgraham.com/makersschedule.html

    • Structural incompatibility between interrupt-driven manager scheduling and technical makers’ focus needs

Note

This note was researched and drafted with AI. How these notes are written →

Graph View

Backlinks