Why Technical Breadth Matters More Than Ever

The Shift I Noticed

For most of my career, the advice was consistent: pick a specialty, go deep, become an expert. That was the safe path, and it worked for a long time.

Lately, I’m starting to think the rules have shifted. Working with AI every day, the skill that matters most isn’t how deep I go into a single technology. It’s how wide my awareness spreads across many.

Two Tiers from the Book

I picked this framing up from Fundamentals of Software Architecture by Mark Richards and Neal Ford. They describe a kind of knowledge pyramid for technologists that I keep coming back to.

At the top is stuff you know — the technologies you’ve used, the patterns you can apply without thinking, the frameworks you’ve actually built things with. This is depth.

Below that is stuff you know you don’t know — the technologies you’re aware of and understand at a high level, but haven’t actually used. You know Kafka is a streaming platform. You’ve heard of event sourcing. You couldn’t write it from scratch, but you know it’s a tool in the toolbox. This is breadth.

There’s a third tier at the bottom — stuff you don’t know you don’t know — but that’s a rabbit hole for another post.

The book’s point, and the one that stuck with me, is that the second tier is where technical leverage really lives. You can’t choose a tool you don’t know exists.

Why Depth Used to Be the Edge

For a long time, going deep was the smart bet. If you knew one database, one language, or one framework better than anyone around you, that was your value. Specialization paid well. Teams needed people who could answer the hard questions nobody else could.

Breadth, by contrast, was often dismissed as “a mile wide and an inch deep” — a generalist label that wasn’t always a compliment.

That model made sense when depth was expensive to build. It took years of real projects to become the person who just knew a technology inside and out. Whoever paid that cost earned the edge.

AI Changed the Math

I’ve started to notice something. A lot of what used to take days of reading source code, digging through documentation, or fighting with a new tool can now be done in a short conversation with an AI. Depth, the kind that used to take weeks to build, has gotten cheap.

And when depth gets cheap, breadth becomes the scarce skill.

Here’s what I mean. AI is genuinely good at going deep on things I don’t know well. But it can only help me if I know what to ask. If I’ve never heard of a technology, I can’t prompt my way to it. The more tools, patterns, and ideas I’m aware of, the more options I can put on the table when I’m working through a problem with AI.

Picking between two queue systems, two database engines, or two frameworks isn’t really about mastering one of them. It’s about knowing enough about each to weigh the trade-offs for your situation. That’s a breadth problem, not a depth problem.

And no model, no matter how capable, knows the full context of what I’m building. It doesn’t know my team’s skill set, our budget, our deadlines, or the quirky constraints the business cares about. Architecture, integration, tool selection — those decisions sit with the human. Breadth is what lets me make them well.

This gets more pronounced as we move toward agentic workflows. When an AI agent is doing the actual implementation, my job shifts further toward direction, selection, and review. All of which lean hard on breadth.

Depth still matters in some places. If you’re working in a niche domain — security, performance-critical systems, low-level infrastructure, banking — deep expertise will always pay off. I’m not saying depth is dead. I’m saying the balance has shifted.

For everything else, depth has become something you pull in when you need it, instead of something you pre-load just in case.

Rethinking How I Learn

This has changed how I spend my learning time.

I’ve picked up a habit from the same book: spending 20 minutes a day learning a specific topic. No big commitment, no deep dive. Just enough to move things from “stuff I don’t know” into “stuff I know I don’t know.”

I’ll share more about this in my next post — Twenty Minutes a Day for Technical Breadth. For now, what I’m convinced of is this: the engineers who’ll do well in the next few years aren’t the ones with the deepest stack. They’re the ones with the widest map.

✌️