I tend to agree with you. I think back through a decade of coworkers, and when I take your "A-Team" approach I find myself picking "The Sysadmin" and "The UX g

I tend to agree with you. I think back through a decade of coworkers, and when I take your "A-Team" approach I find myself picking "The Sysadmin" and "The UX guy" etc. And when I ask myself how they stand up against even the best generalists I met at big5 companies, well, it's no competition. (In that the specialists wipe the floor with the generalists, and I say this as someone who has followed more of the generalist route) There is fundamentally too little time in the day, and too much to know to truly be GREAT in a domain, to expect anyone outside a select few (certainly not enough to fill out general employment at google) to be able to bridge these domains meaningfully and still be as deep as possible. Now; there is a massive benefit to the specialists having sufficient understanding to communicate with other domains. But this to me is not what being a generalist means, and is an asset that is often looked over even in the generalist-focused agile orgs I've worked for; "are we communicating well internally in general". (To bring this back to the article as well, I've also found the specialist groups with "eigenvectors" of skills to be MORE cohesive, as it's a great trust builder when someone can say "I'll be supporting your work in Y with X" and you know that they'll be doing X _light years_ better than you could, and you can truly TRUST them to have your back. Not that the same thing isn't very feasible in other environments, but that's an "easy way in" to trust.)