Manu's Vault

Peanut Buttering Anti Pattern

3 min readStatus:Seedling

Core Idea

The peanut-buttering anti-pattern spreads engineering capacity too thinly across too many simultaneous initiatives — the wider the coverage, the thinner each layer, and the more context-switching overhead destroys throughput.

Peanut-Buttering Anti-Pattern

The peanut-buttering anti-pattern occurs when an engineering organisation spreads capacity too thinly across too many simultaneous initiatives — like spreading peanut butter across a large slice: the wider the coverage, the thinner and less effective each layer.

What It Looks Like

  • Engineers assigned to 3–5 projects concurrently, each at partial capacity
  • Every project has people working on it, but none has enough to build momentum
  • Teams perpetually context-switching between competing priorities
  • Progress is glacial on all fronts; nothing ships on time or with quality

Why It Happens

  • Stakeholder pressure: executives use resource allocation as proxy for organisational influence
  • Fear of saying no: managers avoid explicit trade-offs
  • Optimistic planning: each project “only needs one engineer for a sprint”, but totals compound
  • Accountability diffusion: when everything is a priority, nothing is

Why It’s Harmful

Research on task-switching (Meyer et al., 2001) demonstrates that switching between non-trivial tasks incurs executive control overhead. Gerald Weinberg quantified the equivalent: each additional simultaneous project absorbs approximately 20% overhead per person from context-switching alone — with five concurrent projects, up to 80% of capacity is lost.

Peanut-buttered teams are almost always stuck in Treading Water in the Four-States-of-a-Team model. Hiring more engineers does not fix it; it merely gives more people to spread thinly. The anti-pattern also compounds Organizational-Debt through half-finished work and accumulated technical shortcuts.

The Fix: Concentration Principle

  • Fewer projects, more people each: give each initiative enough capacity to build momentum
  • Explicit deprioritisation: commit publicly to what you will NOT work on this quarter
  • Outcome measurement: assess projects by shipped value, not by whether headcount is assigned
  • WIP limits: Kanban literature (Anderson, 2010) formalises this as constraining work-in-progress to match real throughput capacity

Sources

  • Larson, Will (2019). An Elegant Puzzle: Systems of Engineering Management. Stripe Press. ISBN: 978-1-7322651-8-9.

    • Chapter 2.2: Peanut-buttering as a resource allocation anti-pattern

  • Weinberg, Gerald M. (1992). Quality Software Management, Vol. 1: Systems Thinking. Dorset House Publishing. ISBN: 978-0-932633-22-5.

    • Quantified context-switching overhead: each simultaneous project costs ~20% of productive capacity

  • Meyer, David E., Joshua S. Rubinstein, and John E. Evans (2001). “Executive Control of Cognitive Processes in Task Switching.” Journal of Experimental Psychology: Human Perception and Performance, Vol. 27, No. 4, pp. 763–797. DOI: 10.1037/0096-1523.27.4.763.

    • Foundational research establishing task-switching costs and executive control overhead

  • Anderson, David J. (2010). Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press. ISBN: 978-0-9845214-0-1.

    • WIP limits as the operational mechanism for avoiding peanut-buttering

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

    • Workers take an average of 23 minutes to fully return to a task after an interruption

Note

This content was drafted with assistance from AI tools for research, organization, and initial content generation. All final content has been reviewed, fact-checked, and edited by the author to ensure accuracy and alignment with the author’s intentions and perspective.

Graph View

Backlinks