Live data from Hacker News

The magic of small engineering teams

newsletter.posthog.com

121–130 of 161 posts

Re: The magic of small engineering teams

#121
post #109

Earlier quoted context omitted.

Yup, in NZ a two pizza team would average out to about three people I think. Are US pizzas giant?

I think it's meant to be an 'order some pizzas, everyone grabs a slice' sort of situation, not 'everyone is hungry and has a proper meal'.

If this were true, a two-pizza team would be 12-24 people (assuming a pizza gets sliced somewhere from 6-12 slices).

Re: The magic of small engineering teams

#122
post #109

Earlier quoted context omitted.

Yup, in NZ a two pizza team would average out to about three people I think. Are US pizzas giant?

I think it's meant to be an 'order some pizzas, everyone grabs a slice' sort of situation, not 'everyone is hungry and has a proper meal'.

Somewhere there is a company creating a committee to clarify this.

Re: The magic of small engineering teams

#123

I'm a fan of small teams also - but slowing down as the company scales is unavoidable. > Startups ship more per person than big companies – everyone knows this. But how do you retain that advantage as you scale? You can't! Not really. If you could, we would see companies doing it but...we don't (barring some yet undiscovered engineering process). Everything you ship, by definition, has an ongoing maintenance cost. Th…

> Even this post makes this mistake by referring to "data warehouse" and "analytics" as "products". But customers don't care about your data warehouse or your job pipeline. Depending on the part of the software industry you are in, customers might care very much about data warehouse or analytics products. Particularly, those products are highly important in the ERP area.

For sure if those happen to be your actual products, but that's not the impression I got from reading this particular post. (Happy to be wrong of course)

Re: The magic of small engineering teams

#124
post #2

Counterpoint: Being on a small team in a large organization sucks. In a large org, small teams have no weight. Actually, we have wait - we have to wait for everything: devops resources, marketing resources, even infosec resources. We are too small to notice, not important enough to get quick attention (never mind that our small team's product is profitable).

[deleted]

Re: The magic of small engineering teams

#125

Earlier quoted context omitted.

Where do you think all the heads to chop came from for all the publicized layoffs in tech these past couple of years?

Expected ROI. Do you know what a jobs program is? I think a lot of confusion comes from people not understanding that a role that currently costs more than in brings in is absolutely not the same thing as a jobs program. A jobs program is designed to just keep people employed at a loss by design. No expectation of a path to ever making money. The TSA is an example of a jobs program.

There are some roles like that in tech. For example, "charitable" positions like full-time OSS devs.

Another one that is questionable are tech evangelists or dev rel. Sometimes those positions can be connected to revenue, but usually it's "mindshare" accounting.

Re: The magic of small engineering teams

#126
post #48

Earlier quoted context omitted.

If barriers harm more than abuse then abuse should be accepted.

Reminds me of that bits about money blogpost title : "The optimal amount of fraud is non-zero"

Yes and the optimal amount of test coverage is never 100%

Re: The magic of small engineering teams

#127
post #109

Earlier quoted context omitted.

I think it's meant to be an 'order some pizzas, everyone grabs a slice' sort of situation, not 'everyone is hungry and has a proper meal'.

If this were true, a two-pizza team would be 12-24 people (assuming a pizza gets sliced somewhere from 6-12 slices).

Well alright everyone grabs a couple of slices, I'd say typical is 8 slices per pizza right, so that works out to 8 people, which yes is what it means doesn't it? (Not literally 8 but in that 6-10ish region?)

My point was if you interpret it to mean a full meal for hungry people a two pizza team is like 2 maybe 4 people, because 'a pizza' is an order, unless these are enormous fast food 'party size' type pizzas.

Re: The magic of small engineering teams

#128
post #95

Earlier quoted context omitted.

A lot of this comes down to budgets - those 10 people have a fixed salary so there is no visible cost.

Those costs should be made visible as they are real. The price of each meeting should be included in the agenda.

If salaries were transparent and queryable this could even be a Slack or Teams plugin. But most org cultures would never dare expose salary imbalances like that.

Re: The magic of small engineering teams

#129

Earlier quoted context omitted.

Same. I quit Google to go work at a 4 person company. I love that we’re just able to get stuff done. Hard to get GPUs? Walk down to Central Computers in SOMA and buy L40S cards and build a workstation for everyone to share. I’m not very financially motivated. I’m already making more than 90+% of the US. I just can not fathom the level of greed I saw hiding behind people’s eyes at Google as they try to build empires.…

> I just can not fathom the level of greed I saw hiding behind people’s eyes at Google as they try to build empires. That’s very well written. Poetic even. > I’m in Silicon Valley to learn about and work with computers. The industry used to be more like that. Never entirely, of course - Microsoft made a bunch of people millionaires in the 80s and 90s, turned some heads. A few others did too. Even in the early 2000s a…

You might be missing the dot com boom in your analysis. MBA types flocked to the tech sector looking for those IPOs, a trend that I suspect has only grown stronger since.

Re: The magic of small engineering teams

#130
post #2

Counterpoint: Being on a small team in a large organization sucks. In a large org, small teams have no weight. Actually, we have wait - we have to wait for everything: devops resources, marketing resources, even infosec resources. We are too small to notice, not important enough to get quick attention (never mind that our small team's product is profitable).

I think the primary idea of a small team is that it is self-sufficient and avoids the N^2 problem associated with everyone talking to everyone.

N choose two, not N^2. The latter double counts and also counts people communicating with themselves. For example, with 2 people, it is not 4 paths of communication, but just 1.

N choose two is n*(n-1)/2, which yields the right answer

In asymptotic analysis, they are the same. Except, that analysis does not make sense, asymptotic refers to the growth of the function as values approach effectively infinite

Post reply on HN