7 ms·

Why it’s difficult to build teams in high growth organisations

176 points by absolute100 5y ago

absolute100 5y ago
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 5y ago
  So...Conway's Law :) https://en.wikipedia.org/wiki/Conway%27s_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 5y ago
    I love the idea of the reverse Conway maneuver. Thanks for that. Obvious in hindsight.
  - hinkley 5y ago
    I haven’t gotten to use it much, but it does seem to work for network services as well. But then it’s a fine line between reverse Conway and Gandhi (be the change). You can stand up a sane thing that you enjoy interacting with and then maneuver to have the org and systems match that new structure.
  - muzani 5y ago
    IMO you should always engineer the organization chart before the architecture. If a major goal is to sell ads, that should reflect in both org and tech.
  - jameshart 5y ago
    But there's also a danger: if the only tool leadership can think of to affect how things get done is to redraw the org chart, you get management-through-reverse-Conway. There are other ways to tell people how to behave than shifting their reporting lines, but some leaders haven't heard of them.
    - disgruntledphd2 5y ago
      Yeah, completely agreed. I actually like the strategy outlined in the OP (Absorb and Split). When this has happened, it's always lead to a much better outcome than when you start splitting and creating teams prematurely.
nick0garvey 5y ago
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.
- jasonpeacock 5y ago
  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.
- tibiahurried 5y ago
  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 guy the frontend stuff. Worked like a charm! We delivered on time and things just worked. Sometime, less is better.
  - zemvpferreira 5y ago
    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.
m0llusk 5y ago
Moving fast breaks things.
PragmaticPulp 5y ago
The "absorb and split" pattern recommended by the author (basically: add people to a team, observe who naturally works with each other, split team along natural cohesiveness) works if, and only if, the person assigning the teams can accurately gauge who's actually doing the work. It sounds easy, but evaluating who's doing the work and who they're working with can actually be extremely challenging unless you're embedded with the team. It's too easy to misjudge who's accomplishing what if your only input is observing who speaks up the most in meetings, who's the most talkative in Slack, or who spends the most time putting together presentations. Visibility metrics don't always correlate well to actual productivity. This method also has a high risk of rewarding people for excluding others. Prefer to work with your old friend instead of the actual lead? No problem, just exclude them from your communications and eventually leadership will split that person out of your team. This becomes very problematic when hypergrowth companies are desperate to recruit so they start hiring friends of current employees via referral. When you hire groups of people who have a history together, they tend to stick together in the new org and resist integrating into the company culture. They want to isolate themselves and operate like they did a few years back at a previous company. You end up with a lot of pockets of people trying to operate as independent teams with their own work culture. It takes some work to break up those cliques and fold them back in. All in all, I think the absorb and split pattern in this blog can be good, but you need to watch out for cliques and focus on actual productivity, not just visibility competitions.
- soared 5y ago
  Two friends and I just got hired together at a new company. We’re in the same geo while the rest of the team is remote, and the bulk of the company is not in the us. You’re second paragraph is very true! If I’m new and notice an odd workflow I would normally just adjust, but now I can go into our slack group and commiserate with my friends. It doesn’t help that most of the company is Polish and their culture comes off as very rude to Americans :)
  - stavros 5y ago
    > It doesn’t help that most of the company is Polish and their culture comes off as very rude to Americans :) I've always worked with Americans, and they struck me as very sensitive, whereas we tend to be much more direct. I adapted, and then I worked with Canadians, to whom my American style was seen as boorishly coarse.
lookalike74 5y ago
This was an issue for both of the medical startups I've worked for. The first was started by a physician who kept trying to be physician and tech CEO all at once, and the current one has as almost as many executives as 'others' and with high turnover on the 'others.' I stay so busy filling gaps, training, and taking over half-done shit, the work I was hired to do isn't even what I spend most of my time on.
amznbyebyebye 5y ago
Politics
- nlitened 5y ago
  I think "politics" is "communication in a group of more than 20 people".
deleted 5y ago
[deleted]
chiefalchemist 5y ago
"The newbies outnumber the veterans in high growth. Default culture is not what pre-exists but whatever new people bring with them. Even with careful selection, it’s unlikely that cultural assumptions match up perfectly." Default culture? Sure. But the "creation" of default culture is what curated culture is not. The former is an accident, the latter intentional. To expect optimal with little or no effort is simply a rookie mistake. People are hard. Culture is hard. Both are harder than technology. Technology is relatively easy; people - whether team or marketing to customers - is hard. Unfortunately, many see it the other way around, and that's a mistake. That false assumption makes growth less likely, and stagnation more likely.

