Manu's Vault

Breadth vs Depth

10 min readStatus:Seedling

Argument

Depth and breadth are not rivals to be ranked but two dimensions to be balanced over a career — and the right balance depends on the environment and career stage, not on a universal rule. The architect’s shift from developer is fundamentally a shift along this axis, and the psychology of learning explains why it is hard and how to do it well.

The Core Distinction

Developers are rewarded for depth: deep expertise in specific technologies that lets them solve hard implementation problems. Architects are rewarded for breadth: knowing that multiple solutions exist and judging the trade-offs among them. The transition between these roles is the central tension this cluster of notes explores.

Technical Breadth vs Depth

Core Idea

Developers focus on technical depth (expertise in specific technologies), while architects require technical breadth (understanding of multiple solutions and their trade-offs).

Resolving the Tension: The T-Shape

The dichotomy is false in its extreme form. The durable resolution is not “depth or breadth” but a shape — deep in one area (the vertical bar) and broad across adjacent areas (the horizontal bar), evolving toward Pi- and M-shapes as a career matures.

T Shaped Skills Model

Core Idea

T-shaped professionals combine deep expertise in one area (vertical bar) with broad collaborative knowledge across disciplines (horizontal bar). Not just a generalist — maintains a core area of deep expertise while enabling both specialization and versatility.

Origin

Coined by McKinsey in the 1980s during organizational restructuring analysis; popularized by Tim Brown (IDEO CEO) as central to design thinking; now a standard expectation for senior technical roles.

Model Breakdown

Vertical Bar (Depth): Deep, specialized expertise in one domain (e.g., distributed systems, database design, security, ML). Provides credibility, authority, and ability to solve hard problems. Requires active maintenance.

Horizontal Bar (Breadth): Broad collaborative knowledge across 2-3 adjacent areas (e.g., multiple languages, deployment strategies, team dynamics). Enables collaboration, reduces silos, and facilitates cross-domain connections.

Skill Shape Comparison

ModelProfileBest For
I-shapedSingle depthEarly career, specialized roles
T-shapedDepth + breadthMid-career, senior ICs, architects
Pi-shapedTwo depths + breadthPrincipal level, cross-domain experts
M-shapedThree+ depths + breadthVery senior, complex organizations

Anti-Patterns

  • “T-shaped in name only”: Claims depth but can’t solve hard problems in supposed specialty; lacks credibility with experts
  • “Lazy T-shape”: Rests on existing depth, avoids building breadth; becomes a silo expert
  • “Sideways T”: Very broad but no real depth anywhere — exactly what the model is meant to avoid

Evolution Path

After mastering T-shape (5-10 years): add another vertical bar (Pi-shaped), deepen further in current domain, or transition toward management/leadership.

Sources

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.

The Career-Stage View

When to emphasize each dimension changes over time. Early career typically favors building credible depth; mid and senior stages shift weight toward breadth for architecture and leadership roles. The decision is context-dependent — industry stability, role, and personal strengths all move the optimum.

Specialist vs Generalist Trade offs

Core Idea

Neither pure specialization nor pure generalization is optimal; context determines the right balance. Specialists command premium compensation and deep problem-solving ability but face career rigidity and obsolescence risk. Generalists enjoy flexibility and career optionality but may lack market differentiation and credibility in complex problems.

Why the Environment Decides

A crucial qualifier comes from psychology: depth-through-experience only reliably compounds in kind environments with stable rules and fast feedback. Software architecture is a wicked environment — rules shift, problems rarely repeat exactly, and feedback is delayed. That is precisely why breadth and judgment beat narrow pattern-matching here, and why naive “years of experience” can mislead.

The Cognitive Machinery

Breadth and depth map onto two kinds of intelligence and two kinds of learning. Knowing this turns “be more broad” from a slogan into a practice.

Knowledge Flow vs Knowledge Stock

Core

Organizations should optimize for knowledge flow (how learning moves through the system) rather than knowledge stock (what information exists). Teams with good knowledge flow are more adaptive and learning-oriented than those with extensive documentation but poor circulation of ideas.

The Fundamental Distinction

Knowledge Stock:

  • What the organization knows at a point in time
  • Stored in documentation, code repositories, and people’s minds
  • Often becomes stale or hard to find
  • Static snapshot of understanding
  • Measured by: documentation coverage, expert availability

Knowledge Flow:

  • How knowledge moves through the organization
  • Who learns from whom, and how quickly
  • How problems get solved collaboratively
  • Dynamic, adaptive process
  • Measured by: learning speed, cross-team collaboration, onboarding time

Why Flow Matters More Than Stock

The traditional approach focuses on accumulating knowledge (write more docs, hire more experts). But static knowledge has problems:

  • Documentation becomes outdated quickly
  • Experts become bottlenecks
  • Knowledge is concentrated in isolated pockets
  • Teams duplicate work unknowingly

Knowledge flow enables:

  • Rapid adaptation to changing requirements
  • Distributed problem-solving
  • Organizational resilience (not dependent on individuals)
  • Continuous learning culture

