Live data from Hacker News

The magic of small engineering teams

newsletter.posthog.com

11–20 of 44 posts

Re: The magic of small engineering teams

#11

> 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 team…

[dead]

Re: The magic of small engineering teams

#12

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…

> selling to developers is really hard.

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.

Re: The magic of small engineering teams

#13

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…

> selling to developers is really hard. 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.

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.

Re: The magic of small engineering teams

#14

> 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 team…

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.)

[deleted]

Re: The magic of small engineering teams

#16

> 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 team…

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).

Re: The magic of small engineering teams

#17

> 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 team…

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.

Re: The magic of small engineering teams

#19
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.
Post reply on HN