Broad > Deep: Why T-Shaped Teams Win in the AI Era

Once upon a time, I was there, it was roughly 2005, a software team was a stack of specialists.

The architect had the strategic view. Everyone else had a slice: the database person, the middleware person, the UI person, the tester at the end of the line who found out what the product was supposed to do at roughly the same time the customer did. Depth was the whole game. Your career was a well; you dug it deeper.

Client-server made this reasonable. Cloud-native made it fragile. And AI-native is making it a liability.

What changed

Cloud-native broke the walls between layers. Suddenly the developer needed to understand deployment, the ops engineer needed to understand the code, and the product manager needed to understand both because releases happened every hour, not every quarter.

AI has taken that and pressed fast acceleration. When the model can write the boilerplate, the value of a person is no longer in producing the slice, it's in knowing whether the slice is right. And you can't know that from inside a silo. You know it from context: what the customer is trying to do, what the business can afford, what the design is trying to say, what the data will do at scale.

Breadth builds context. Context drives better decisions. That's the whole thesis.

The T

The shape I hire for now is a T: real depth in one discipline (the stem) with working fluency across the neighbouring ones (the bar).

Designers who get business. Developers who think product. QA engineers who grasp user needs before they read the test plan. A product manager who can read a query plan, or at least doesn't flinch at one.

None of this means "everyone does everything". A T without a stem is a dash, pleasant in meetings, useless at 2 a.m. Depth still matters; it's just no longer sufficient. The interesting work now happens at the joints between disciplines, and the people who can stand at a joint and see both sides are the ones who make the calls that matter.

The old word for it

Indian wisdom got here first, as it often does. Sarvagun sampanna, a person of many virtues, was never a compliment for a specialist. It described someone whose capabilities connected, so that the whole was wiser than the parts.

In the AI era that's not a optional. It's the job description.

What this means if you run a team

Hire for the bar, not just the stem. In interviews I spend as much time on "what's happening in the layer above and below yours?" as on the specialty itself.

Rotate deliberately. A developer who spends a month in support, a designer who sits in on sales calls, the context comes back with them and never leaves.

Reward the connectors. Most performance systems reward depth because it's easy to measure. Find a way to reward the person who prevented a bad decision by knowing two things at once.

Let AI take the depth it can take. If a model can write the CRUD layer, don't make your best engineer prove they can too. Free them to do the thing the model can't: decide.

The point

Depth got us here. Breadth gets us through what's next. The teams I see winning in 2026 are not the ones with the deepest specialists; they're the ones where everyone can see a little into everyone else's world, and so nobody ships something clean that belongs in the bin.

Broad > deep. Not instead of. On top of.