The industry has spent fifteen years turning engineers into the narrowest kind of specialist. Not the old kind, the one who still understood how a system breathed end to end. The new kind: a person who owns one slice of one service, in one language, under one framework. Their calendar is full of tickets that never leave that slice. Their review is measured in velocity inside that slice. Their career path is "senior [that slice] engineer."
They sell this as efficiency. It is actually a slow form of deskilling.
What narrow roles actually look like
Look inside most large tech companies. A frontend engineer who has never touched the data model. A backend engineer who treats the UI as someone else's problem. A platform engineer who never ships a feature a user can feel. An ML engineer who has never debugged a production outage that wasn't caused by the model. A "fullstack" title that, in practice, means React plus whatever thin backend the framework already gives you.
The org chart is a map of dependencies, and every dependency is someone else's job. The system works until it doesn't. And when it doesn't, the only people who can see the whole picture are the ones who refused to stay in their lane.
The cost shows up the day someone leaves
Spend five years writing only GraphQL resolvers, or only React components, or only Kubernetes manifests, and you do not suddenly become able to build something from nothing. You become someone who needs the same scaffolding, the same adjacent specialists, the same process that held you up before. Without continuous, deliberate learning outside the job, your skill set collapses to the shape of your last role.
That is not a moral failure. It is the predictable result of being paid to stay narrow.
I have watched this repeat. People who were excellent at one tightly scoped thing. People who shipped tickets faster than anyone else in their domain. People who looked senior on paper. Then they sat in interviews, or in new roles, and could not reason about anything outside the walls they had been handed. The muscle of connecting ideas across layers had atrophied. Debugging a full request path felt foreign. Choosing a data structure for a new problem felt like starting over. The confidence that used to come from having built things end to end was gone.
What the opposite looks like
The opposite is not "know everything." That was never possible. The opposite is refusing to let your curiosity, or your competence, stop at the ticket boundary.
A polymath engineer does not claim mastery of every field. They claim the right, and the habit, of crossing between them. They can read a network trace. They can sketch a UI that doesn't fight the data. They can spot a database choice that will hurt the product three years out. And they can still write the code that ships. They keep enough surface area in their head that a new problem doesn't automatically become "not my area." They treat specialization as a temporary focus, not a permanent identity.
This is harder. It is slower in the short term. It produces less of the metrics big companies reward. It also produces people who can still function when the org chart, the framework, the cloud provider, or the whole stack changes. And that is the only condition that actually lasts.
The people who prove it
Claude Shannon. A mathematician and electrical engineer who, in his twenties, noticed that the switches in a telephone circuit and the symbols in Boolean logic were the same thing, and turned that one observation into the foundation of the digital age. He then wrote the paper that created information theory, built chess-playing and maze-solving machines, juggled, and rode a unicycle around Bell Labs. None of those were separate hobbies. They were one habit: never stopping at the boundary of his own field.
Grace Hopper. A math professor who joined the Navy, learned to program one of the first computers, and grew so frustrated with rewriting the same machine instructions that she built the first compiler. The idea that people should talk to machines in something closer to English came from crossing math, hardware, and a deep impatience with tedium. No single one of those would have produced COBOL.
John Carmack. He wrote game engines down to the metal, then spent years building rockets at Armadillo Aerospace. The same instinct drove both: understand the whole machine, from the physics to the pixels, and refuse to leave any layer to "someone else."
Leslie Lamport. A mathematician who worked at a chip company, then gave distributed systems the consensus algorithm the whole internet still leans on, then went and wrote LaTeX because he was annoyed with how papers looked. The breadth was not a detour from his best work. It was the route to it.
Steve Wozniak. He designed the Apple I and the Apple II alone, hardware and software, board and code, because he could hold the whole machine in his head. That is not a story about genius as much as it is a story about range. He could see the whole system, so he could make the whole thing coherent.
None of these people were generalists who knew a little about everything. They were people who knew their field deeply and refused to let that depth become a fence.
Why this is not a luxury
People talk about breadth as if it were a nice-to-have, something you get around to after you have optimized for the current stack. But the current stack is the least durable thing about your career. jQuery. Angular 1. Backbone. The framework you are an expert in today will be legacy in five years, and the next job posting will want the thing after it. The engineers who survive those shifts are rarely the ones who knew the old framework deepest. They are the ones who knew what the framework was built on, and could carry that underneath to the next thing.
Depth in a tool decays. Depth in how systems work compounds.
The usual objections, and why they fall
"Depth requires specialization." Depth requires sustained attention, not permanent isolation. The people who do the deepest work in any technical field almost always have wider foundations than the ones who stayed in one box. The box is a management convenience, not a cognitive requirement.
"Modern systems are too large for one person to understand." Systems are large. Understanding doesn't mean knowing every line. It means knowing how the pieces relate, where the sharp edges are, and how a change in one place lands somewhere else. That relational map is exactly what narrow roles destroy.
"The market rewards specialists." The market rewards the appearance of specialization on a résumé. The people who keep getting hired for hard problems, who start things that survive, who are still useful after the current stack dies, are usually the ones who refused to stay narrow. The résumé lags. Reality doesn't.
"You can always learn later." Later rarely arrives for free. The longer you stay inside one silo, the more expensive the climb out becomes. The paths in your head that make new domains feel approachable atrophy the same way any unused skill does. The people who say "I'll broaden out after this role" usually don't. The role never ends, and the habits harden.
The quieter cost
There is a cost that is harder to measure. Narrow roles train people to wait for permission to think. The ticket arrives with the boundaries already drawn. Crossing them feels like overstepping. After a few years of that, the instinct to own a problem end to end starts to feel foreign.
That is not a technical limitation. It is a learned limitation of agency.
What I am actually saying
I am not arguing against expertise. I am arguing against the idea that expertise must be bought by amputating everything else. The best engineers I know are not the ones who went deepest into the smallest hole. They are the ones who kept enough range to still see the shape of the whole system, still learn a new layer when it mattered, and still build something coherent when the supporting cast was gone.
Big tech and large companies optimized for throughput and headcount efficiency. They got what they optimized for: people who move tickets quickly inside a narrow lane. What they did not optimize for is the capacity to invent, to diagnose across boundaries, or to stay useful when the lane itself disappears.
That capacity is still available. It just requires treating the job description as a temporary contract with the current work, not a definition of who you are allowed to become. Keep learning outside the ticket. Keep touching the adjacent layers. Keep asking how the whole thing actually works.
Otherwise the specialization that feels like safety becomes a trap with a very short half-life.