3 ms·

IMO and experience, the best way to build a team is to exploit comparative advantage so that the whole is stronger than any of its parts. Assuming you've avoid

by varelse 11y ago

IMO and experience, the best way to build a team is to exploit comparative advantage so that the whole is stronger than any of its parts. Assuming you've avoided hiring a sociopath, group cohesion follows from everyone having a critical skill they bring to the project uniquely. This is of course 100% anecdotal. This of course runs 180 degrees against the concept of fungible engineering and Google's generalist fetish. Or TLDR: I prefer building the A-Team instead of trying to be Agile.

existencebox 11y ago
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.)
elliotec 11y ago
Teams in general should always be made up of specialists. Thats the point of teams, to have collaboration between people that know specifics of certain things. Teams of generalists will just be a bunch of people that are ok at a bunch of different stuff and will either end up specializing in one thing anyway, or just being mediocre at everything and bumping into each other. One-man bands are a different story though, if a full engineering team is not feasible, a generalist who has a broad but shallow knowledge of lots of things is far preferable to a specialist of one.
spacecowboy_lon 11y ago
And not using stack ranking which damages team cohesion if you are being ranked with your peers.

by varelse 11y ago

existencebox 11y ago

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.)

elliotec 11y ago

Teams in general should always be made up of specialists. Thats the point of teams, to have collaboration between people that know specifics of certain things. Teams of generalists will just be a bunch of people that are ok at a bunch of different stuff and will either end up specializing in one thing anyway, or just being mediocre at everything and bumping into each other. One-man bands are a different story though, if a full engineering team is not feasible, a generalist who has a broad but shallow knowledge of lots of things is far preferable to a specialist of one.

spacecowboy_lon 11y ago

And not using stack ranking which damages team cohesion if you are being ranked with your peers.