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