Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The magic of small engineering teams

newsletter.posthog.com

Post reply on HN
Print view View original

131–140 of 161 posts

Re: The magic of small engineering teams

#131

Post by seadan83 »

bdcravens wrote: post #125
kortilla wrote: post #84

Earlier quoted context omitted.

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.

OSS dev might be a bad example. OSS is often an internal product that is opened up to gain free OSS labor. Most often, the position would exist within the company if it were OSS or not. In other words, it is something the company is working on regardless of OSS or private codebase

Re: The magic of small engineering teams

#132

Post by seadan83 »

_xivi wrote: post #118
hartator wrote: post #111

> Startups ship more per person than big companies Are they? Apple revenue per engineer is $2.4M. It seems hard to beat.

What does revenue got to do with producing/shipping products? maybe you quoted the wrong sentence? You can have millions of dollars in revenue without producing anything, on the other hand, you can also provide a lot of services and products for free

> What does revenue got to do with producing/shipping products?

I'm quite sure a number of product people would answer "everything"

Feature factories are a thing for a reason.

Re: The magic of small engineering teams

#133

Post by seadan83 »

defrost wrote: post #99
binary132 wrote: post #98

Earlier quoted context omitted.

curl and git are amazing but they aren’t skyscrapers. Building a skyscraper, space shuttle, or integrated circuit is hard to organize even once, let alone to abstract over the process of organizing and building it so that it can be reproduced. I don’t think that problem is solved at all. And it’s not at all as simple as “just take the open source legos and slap a few of them together!”

> Building a skyscraper [...] is hard to organize even once, let alone to abstract over the process of organizing and building it so that it can be reproduced. I don’t think that problem is solved at all. Hong Kong has over 9,000 high-rise buildings, of which over 4,000 are skyscrapers standing taller than 100 m (328 ft) with 554 buildings above 150 m (492 ft). ~ https://en.wikipedia.org/wiki/List_of_tallest_building…

You make good points. I think this illustrates well that software engineering is much more akin to writing than it is to carpentry/construction. Thus, a team of software developers is more akin to a team of story writers than a team of carpenters. A software company is more akin to a newspaper (writers/reporter/chief editor) vs a construction firm (business giving direction to an architect and in turn a foreman + dozens of laborers)

Re: The magic of small engineering teams

#134

Post by seadan83 »

osigurdson wrote: post #77

I never really understood the "pizza" metric. Why not just state the range instead?. Two pizzas can "feed" a lot of people (perhaps 16 - 20 even) if they aren't very hungry, aren't very big or aren't very young.

I joked that I was a half pizza team on my own. The commute had me riding 25 miles per day on bike, I don't eat breakfast and only a light dinner -> lunch was easily 4 slices of pizza.

In seriousness, pizza is not a bad measure since it means basically 3 to 4 people per pizza. Thus two pizzas is 6 to 8. 2 slices is usually assumed to be the serving size. 20 people is not even one slice per person

Re: The magic of small engineering teams

#135

Post by seadan83 »

OJFord wrote: post #127
mathgeek wrote: post #121

Earlier quoted context omitted.

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.

2 slices is considered to be a meal. Calorie wise, it likely is. Typical large pizza has 8 slices. The vagueness is intentional. From the Amazon concept, it is intended to replace a meal and not be a random snack. (Former amazon employee here)

Re: The magic of small engineering teams

#136

Post by quantgenius »

vbezhenar wrote: post #31
goosejuice wrote: post #25

Earlier quoted context omitted.

I think this is all too common due to a small few who take advantage which leads to the construction of barriers to prevent abuse. This isn't limited to large orgs -- it's everywhere in society. I suspect accountability without authority might not be as accurate as one might seem when there exists middle management. You might be accountable but your boss probably is more so, thus the reluctance in giving full autonom…

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

Nope. Abuse should never be accepted. The right solution for actual abuse of a policy like this as opposed to an error is to immediately fire the person conducting the abuse. The inability or unwillingness to make decisions like this fast is the root cause of a lot of nonsense that goes on at businesses.

If it's an error, you correct and accept errors as the cost of doing business.

Re: The magic of small engineering teams

#137

Post by seadan83 »

maccard wrote: post #47
skywhopper wrote: post #41

God, I hate the pizza as a unit of team size. It tells me nothing.

It’s an abstract measure that is somewhere between 2 and 10 people. It’s deliberately not supposed to be prescriptive

It is one large pizza, 8 slices, that is 3 to 4 people.

Yes, some people can eat more or less. If you had 10 people, you could order 2 larges but that is going to be a treat or a snack, not something that will be welcome if that is a lunch meeting.

Re: The magic of small engineering teams

#138

Post by seadan83 »

maccard wrote: post #97
skywhopper wrote: post #50

Earlier quoted context omitted.

This is what I’m saying. “Between 2 and 10” is useless guidance.

I don’t think it is, at all. It’s telling you to keep teams small enough that you can manage them and have them all in one meeting

And secondly, do not need to fill out an elaborate expense report for buying lunch. At the time of two pizzas, Anazon circa 2008, that would have been a sub $50 order.

Re: The magic of small engineering teams

#139

Post by shepherdjerred »

evilduck wrote: post #128
osigurdson wrote: post #110

Earlier quoted context omitted.

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.

There is this project: https://github.com/syncfast/clockwise

Re: The magic of small engineering teams

#140

Post by com »

kjellsbells wrote: post #43
crtified wrote: post #34

Earlier quoted context omitted.

This reminds me of a situation which I'll label "satellite office syndrome" - which is where a company has a large/dominant Head Office, and smaller regional offices which are in a permanent state of playing second-fiddle in terms of funding, attention, respect and company culture.

This is as true with products as with locations. For example, the people doing S3 at Amazon get everything they need, because that is a blockbuster product...and the people doing, oh I dont know, Greengrass IoT are waayyy down the totem pole even though it might be a perfectly profitable product. Large orgs tend to have a Roman Empire feel to them for most of the people, most of the time. You're stuck out on the edge…

I thought that metaphor would go in a different direction, tbh. I was thinking “praetorian guards”, “imperial decline”, “decadence”, “barbariand resettling inside the limes” etc.
Post reply on HN