I tend to agree with you.  I think back through a decade of coworkers, and when I take your &quot;A-Team&quot; approach I find myself picking &quot;The Sysadmin&quot; and &quot;The UX guy&quot; etc.  And when I ask myself how they stand up against even the best generalists I met at big5 companies, well, it&#x27;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)<p>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.<p>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&#x27;ve worked for; &quot;are we communicating well internally in general&quot;.<p>(To bring this back to the article as well, I&#x27;ve also found the specialist groups with &quot;eigenvectors&quot; of skills to be MORE cohesive, as it&#x27;s a great trust builder when someone can say &quot;I&#x27;ll be supporting your work in Y with X&quot; and you know that they&#x27;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&#x27;t very feasible in other environments, but that&#x27;s an &quot;easy way in&quot; to trust.)