[HN Gopher] Designing Engineering Organizations ___________________________________________________________________ Designing Engineering Organizations Author : dochtman Score : 46 points Date : 2021-01-05 18:36 UTC (1 days ago) (HTM) web link (jacobian.org) (TXT) w3m dump (jacobian.org) | ramenmeal wrote: | I assume this is based purely from his experience. I wonder how | much research has been done on this. Surely Microsoft has tried | to do some studies on it? | lrossi wrote: | > My experience is that it takes at least 6 months to reach the | "performing" level, and sometimes much more. If staff switch | teams more often than that, teams never reach their full | potential. | | On one hand, I agree with this, as I have been moved quickly | between projects in the past, when I was more needed elsewhere. | It helped to keep things interesting but I would have liked more | stability. | | On the other hand, there is a risk that people get stuck in one | place for a while with no mobility, working on something they | don't like. I have seen this as well. Good people weren't allowed | to move, so they quit. As the team was shrinking, the others had | to stay. Needless to say that morale was poor. | | There is a fine line between the two. | Noe2097 wrote: | 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. | jasonpeacock wrote: | Team Topologies[0] goes into more depth about this topic, it's a | good read. | | [0] https://smile.amazon.com/gp/product/1942788819 ___________________________________________________________________ (page generated 2021-01-06 23:00 UTC)