A T-shaped developer has deep expertise in one area (the vertical bar of the T) but enough breadth across adjacent disciplines to contribute meaningfully beyond their specialty (the horizontal bar). This contrasts with an I-shaped developer, who is a deep specialist in exactly one domain.
Why Agile teams need T-shaped people: In small cross-functional teams, I-shaped specialists create bottlenecks. If the only system engineer is out, the project stalls. T-shaped team members can pick up work outside their primary role β not at expert level, but well enough to keep the sprint moving. They also communicate more effectively across disciplines because they understand the difficulty and vocabulary of adjacent roles.
The compounding benefits:
- Team completeness: fewer single-points-of-failure on the team
- Mutual understanding: a backend dev who has touched frontend can have a real conversation with a frontend dev
- Open mind: someone who has learned four things has proven to themselves they can learn a fifth
- Substitutability: coverage during absence without blocking the whole team
How to become T-shaped: Itβs a slow, deliberate path β learn something new, practice it with real time investment (months, not days), exercise patience both with yourself and colleagues who are slower to expand, and share what you learn (teaching reinforces understanding). The mantra worth keeping: Think Big, Start Small, Build Deep.
After T comes Pi and M: T-shaped is not the ceiling. Some practitioners develop a second deep specialty (Ο-shaped), and organizations increasingly value M-shaped people with multiple depth areas across the stack.
Connections
- agile-manifesto β Agile values underpin why cross-functional teams matter
- software-architect-role β Architects are typically T- or Ο-shaped, with breadth across trade-off domains
Sources
- t_shaped β Original blog post (2021)