[HN Gopher] The magic of small engineering teams
___________________________________________________________________
The magic of small engineering teams
Author : surprisetalk
Score : 78 points
Date : 2024-07-05 15:38 UTC (5 days ago)
(HTM) web link (newsletter.posthog.com)
(TXT) w3m dump (newsletter.posthog.com)
| JohnMakin wrote:
| > 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.
| playingalong wrote:
| Large companies vs. large teams is not the same.
|
| > 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.
| JohnMakin wrote:
| > Large companies vs. large teams is not the same.
|
| sure, but isn't this OP making a direct comparison?
| MacsHeadroom wrote:
| 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.
| sokoloff wrote:
| 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.
| jdlshore wrote:
| 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.)
| bee_rider wrote:
| 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).
| Espressosaurus wrote:
| 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.
| cchi_co wrote:
| Many large companies adopt a hybrid approach where they
| organize work into small, cross-functional teams
| LeifCarrotson wrote:
| 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.
| scubakid wrote:
| From what I've seen, total output (usually) continues
| increasing, but at a certain point, the curse of scale is
| bureaucracy.
| Maxatar wrote:
| 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.
| wood_spirit wrote:
| Previously
|
| https://news.ycombinator.com/item?id=40873471 (151 comments)
| adamors wrote:
| So it's not me having deja-vu, yes this was posted a couple of
| days ago.
| ilrwbwrkhv wrote:
| 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.
| Aperocky wrote:
| > 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.
| Terr_ wrote:
| 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.
| iddan wrote:
| From my experience: that is not the problem selling to
| developers
| iddan wrote:
| To give a counter point: replacing stan.store takes a day,
| while replacing posthog can take a year
| ramesh31 wrote:
| 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.
| chidli1234 wrote:
| Hmm.. 47 people, 15 teams - indicates 3 to a team.
|
| Yet the image has 6 gophers.
| warkdarrior wrote:
| 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.
| icedchai wrote:
| Sadly, I have seen organizations follow this rule. And wind
| up with more "managers" than actual ICs. It's insane.
| Eridrus wrote:
| 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.
| dbg31415 wrote:
| Use this thread.
|
| https://news.ycombinator.com/item?id=40873471
| pictur wrote:
| 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.
| iddan wrote:
| Looks like it works pretty good for them. Maybe managing like
| an engineer is not such a good idea
| Scubabear68 wrote:
| 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.
| iddan wrote:
| That's a rich man's problem. You miss the point - having this
| type of problems for a startup is a huge win
| BigParm wrote:
| My favorite size of engineering team is 1
| lifeisstillgood wrote:
| >>> 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"
| Eridrus wrote:
| 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.
___________________________________________________________________
(page generated 2024-07-10 23:00 UTC)