The T-Shaped Fallacy: It's Not About Coverage

Every engineering blog has written about T-shaped engineers by now. The concept is everywhere: broad knowledge across the stack, deep expertise in one area. Full-stack but focused. It sounds right. And it’s completely misunderstood by most people who use the term.

The real insight isn’t about coverage. It’s about judgment. The T-shape isn’t “I can touch backend, frontend, and DevOps”—that’s full-stack, which is just a statement of skill inventory. The T-shape is “I know enough across the stack to recognize where depth actually matters, and I have the discipline to own that depth completely.”

Most discussions of T-shaped roles get this backwards. They talk about breadth as the constraint—be good enough at multiple things. But breadth is easy now. AI makes breadth a commodity faster than depth ever was. The real constraint is the vertical bar: the judgment about where to go narrow, and the sustained discipline to stay there.

The Difference Between Coverage and Ownership

I can learn enough frontend to ship a screen. I can learn enough DevOps to stand up infrastructure. That’s coverage. But there’s a difference between “I can do this” and “I own this completely,” and the difference is where judgment lives.

PostHog wrote about product engineers with a line I keep thinking about: “They care more about outcomes than the exact implementation.” That’s not saying they’re shallow across domains. It’s saying they’re strategic about where they go deep. They look at a problem and ask: Where does my depth actually change the outcome? And then they go deep there. That’s the vertical bar.

The common mistake is thinking the T-shape means “spread yourself thin enough to seem valuable everywhere.” The honest version is: “be shallow enough everywhere to make good decisions, then go very deep in the one place where your depth changes the game.”

Why This Matters Right Now

In a world where AI learns domains as fast as you can feed it documentation, the engineer who knows “a little about everything” is common. The engineer who knows “a little about everything AND has made a deliberate, justified choice about where to go deep”—that person is rare.

The rarity isn’t in the breadth. It’s in the judgment. It’s in having the taste and experience to say: “This is the layer that matters. This is where my attention goes. Everything else, I’ll understand enough to be dangerous, but I won’t own it.”

Most engineers, especially early in their careers, experience this as a constraint. “I have to specialize.” “I can’t do it all.” But it’s actually freedom. The T-shape isn’t a limitation. It’s permission to be strategic. To own something completely. To know that the quality of your work in that one place—where you went deep—is the thing that matters.

That’s the real T-shape. And it’s why it matters more now than it ever did.

The Strategic Implication for Your Own T

This isn’t abstract for me. I spent six years building depth in iOS. Then I spent time building breadth in backend—understanding the systems on the other side of the API boundary.

Here’s the question that matters: Where should I now go deep?

The answer isn’t “whichever pays better” or “whichever has more open positions.” It’s: where do I already have the foundation to go really deep, and where does the breadth I’ve acquired actually amplify my judgment?

I’m a senior iOS engineer. That’s my foundation. That’s where I have six years of refined taste and hard-won judgment. I now also understand backend deeply enough to recognize good API design, data integrity trade-offs, and scale implications. But I don’t have six years of backend judgment. I have 1+ year.

The T-shape for me isn’t “I’ll go deep in backend and be broad in iOS.” That would mean competing for mid-level backend positions against people with better domain intuition. The T-shape for me is doubling down on iOS, but with backend knowledge that makes my iOS decisions sharper. That’s a senior-level position. That’s expertise I can actually claim.

This is the insight the market hasn’t fully absorbed yet: not every engineer should follow the same T. Your T should stack your existing depth with breadth that amplifies it, not replace it.