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.<p>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.<p>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.<p>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.<p>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.
I've worked at both small and large companies in periods of rapid growth.<p>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.<p>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.
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."
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.
"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."<p>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.<p>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.