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.
> 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.
I have seen this at a company I've worked at that experienced rapid growth. The strategy they employed was Split and Absorb: first they substantially increased the size of middle management such that the manager-to-IC ratio was something like 2:1. Next each manager was given the ability to Absorb, and they had a lot of time available to them for hiring and onboarding due to the fact that they were managing maybe 3 people each.
In practice I saw this start to fail almost immediately for multiple reasons. First, there began to be a cultural divide between the people who were hired organically (who were typically at the bottom of the ladder) and middle management (who were typically friends from previous jobs). There were communication breakdowns as more management discussions were being done in private channels between friends instead of with the teams. Lastly it was hard for people at the bottom to bring up concerns; even if every IC on a team agreed a problem needed to be solved, there were only 2 of you, but your manager would discuss it with their 10 friends and that made it hard for the people at the bottom to have their perspective heard in an equal light.
> It takes some work to break up those cliques and fold them back in.
How do you actually do this? Who at a company should be taking these steps?
In theory I'm not exactly sure where it went wrong. If you're going huge amounts of time without any applicants then you can't avoid bringing in referrals, and management might even prefer for their friends to be brought into management roles due to alignment in values and culture. For the clique problem, I'm not entirely sure what an organization can do to avoid that. It's unrealistic in my opinion to assume referrals will always stay objective about everything that involves their friends, and if management has this problem then who are the Watchmen who will address that problem?
I'm not a religious person, but the phrase "the devil makes work for idle hands" seems to apply. If you give teams extra time, less than desirable behavior ensues.
> 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.
Also if the team is split over timezones and management are only in one of those zones. I've seen members of a remote team get none of the praise nor promotion while a loud person in the right office makes it their business to sell their own brand, and gets promoted continually. I've seen that person get promoted into management, and completely fail to grow the careers of their team members to the point where those team members just leave. From the perspective of higher ups, none of this information makes it out of the team event horizon.
> 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.
I would assume that it is the direct manager of the team that makes that decision or at the very least provides input.
And if you are managing the team and don't know who is accomplishing what, then you are in a whole lot more trouble than just a problem of choosing wrong strategy of splitting the team.
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 :)
> 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.
> 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.
Interesting. As a visible person, I see the opposite of this.
I'm currently in an IC-ish role. In this role, I am the one who speaks most in meetings, most talkative in company chat compared with the rest of my team (they rarely write anything, weeks can go by), and spend more time putting together documentation and reports (even when the whole team is asked to in theory, it seems to fall on me).
This makes me the most visible, but it's having an undesirable effect for me:
I'm highly productive in the sense that I've closed several longstanding issues that were considered hard to solve and lingered for years, and will continue to do that with all major issues in the project. I'm confident it's the right approach, because of the project's history and some consistently missing or broken functionality, that if I didn't do this, the product would be an endless tarpit of not-quite-working enough for end users to actually choose it.
But my way of doing this produces fewer PRs than the rest of my team, noticably so. As a review put it, "their productivity is measured more in quality than quantity". That's because I think hard about what the actual strategic goals are, figure out solutions to problems everyone else seems to consistently skip over even when they are long-term showstoppers, and actually put together a working solution.
Some of these are just clever bugfixes in poorly understood areas. But in other areas you could say I'm re-architecting and developing new techniques, figuring out parts that work well together and how. But I'm definitely not the parochial "architecture astronaught": My hands are dirty with plenty of coding, and to be honest I'm not sure there is another way. In my experience some techniques used have to be demonstrated in working code before people will recognise that they work or that they provide an advantage, e.g. in significant algorithmic complexity, or changing something from taking days to a few minutes, or reducing a terabyte of storage to a hundred gigabytes. Talking about it isn't enough and short write-ups don't convince either. A thorough writeup would be a lot of work itself (eg. like an academic paper is a lot of work), and would be considered a waste of time by others I think, and probably ignored as acedemic papers tend to be anyway. It should be done after, rather than before, a working implementation.
Some things, you can spend weeks talking about and nobody seems to pick up the real point. Or you can ship a surprisingly short PR that makes something work that didn't before, and it's a breakthrough. And management might see it as a mere bugfix, or they might recognise why it took time and is valuable.
It doesn't help that we are all in different timezones; it's fully remote, and the team operates in a very atomised way, hardly talking except in management meetings. I hope to change this eventually but for now I need to work on shipping technical solutions to major areas that I don't think will be solved without me doing so.
I'd love to be do this more collaboratively. But at least for now, my teammates don't seem to have the relevant knowledge and understanding to help effectively with the parts I'm working on, and one doesn't seem to want to be helpful anyway. And, how to say this - they very rarely communicate except to comment on PRs and in management-led meetings. One set up this obstacle a month after I joined: "You can't expect a new person to know what needs doing on a project" (that means me), they want tasks from "people who have worked for years with the project", which makes collaborating in the same areas a real time sink with respect to progress.
So back to the point of gauging who's actually doing the work:
I'm highly productive in one sense: I'm making transformative changes that will help the company and its product achieve their stated goals, and I'd go a little further in this instance and say I don't think they would achieve it without someone on the team taking my approach. That's why I'm doing it. I'm definitely conscientious and working hard. The changes are visible: The effects can be seen and enjoyed as well as making the product more effective.
But in another sense, I'm gauged as not particularly productive for two reasons: I'm most visible (because I talk in meetings, etc.), and I ship fewer PRs than others on the team.
My teammates ship something more often. It's good that they do, as to be honest one of them often appears not to understand the context of the component they are working on (from basic questions in management meetings), but gives a good story of working hard and shipping something. Their work isn't wasted, it will eventually be used, but someone will still have to develop it further to use it.
It's interesting to see that by me being more visible in explaining what I'm working on and why, there ends up being more attention on basic metrics of my output in management meetings. More time is spent by management asking why I haven't produced X and Y, and that I "need" to ship PRs more often (I'm struggling to figure out how to do this effectively given what I'm working on, though). In the same meetings when my teammates also haven't shipped anything, this doesn't seem to get much attention. I imagine this is almost entirely due to my talks setting high expectations, and the management's idea of what they are looking to see.
Politically I think I'd be more secure just staying quiet, and churning out more basic bugfixes and minor features, knowing that the project is kind of doomed due to key unsolved technical issues, instead of dealing with those issues and explaining how the solutions work.
So who "doing the work"? I think it depends on what you decide productive means. I think it's valid to decide that I'm not productive from a certain point of view, but it's also valid to decide that I'm highly productive from another point of view. My own take on it is I'm doing the right thing for the company and the project, specifically in terms of management's stated goals for the project, but that it's not well understood or particularly visible to others at this point in the trajectory which means I'm taking a personal risk doing so. (I don't think it's much of a project risk (except for bus factor). And if our team wasn't so atomised, or if we had similar knowledge and understanding, there wouldn't be the bus factor either, but we have what we have and changing it will have to wait.)
I feel this. It is hard to be a quality-first person because the same kinds of coworkers and situations that create those thorny issues can’t recognize good solutions. Even a manager who is like you has to rely on your word and that can be hard to do proactively over long periods of time.
A frank conversation and/or a job search might be in order.
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.
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.
(disclaimer: I've never ran I company myself, but have been part of numerous teams and experienced some growth pain; so the following is my [sort of] one-sided view of the picture)
That's a pet peeve of mine. Adding more people feels more like a company "ego" inflation injected by VCs so they "look good" and valuation goes up. External pressure. It can make good ideas and teams de-rail fast… processes will be introduced, knowledge silos will emerge (because how else would you justify your job in 6 months?), great people will leave because what they don't feel connected anymore. And you rarely observe this in bootstrapped companies.
There's this false pretense that adding more people will yield more "product". And that we need 1 person for infra, 1 person for backend, 1 person for web front-end, 1 person for iOS mobile, 1 person for android mobile, 1 person for… Outsiders only see these "labels" and head counts.
Growth != more people.
(ps. sorry if this looks unfinished and rant-y; I'm not exactly in a good mental space and needed to vent out a bit…)
I think you've conflated the success/ROI of the business with the need to hire more people.
Success is not guaranteed, no matter how impressed we are with an idea or how proud we are of its execution. A leadership team over a long enough period of time running the business and constantly looking at "the numbers" will develop some intuition of how to steer the ship. They'll make plans for what they think they need to do to increase the chances of success, with concrete facts and trends or just good storytelling. There's no magic bullet.
Your company may be mature enough that it has steady revenue so you need to protect that part of the business, because it's not fun to explain to investors that revenue is down because you pulled employees off known-revenue generating projects to do projects that may or may not move the needle. You need to be mindful that there will be future fundraising rounds, and you want existing investors to join them.
So you have to hire. You need to spend money to tackle new projects, to increase your chances of success, without impacting the existing success you've had and adding headcount is much cheaper/less risky than rocking the boat on existing projects or not tackling the new things.
But no plan is perfect, and even experienced leaders will make mistakes that will have negative consequences within the organization.
I agree with you tomnipotent. Growth is not equal to more people. We all know that WhatsApp before taken by facebook has only 65 quality people team as compared to big giant companies having thousands of employee with same value.
But in some cases, even without pulling people out of the team, growth is impacted by other factors e.g. competition. How to avoid such factors is definitely a challenge.
The very nature of exogenous factors is that we can only react to/worry about them.
When all is said and done, my board is going to ask me what I did "about it" which is an implicit invitation for me to explain why they should be confident in how I'm spending their money. If the numbers don't look good or good enough, I need to tell them what I'm doing to change that. That manifests as some slides in a board deck explaining projects, impacts, deadlines, and headcount. Maybe an org chart. Financial projections.
One investor will ask me if I really need those people. Another will ask how adding those people will affect the delivery schedule. Another will ask if there are any projects we're currently working on that we're maybe not excited about (or they're not) and if we could cut our losses.
Unless our runway is really low and we're uncertain in our confidence to raise another round, the general consensus will be to hire more people and not impact existing projects. Maybe you went expecting to hire 20, but "negotiated" down to 10. Sometimes you go in expecting to hire 20, and the board convinces you to hire 40.
Stepping away to take a walk helps clear the air, gets the blood moving, and changes up the surroundings. It's rarely the full solution, but quite often a good first start. Good luck, and take care.
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.
Creativity generally doesn’t bloom without constraints. If you know you can’t afford to build something bespoke yourself, you have to find a set of tools and needs that are complementary to each other. You have to do it right, because there’s no other option.
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."
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.
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.
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.
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.
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."
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.
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.