Specialization, Generalization, and Who Gets to Be Complete

Specialization makes perfect sense when you have close to infinite demand for that skill. Generalization makes sense when you want to serve a dynamic, broader demand. It is that simple.

Should doctors operating on knees also do hips? No. Why would they? There is an infinite demand of misplaced meniscus and torn ACLs. Should a neurosurgeon also set broken bones? No need — there's more than enough demand to fill a career ten times over.

Must a classical pianist also learn to play other instruments? Not required. There are more piano tunes than she can ever play in her lifetime.

What about a backend Java developer? The one that is on a payment team? Should she stay in that narrow niche?

Well, it depends. Depends on the stability of the demand. And historically perhaps it used to be more or less stable. Or we thought it was — and we covered the fluctuations by making up work. But that worked well for a while.

As a result the ultimately holistic discipline of software engineering got artificially split over time into dozens upon dozens of micro-specializations.

Now I see the pendulum is accelerating the other way.

In the age of AI / agentic engineering almost anyone can open almost any repository, prompt an architectural diagram, figure out how to run tests, build, deploy, add missing coverage — and eventually make necessary changes. The stable narrow demand that justified "I only do payments in Java" is collapsing. The sand castles of narrow career paths are being washed away. (It's the same shift I traced in AI Replaces Tasks, Not People and Routine vs. Adaptive Expertise.)

But here's the thing that bothers me the most: the individual can't generalize if the organization won't let them. A developer ready to work end-to-end hits a wall when the org chart still carves work into component teams, hands it through queues, and measures people by role, not outcome. The structure — not the tooling — determines who gets to be complete. I keep running into this same wall in The Super IC Trap and in the Multi-Learning org design pattern.

For those few domains with genuinely infinite demand — designing and training LLMs, perhaps — specialization holds. For the vast majority of software engineers, radical broadening is already necessary.

Perhaps, you don't like the term "generalist"? Call it broad specialist. The label doesn't matter. What matters is: does your organization allow it?

We're entering a world where makers can finally be complete. The question is whether your org will let them — or keep slicing the work into pieces no one person is allowed to finish. You can hear the same tension in why roles built on artificial scarcity are getting squeezed.