The magic of small engineering teams • Hacker News Board

Re: The magic of small engineering teams

#41

Post by llm_trw » Thu, Jul 11, 2024, 12:08 AM UTC

JohnMakin wrote: post #2

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

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

Re: The magic of small engineering teams

#42

Post by llm_trw » Thu, Jul 11, 2024, 12:12 AM UTC

bee_rider wrote: post #16

jdlshore wrote: post #10

Earlier quoted context omitted.

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/prob…

Rockstars expect rockstar compensation.

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.

Re: The magic of small engineering teams

#43

Post by lolinder » Thu, Jul 11, 2024, 12:43 AM UTC

closeparen wrote: post #36

Eridrus wrote: post #28

Earlier quoted context omitted.

Yeah, that line seemed super weird to me too. 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.

Re: The magic of small engineering teams

#44

Post by icedchai » Thu, Jul 11, 2024, 10:33 PM UTC

fullsend wrote: post #38

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

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.