The magic of small engineering teams
newsletter.posthog.com
newsletter.posthog.com
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.
> How do large teams form if not from necessity?
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.
sure, but isn’t this OP making a direct comparison?
Large teams don't cause success. They require success to sustain their bloat.
(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.)
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.
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.
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.
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.
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”
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.
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.
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.
Yes, software wise, we either take open source stuff or write our own stuff.
There are just very little in between that can be monetized.. unless it bundles with hardware like ChatGPT.
https://news.ycombinator.com/item?id=40873471 (151 comments)
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.
Yet the image has 6 gophers.