176 points by absolute100 5y ago

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 5y ago
So...Conway's Law :) https://en.wikipedia.org/wiki/Conway%27s_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 5y ago
  I love the idea of the reverse Conway maneuver. Thanks for that. Obvious in hindsight.
- hinkley 5y ago
  I haven’t gotten to use it much, but it does seem to work for network services as well. But then it’s a fine line between reverse Conway and Gandhi (be the change). You can stand up a sane thing that you enjoy interacting with and then maneuver to have the org and systems match that new structure.
- muzani 5y ago
  IMO you should always engineer the organization chart before the architecture. If a major goal is to sell ads, that should reflect in both org and tech.
- jameshart 5y ago
  But there's also a danger: if the only tool leadership can think of to affect how things get done is to redraw the org chart, you get management-through-reverse-Conway. There are other ways to tell people how to behave than shifting their reporting lines, but some leaders haven't heard of them.
  - disgruntledphd2 5y ago
    Yeah, completely agreed. I actually like the strategy outlined in the OP (Absorb and Split). When this has happened, it's always lead to a much better outcome than when you start splitting and creating teams prematurely.

nick0garvey 5y ago

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.

jasonpeacock 5y ago
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.
tibiahurried 5y ago
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 guy the frontend stuff. Worked like a charm! We delivered on time and things just worked. Sometime, less is better.
- zemvpferreira 5y ago
  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.

m0llusk 5y ago

Moving fast breaks things.

PragmaticPulp 5y ago

The "absorb and split" pattern recommended by the author (basically: add people to a team, observe who naturally works with each other, split team along natural cohesiveness) works if, and only if, the person assigning the teams can accurately gauge who's actually doing the work. It sounds easy, but evaluating who's doing the work and who they're working with can actually be extremely challenging unless you're embedded with the team. It's too easy to misjudge who's accomplishing what if your only input is observing who speaks up the most in meetings, who's the most talkative in Slack, or who spends the most time putting together presentations. Visibility metrics don't always correlate well to actual productivity. This method also has a high risk of rewarding people for excluding others. Prefer to work with your old friend instead of the actual lead? No problem, just exclude them from your communications and eventually leadership will split that person out of your team. This becomes very problematic when hypergrowth companies are desperate to recruit so they start hiring friends of current employees via referral. When you hire groups of people who have a history together, they tend to stick together in the new org and resist integrating into the company culture. They want to isolate themselves and operate like they did a few years back at a previous company. You end up with a lot of pockets of people trying to operate as independent teams with their own work culture. It takes some work to break up those cliques and fold them back in. All in all, I think the absorb and split pattern in this blog can be good, but you need to watch out for cliques and focus on actual productivity, not just visibility competitions.

soared 5y ago
Two friends and I just got hired together at a new company. We’re in the same geo while the rest of the team is remote, and the bulk of the company is not in the us. You’re second paragraph is very true! If I’m new and notice an odd workflow I would normally just adjust, but now I can go into our slack group and commiserate with my friends. It doesn’t help that most of the company is Polish and their culture comes off as very rude to Americans :)
- stavros 5y ago
  > It doesn’t help that most of the company is Polish and their culture comes off as very rude to Americans :) I've always worked with Americans, and they struck me as very sensitive, whereas we tend to be much more direct. I adapted, and then I worked with Canadians, to whom my American style was seen as boorishly coarse.

lookalike74 5y ago

This was an issue for both of the medical startups I've worked for. The first was started by a physician who kept trying to be physician and tech CEO all at once, and the current one has as almost as many executives as 'others' and with high turnover on the 'others.' I stay so busy filling gaps, training, and taking over half-done shit, the work I was hired to do isn't even what I spend most of my time on.

amznbyebyebye 5y ago

Politics

nlitened 5y ago
I think "politics" is "communication in a group of more than 20 people".

deleted 5y ago

[deleted]

chiefalchemist 5y ago

"The newbies outnumber the veterans in high growth. Default culture is not what pre-exists but whatever new people bring with them. Even with careful selection, it’s unlikely that cultural assumptions match up perfectly." Default culture? Sure. But the "creation" of default culture is what curated culture is not. The former is an accident, the latter intentional. To expect optimal with little or no effort is simply a rookie mistake. People are hard. Culture is hard. Both are harder than technology. Technology is relatively easy; people - whether team or marketing to customers - is hard. Unfortunately, many see it the other way around, and that's a mistake. That false assumption makes growth less likely, and stagnation more likely.