[HN Gopher] Why it's difficult to build teams in high growth org...
       ___________________________________________________________________
        
       Why it's difficult to build teams in high growth organisations
        
       Author : absolute100
       Score  : 30 points
       Date   : 2021-08-19 20:12 UTC (2 hours ago)
        
 (HTM) web link (jchyip.medium.com)
 (TXT) w3m dump (jchyip.medium.com)
        
       | m0llusk wrote:
       | Moving fast breaks things.
        
       | absolute100 wrote:
       | Jason Yip shares his observations for scaling software teams
       | during hyper growth (and what not to do). I liked his insight on
       | group structure alignment with the stability of the group's
       | strategy: "Structure should be stable where strategy is stable;
       | structure should be flexible where strategy is volatile. For
       | example, if a broader department-level product strategy is stable
       | while more local tactics are volatile, you should want the
       | structure and shared identity of the department to be stronger
       | and more stable than team-level structures and identities."
        
         | jasonpeacock wrote:
         | So...Conway's Law :)
         | 
         | https://en.wikipedia.org/wiki/Conway%27s_law
         | 
         | There is also the "reverse-Conway maneuver": Structure the org
         | to produce the results you want.
        
           | msandford wrote:
           | I love the idea of the reverse Conway maneuver. Thanks for
           | that. Obvious in hindsight.
        
       | nick0garvey wrote:
       | I've worked at both small and large companies in periods of rapid
       | growth.
       | 
       | With 2x YoY growth you are always onboarding. You need to be
       | multiplicative with your onboarding efforts. This means writing
       | quality onboarding documentation, mentoring mentors, and
       | codifying parts of the onboarding process (e.g. groups to join,
       | permissions, etc.). Making other engineers effective is a very
       | valuable use of time when so many people are ramping up at once.
       | 
       | It can feel exhausting, but mostly invigorating. There's always a
       | feeling of energy; the hardest part can be setting boundaries to
       | not let it consume your free time.
        
         | tibiahurried wrote:
         | There is also the fake "high growth". I worked at startup where
         | the CEO was growing the organization like crazy, just for the
         | sake of showing that the company was growing, even though it
         | was not. We were on-boarding engineers almost every day and did
         | not have any work for them to do.
         | 
         | I am talking like teams of more than 10 engineers that took
         | months to deliver simple features. Most of the engineers were
         | spending their time fighting their IDE, local setup and finding
         | a purpose.
         | 
         | Best project I worked on, it was in a team of 3 people: manager
         | + 2 engineers. I built the whole backend and the other gui the
         | frontend stuff. Worked like a charm! We delivered on time and
         | things just worked.
         | 
         | Sometime, less is better.
        
           | zemvpferreira wrote:
           | Instagram was 13 people when Facebook acquired it for roughly
           | 1 billion dollars. It had 30 million users.
           | 
           | Plenty of us have excuses for why our companies are not worth
           | 76 million dollars per employee. Some of us don't even try.
           | The point is you're right: It doesn't take a lot of people to
           | create extraordinary value.
        
         | jasonpeacock wrote:
         | The hardest is part is keeping all the onboarding tools, docs,
         | etc updated as the product, infrastructure, and process
         | changes.
         | 
         | You really need a full-time "onboarding" engineer, or make a
         | rotation for everyone to dogfood the onboarding process and
         | update it.
         | 
         | Otherwise it falls on the new person to update the process,
         | which is both education and frustrating, depending on how busy
         | the rest of the teams are.
        
       ___________________________________________________________________
       (page generated 2021-08-19 23:00 UTC)