Scrolls
5 min read
On this page

T-Shaped Skills

The most valuable developers are not the ones who know everything about one thing, and not the ones who know a little about everything. They are the ones who are deep in one area and broad across many. This is the T shape: the vertical bar is your depth, the horizontal bar is your breadth.

Specialists plateau. They become the person who knows everything about Postgres but cannot have a meaningful conversation about frontend performance or deployment strategies. Their career options narrow as their expertise deepens. Generalists get lost. They know a bit of React, a bit of Python, a bit of Kubernetes, but cannot go deep enough in any of them to solve hard problems. They are perpetually the person who "knows a little about that" but never the person who owns a solution.

The T shape avoids both failure modes. Be the best at one thing. Be competent at five.

What Depth Means

Depth is not "I have used this technology for 5 years." Depth means you understand the technology well enough to debug problems that others cannot, make architectural decisions with confidence, and teach others.

Levels of depth:

Level 1 - Awareness:
  "I know this technology exists and what problem it solves."
  (Enough to have a conversation, not enough to contribute)

Level 2 - Working knowledge:
  "I can use this technology to build things with documentation."
  (Can be productive, but needs reference material frequently)

Level 3 - Proficiency:
  "I can build complex systems, debug hard problems, and make
  architectural decisions."
  (Can work independently, mentors others)

Level 4 - Expertise:
  "I understand the internals, can optimize for edge cases, and
  can evaluate tradeoffs that are not in any documentation."
  (The person everyone goes to with hard questions)

Level 5 - Mastery:
  "I contribute to the ecosystem, shape best practices, and can
  extend the technology in novel ways."
  (Conference talks, open source contributions, book-worthy)

Your depth area should be at Level 4 or higher. Your breadth areas should be at Level 2-3. Level 1 across the board is not a T -- it is a dash.

Choosing Your Depth

Your depth area should be at the intersection of three things: what you are good at, what you enjoy, and what the market values.

Good depth areas (high demand, clear career path):
- Backend systems (distributed systems, APIs, databases)
- Frontend engineering (complex UIs, performance, accessibility)
- Infrastructure/platform (Kubernetes, CI/CD, cloud architecture)
- Data engineering (pipelines, data modeling, analytics)
- Security engineering (application security, threat modeling)
- Machine learning engineering (ML systems, not just model training)

Questions to identify your depth:
- What kind of problems do you voluntarily spend time on?
- What topics do you read about outside of work?
- What questions do teammates bring to you?
- What work gives you the most energy?
- Where do you have the most accumulated experience?

Do not choose a depth based solely on market demand. If you hate infrastructure work, becoming a Kubernetes expert will make you miserable regardless of the salary. Your depth should be something you can sustain interest in for years, because expertise takes years.

What Breadth Means

Breadth is the ability to work across boundaries. A backend developer with frontend breadth can review a React PR intelligently, have a productive conversation with the frontend team about API design, and build a quick prototype UI when needed. They are not a frontend expert, but they are not helpless either.

Breadth areas for a backend developer:
- Frontend (enough to build a prototype, read React code, discuss UX)
- Infrastructure (enough to write a Dockerfile, read Terraform, debug
  a deployment)
- Databases (enough to design a schema, write queries, understand
  indexing)
- Security (enough to avoid common vulnerabilities, review auth flows)
- Product (enough to understand user needs, push back on requirements)

Breadth areas for a frontend developer:
- Backend (enough to build a simple API, understand REST/GraphQL,
  read backend code)
- Design (enough to implement a design system, discuss UX tradeoffs)
- Performance (enough to profile, optimize bundle size, understand CDNs)
- Accessibility (enough to build WCAG-compliant interfaces)
- Infrastructure (enough to configure a CDN, understand CI for frontend)

The specific breadth areas depend on your role, your team, and your career goals. But the pattern is consistent: deep in one, competent in several.

Why the T Shape Wins

The T shape creates unique value that neither specialists nor generalists can provide.

Specialist (I shape):
- Can solve very hard problems in one domain
- Cannot effectively collaborate across domains
- Bottleneck: the team depends on them for one thing
- Career risk: if the technology declines, so does the career
- Communication gap: cannot explain their work to other teams

Generalist (dash shape):
- Can work on anything at a surface level
- Cannot solve hard problems in any domain
- Perceived as junior regardless of experience
- Career risk: always the backup, never the lead
- No clear identity or value proposition

T-shaped:
- Can solve hard problems in one domain (the depth)
- Can collaborate effectively across domains (the breadth)
- Not a bottleneck: others can learn from their depth area
- Career resilience: depth provides expertise, breadth provides options
- Bridges between teams: translates between domains

