3 ms·
This post is interesting only as an example of a total lack of facts, comparisons, and perspective. The lone backing of each opinion is the adverb "generally".
by Noe2097 6y ago
This post is interesting only as an example of a total lack of facts, comparisons, and perspective.
The lone backing of each opinion is the adverb "generally". There is no mention of any concrete team/company size where issues do/might occur in one or the other setup. There is no mention of successful or failing companies adopting one or the other setup.
And just to mention a single concrete counter-example to the groundless side taken here, take Apple. Apple's organization is _based_ on specialization, for the simple reason that the more specialized teams are, the higher their expertise is. Look at Spotify, Microsoft, and others; they moved away from the simplistic feature-squad model advocated here, because it simply didn't scale.
Certainly, communication across team members, and communication across teams are subjects of attention. It does not mean it should be ignored/avoided. It's like saying "scaling horizontally is too difficult, just stick to scaling vertically"; sure, it's easier, but the power is not the same.
- smilliken 6y ago"Generally" is a bit of a cop out without data, but it's not wrong. If you survey companies to understand their organizational structure, you will see the sample dominated by domain-oriented structures (eg product, business unit, etc) as opposed to functionally-oriented structures (eg skills). The example you mention (Apple) is a notable one precisely because it's an outlier in this respect. It is interesting! In particular, I understand than iPhone, iPad, and Mac are built by the same people, not split across separate teams. Even then, Apple still has lots of typical domain-oriented structure. Of the 10 or so people I'vd known to work there, all of them have been in product-oriented teams.
- coderintherye 6y agoWhile I generally agree with the author's thesis based on my own experience leading engineering teams, I also agree with your view point that the author provides no facts to back it up, not even examples of teams he has worked on. This makes his opinions somewhat circumspect. For an example of research-based conclusions about teams, Google's write-ups are illustrative: https://rework.withgoogle.com/print/guides/5721312655835136/ https://rework.withgoogle.com/print/guides/5721312655835136/ In general, I think Google's research captures something that the author of this post fails to take into account fully, which is that psychological safety of the team members matters is a key indicator towards effectiveness.