> Startups ship more per person than big companies – everyone knows this
The post starts out by assuming this but I am not convinced this is true along the entire graph, if the x axis is amount of people on a team and the y axis is amount "shipped". As a company scales output, at some point in this graph the output per person from the large team should overtake the small team, otherwise why do we even have large teams in the first place? How do large teams form if not from necessity? Seems they are advocating for small one pizza teams working together in tandem at scale? Because that's essentially the way I've seen it done everywhere I've ever worked and it isn't a new idea, and what you have at the end of that is a larger unit that definitely constitutes a "department" and a "large team" even if the large team consists of several small teams. The communication overhead there can get extremely complex as well.
Companies increase team size because they want to increase overall output, not per-person output. Even if 20 people produce half as much per person as 5 people, they’re still getting twice as much done.
(The other answers take a cynical “managers suck!” stance, which isn’t entirely wrong, but it’s not the main reason. Companies mainly add people because they want more output, simple as that.)
Could it also be the case that some people just aren’t suited for small teams?
I don’t have any experience actually handling this sort of thing, so here’s some rampant speculation instead:
A small team of motivated rockstars might be the fastest way to solve a problem. But, there are a lot of non-rockstars out there. Maybe marshaling up a little talent from a lot of people is more feasible for some organizations/problems (in particular some types of problems might be boring, and not attractive to a team of rockstars).
I find that pretty much all managers balk at the idea of paying someone more than they get paid, but are happy for total payroll to be stratospheric. Until we deal with this mental illness we will always have expensive shit software written by huge teams.
Yeah. Increases in team size typically mean an increase in specialization and a decrease in productivity because of the larger amount of communication that must be done to keep everyone moving in the same direction.
I was responsible for a lot more at a small company, and I only had to convince one other person if I wanted to do something within my corner. At a large company, I may have to convince representatives from teams representing > 100 people.
That takes time.
But as an organization, we can solve problems that weren't possible to solve at the small company due to lack of resources and lack of people who could sit heads down and work on a problem for 6 months due to their other responsibilities.
Not sure if there's some Parkinson or Murphy's law, but every manager complains about too little headcount.
Also count of people reporting to you (directly or indirectly) is one of the measures of success for managers.
Large teams are a non-monetary bonus/incentive for the managerial class. At a manager's prospective employer they'll be asked for and judged by their headcount, much like engineers are asked for their previous salary.
Large teams don't cause success. They require success to sustain their bloat.
In 2020, I interviewed at Google. One of the screening questions was my current team size. I had no idea (but had a system where I could look it up). I was under by a little more than a factor of 2, because I don’t care about my team size as a vanity metric, but I can confirm that recruiters are very interested in it.
It's selection bias. This person is only considering successful startups and comparing them to big companies, not the huge number of startups that fail before they ever manage to ship anything.
It may also depend on the kind of thing that's being shipped. Want to ship something large and monolithic? Want it quick? You need a big team.
If your product can be modularized into small problems/features/projects that are one- or two-pizza sized, and the abstraction overhead to connect pieces together is low enough, then yeah, small teams make more sense.
I suppose the real question is whether the cost of splitting big problems into small ones is worth the productivity bonus of working on those small problems.
>As a company scales output, at some point in this graph the output per person from the large team should overtake the small team, otherwise why do we even have large teams in the first place?
Asymptotic growth. The net contribution of each new member approaches zero but never quite reaches it. For any small team a larger team can out produce them because they throw more bodies at the problem.
>>> We prefer goals orientated around what teams will ship, rather than more abstract goals like "increase conversions by 10%".
This is … interesting. I can hear every scrum master course leader crying but I like it.
On the other hand, measuring impact in the real world is a vital task - but yeah it’s a lot easier to say “Inwill build a car” than “I will drive the user to a football game once I have built a car”
>I can hear every scrum master course leader crying but I like it.
This is a feature not a bug. Small teams don't need a leader just like how small bands don't need a conductor. If you want to add admin give them a secretary so they don't waste their time on administrivia.
Obviously "improve X metric" is not a plan, but without any key results to evaluate against, it's easy for things to be "done" poorly or to not be targeted at something that matters, particularly as orgs get larger.
They do say that teams have long term objectives and metrics, so maybe those are what is used for evaluation, but it definitely feels weird.
It depends who is calling the shots on what to build. If it's the business or a product manager, then some engineer is going to be rewarded or punished for the impact (or lack thereof) that is already locked in, and all that's left is politicking about who it's going to be.
In this case they're pretty clear that the teams are supposed to have complete ownership of product chunks, so it does feel a bit odd that they're accountable for delivering and not for outcomes.
I find Posthog interesting because it launched around the same time (2020ish) as Stan.Store.
Not Posthog is a technically much more challenging product and is more geared towards developers and yet in terms of ARR it is at 10 million whereas Stan.Store which is basically link in bio + a very basic store is doing 25 million ARR.
Goes to show, selling to developers is really hard. Hopefully Posthog makes it in the long term, but graphing time spent vs returns, something like Stan.Store will make the founder + investors a lot more money in a shorter time period.
Cynical take: Selling software to developers is hard partly because the customer is more likely to notice when the product functionality (as opposed to marketing) doesn't really do what they need.
There's a danger as well. Small teams become very tribal, and once they're trapped down a rabbit hole of bad abstractions and local maxima, can be very hard to coax out of.
I started out firmly against large companies. My ideal team is 10-20 engineers, in person, hyper focused and all on the same page with mutual respect. Minimal or no product manager types.
But I’m also sick of hearing how these teams can “ship” so fast. Yeah you can ship, you have no customers. No users, no SLAs, no employees. Good work, you just did whatever you wanted and then typed “git push” to a repo you control, with standards you control, and a build process you control. Wow those stodgy big co’s could learn something from you!
This is a similar convo to “why use Kubernetes”. Do you have one binary and one database with one password? Go nuts with your single VPS and bash scripts and keep telling yourself that everyone is over complicating it. But are you scaling? You’ll probably need some orchestration. You’ll probably need some managers, a ticket system, on-call, standard build tools. Documentation.
Scaling to billions with a team of 20 is a fantasy achieved only by the select few. As always it is a fine line companies should tread lightly. Don’t rush to hire, but don’t be afraid of it either. Focus on scaling intentionally and carefully.
This is _not_ a small team. This is the size of a team that can serve the world, see whatsapp. A small team is >5 engineers working on a well defined business task, like writing Unix.
A small team is more like 3 to 6 people, focused on building. Your manager is also an IC and probably a cofounder of the company. 10-20 is in the range where you need some more coordination and processes.
15 teams means 15 first-line managers, 5 second-line managers, 2 directors, and 1 VP (I am assuming the manager teams have the same rule of 3/team). In total 23 managers for 47 people.
Do they actually have 15 dedicated first line managers? For a team of 3 people you can definitely get away with a TL who spends most of their time coding.
I think they will eventually find that having a huge number of tiny teams will result in silos, replicated work, and massive inefficiency as they try to scale up. This averages out as 15 3 man teams. Yikes.
This is a case of managing technology teams with the mindset of a product manager. It can also be said that it is an effort to find a solution to a problem that does not exist. I prefer 2 teams that work much more dynamically to 18 teams dealing with a very small region.
The post starts out by assuming this but I am not convinced this is true along the entire graph, if the x axis is amount of people on a team and the y axis is amount "shipped". As a company scales output, at some point in this graph the output per person from the large team should overtake the small team, otherwise why do we even have large teams in the first place? How do large teams form if not from necessity? Seems they are advocating for small one pizza teams working together in tandem at scale? Because that's essentially the way I've seen it done everywhere I've ever worked and it isn't a new idea, and what you have at the end of that is a larger unit that definitely constitutes a "department" and a "large team" even if the large team consists of several small teams. The communication overhead there can get extremely complex as well.