The bridging function is underrated. The T-shaped developer who is deep in backend and broad in frontend becomes the person who designs APIs that frontend developers actually want to use. They do not need to be a frontend expert. They need to understand enough to empathize with the frontend team's constraints.

Building Your Breadth

Breadth is not acquired by taking courses. It is acquired by doing real work in adjacent areas. The most natural way to build breadth is to take on tasks slightly outside your comfort zone.

Practical breadth-building:

- Review code outside your specialty. Read frontend PRs if you are
  a backend developer. You will learn patterns and pain points.

- Volunteer for cross-functional tasks. "I'll set up the CI pipeline
  for this project" teaches you infrastructure even if you are a
  frontend developer.

- Pair with specialists in other areas. Spend an afternoon with the
  DBA. Watch them diagnose a slow query. Ask questions.

- Do on-call rotations that expose you to the full stack. Debugging
  a production incident teaches you more about infrastructure in one
  night than a month of reading.

- Build side projects in adjacent technologies. If you are a Python
  developer, build something small in Go. Not to become a Go expert,
  but to understand the paradigm.

- Read architecture decision records (ADRs) from other teams.
  Understanding why they chose a particular database or message
  queue broadens your perspective.

Deepening Your Depth

Breadth is relatively easy to acquire. Depth is harder because it requires sustained investment in one area over years.

How to go from Level 3 (proficient) to Level 4 (expert):

- Read the source code of the tools you use. Understand how your
  database query planner works. Read the framework's routing code.

- Debug hard problems instead of working around them. When you hit
  a weird behavior, understand the root cause, do not just find a
  workaround.

- Teach others. Explaining a concept forces you to understand it
  deeply. Write internal docs, give tech talks, mentor juniors.

- Read research papers and design documents. Not tutorials -- the
  primary sources that shaped the technology.

- Contribute to open source projects in your depth area. Reviewing
  issues and PRs teaches you edge cases you would never encounter
  in your own work.

- Attend or watch conference talks by the creators and maintainers
  of the technology. Their mental models are the most accurate.

The jump from Level 3 to Level 4 is where most developers stall. They are proficient enough to be productive and stop investing in depth. The difference between a proficient developer and an expert is not the ability to write code -- it is the ability to make decisions that avoid problems before they occur.

The Pi Shape & Beyond

Some developers eventually develop two areas of depth, creating a Pi shape (two vertical bars). This is rare and takes a decade or more, but it is extraordinarily valuable.

Pi-shaped examples:
- Deep in backend systems AND deep in infrastructure
- Deep in frontend engineering AND deep in design
- Deep in security AND deep in distributed systems
- Deep in data engineering AND deep in machine learning

Why Pi is powerful:
The combination of two deep areas creates insight that neither
area alone provides. A developer who is deep in both security
and distributed systems can design secure distributed systems
in ways that a security specialist or a distributed systems
specialist cannot.

Do not aim for Pi from the start. Build your T first. If a second depth area emerges naturally from your work and interests, pursue it. But forced Pi-shaping -- trying to be deep in two areas simultaneously -- usually results in being mediocre in both.

Common Pitfalls

  • Going broad too early. Junior developers should focus on depth first. You need one area of expertise before breadth becomes valuable. Without depth, breadth is just scattered familiarity.
  • Refusing to go broad. Senior developers who only work in their specialty become bottlenecks and limit their career growth. At some point, you need to invest in breadth.
  • Confusing familiarity with competence. "I've used Kubernetes" is not breadth. "I can write a Helm chart, debug a failing deployment, and explain pod scheduling" is breadth.
  • Choosing depth based on hype. Blockchain, AI, whatever is trending -- if you do not genuinely enjoy the work, you will not sustain the investment needed for real depth.
  • Not maintaining depth. Technology evolves. If your depth is in a framework that was popular 5 years ago and you have not kept up, your depth is eroding. Stay current in your depth area.
  • Comparing your breadth to someone else's depth. You will never know frontend as well as the dedicated frontend developer. That is fine. Breadth means competent, not expert.

Key Takeaways

  • The T shape is deep in one area (Level 4+) and broad across several (Level 2-3). Neither pure specialist nor pure generalist.
  • Your depth area should be something you enjoy, are good at, and the market values. It takes years to build, so choose carefully.
  • Breadth is built through real work in adjacent areas: code reviews, cross-functional tasks, pairing with specialists, on-call rotations.
  • The bridging function of T-shaped developers is underrated. They translate between teams, design better interfaces, and catch problems that specialists miss.
  • Build depth first, then breadth. Junior developers need a foundation before cross-domain work adds value.
  • Some developers eventually build a Pi shape (two deep areas). Do not force it. Let it emerge from genuine interest and sustained practice.