The Four Quadrants

High Stock, Low Flow → Information silos, duplicated work, experts hoard
High Flow, Low Stock → Teams learn quickly, solve together, agile adaptation
High Flow, High Stock → Ideal: documented learning + active sharing
Low Flow, Low Stock → Early startups: chaotic but learning happens

Most organizations try to move from low-low to high-stock. Better path: low-low → high-flow → high-flow-high-stock.

How Breadth and Depth Relate to Flow

Depth generates knowledge:

  • Deep expertise creates valuable insights
  • Specialist knowledge is the source material
  • Without depth, nothing valuable to flow

Breadth facilitates flow:

  • T-shaped people bridge between specialists
  • Cross-domain understanding enables translation
  • Breadth creates the pathways for knowledge to travel

The architect’s challenge: Generate knowledge through expertise AND distribute it through breadth.

Knowledge Flow at Different Scales

Individual Level:

  • Do I learn from others?
  • Do I apply knowledge across contexts?
  • Do I share what I discover?

Team Level:

  • Does the team have a shared understanding?
  • Can members explain decisions to each other?
  • Do new members learn quickly?

Organization Level:

  • Does knowledge cross team boundaries?
  • Are there silos where knowledge gets stuck?
  • Can teams learn from each other’s experiences?

Industry Level:

  • Do we share learnings publicly (conferences, blogs)?
  • Do we learn from industry trends?
  • Do others benefit from our innovations?

Common Knowledge Flow Failures

Single Point of Failure: Knowledge concentrated in one person

  • Impact: Organization dependent; knowledge lost if person leaves
  • Solution: Deliberately spread through breadth and mentoring

Silos: Teams don’t share across boundaries

Documentation Decay: Knowledge captured but becomes stale

  • Impact: Outdated information is worse than none
  • Solution: Focus on living documentation that explains reasoning

Expert Hoarding: Specialists don’t share knowledge

Relationship to Architecture

Architecture is fundamentally about designing for knowledge flow:

  • System boundaries affect how knowledge flows between teams (see Conway’s-Law)
  • Documentation practices determine flow through time
  • Code review and design processes create flow opportunities
  • The architect’s role is to facilitate this flow

Traditional view: Architect makes decisions Better view: Architect designs contexts where teams learn and decide together

Sources

Knowledge Flow in Architecture:

  • Larsen, Diana and James O. Coplien (2010). “Organizational Patterns for Teams.” Proceedings of the 17th Conference on Pattern Languages of Programs (PLoP ‘10).

  • InfoQ Interview: “Architecture is Designing Knowledge Flow – Diana Larsen” (2019).

Knowledge Management Theory:

  • Snowden, Dave J. (2002). “Complex Acts of Knowing: Paradox and Descriptive Self-Awareness.” Journal of Knowledge Management, Vol. 6, No. 2, pp. 100-111.

    • Knowledge as flow vs knowledge as thing
    • Complexity and knowledge management
    • DOI: 10.1108/13673270210424639

  • Nonaka, Ikujiro and Hirotaka Takeuchi (1995). The Knowledge-Creating Company: How Japanese Companies Create the Dynamics of Innovation. Oxford University Press.

    • Knowledge creation through flow
    • SECI model of knowledge conversion
    • Ba (shared spaces) enabling flow
    • ISBN: 978-0195092691

Organizational Context:

  • Bass, Len, Paul Clements, and Rick Kazman (2021). Software Architecture in Practice (4th Edition). Addison-Wesley.

    • Chapter 24: “Architecture and the Organization”
    • Knowledge flow in architectural decision-making
    • ISBN: 978-0136886099

  • Kim, Gene, Jez Humble, Patrick Debois, and John Willis (2016). The DevOps Handbook. IT Revolution Press.

    • Part V: “The Technical Practices of Flow”
    • Knowledge flow in DevOps culture
    • ISBN: 978-1942788003

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.

Duties Skills Knowledge Model

Core Idea

Software architect competence cannot be measured by a single dimension. Instead, it integrates three interdependent areas: the Duties an architect performs, the Skills they employ, and the Knowledge they possess.

Learning Agility Fluid vs Crystallized

Core Idea

Career success requires two distinct types of learning: fluid learning (adapting to new) and crystallized learning (applying accumulated wisdom). Breadth develops through fluid learning; depth through crystallized learning. Both are essential for sustained career growth.

The Failure Mode

Depth maintained past its relevance, without breadth, hardens into the Frozen Caveman Anti-pattern: confident decisions drawn from an outdated past. Breadth is the hedge against it.

Synthesis

The honest answer to “breadth or depth?” is both, sequenced and balanced for your environment. Build enough depth to earn credibility and to know what real expertise feels like; build breadth continuously so you can recognize alternatives, transfer ideas across domains, and adapt when your specialty shifts. In wicked domains like architecture, weight the balance toward breadth — and use deliberate, effortful learning to make that breadth stick.

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