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.
Numbers are hard to remember, but pizza is easy to remember
The magic of small engineering teams
151–160 of 161 posts
Re: The magic of small engineering teams
#152Earlier quoted context omitted.
One of the most interesting discussions I've had around this was at a small company who mass-hired a bunch of people from a big company. We went round and round in circles for a while because of issues similar to what you're describing. I ran a small 4-6 person hardware team (softly blurry on the edges) and the new people wanted significant amounts of design and documentation review as well as financial oversight. We…
This kind of stuff drives me nuts. I just spent 8 months fighting to get $150 for something. This should have just been taken out of some petty cash fund, but instead I wasted a ton of my time, and others, fighting to get it from the proper source. This cost the organization thousands of dollars in lost time.
Re: The magic of small engineering teams
#153I'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…
And it comes down to hubris.
Too many people (in finance, mostly - which drives the rest: entrepreneurs, "big" managers, etc.) in the industry (like to) think that maintenance is bad, because it's not new or growth-capable (which is where they expect to get more, and more, and more).
But maintenance/routine is actually most of the work for everyone, everywhere on this planet. Which is good work.
You can/may outsource, or automate (it's the same actually: getting the same output for a lower cost), it. With the consequences it comes with.
You can/may prefer to be in the 1% of innovation too. But once you innovate (on) something, you've got to maintain it. Someone has to.
The good places where to work are those that admit, and implement (in their structure, in how the manage people and their expectations), that maintenance is most of the work, and that innovation is the small part of it.
It's like in art: most/99% of the time, you practice, you learn. 1% of the time, you get to do/find something great out of it.
Which leads me to the dullness of generative AI: you can't have the 1% if you don't go through the 99% - and you may not understand this if you never tried once to get through those 99%.
Re: The magic of small engineering teams
#154Earlier quoted context omitted.
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)
Yeah there's still way to many variables. Regional/cultural differences, appetite and body size, pizza styles, etc. For small teams that makes for a meaningful difference between the min and max. For large teams not so much. My wife and I have no issues finishing a 16in tavern style pizza. So that's a 4 person team. We're not even large people or big eaters. We just like pizza.
When I worked for amzn.. I was eating approx 3500 calories a day - long bike commute. Pizza was always disappointing as rarely enough (and even then, eating my fill would be too much. I had to go out and still buy another lunch anyways* - and almost always not enough veg pizzas!). We perhaps could get into the variety of factors, yeah, eg: nutrition density to as a function of toppings.
Though.. if you look at serving size and how many people a large is meant to feed, it is pretty simply just 3 to 4.
* worse yet, because lunch was delivered, there was an expectation to work an extra hour that day (ie: working lunch meeting, and certainly do not go home early). Foing out to get enough real food and suddenly I was the bad guy for being the one team member not in office. Actually buying lunch was easier, I would just buy two at once.. Thinking back to that time, holy shit the work expectations were something else..
Re: The magic of small engineering teams
#155Earlier quoted context omitted.
One of the most interesting discussions I've had around this was at a small company who mass-hired a bunch of people from a big company. We went round and round in circles for a while because of issues similar to what you're describing. I ran a small 4-6 person hardware team (softly blurry on the edges) and the new people wanted significant amounts of design and documentation review as well as financial oversight. We…
This is a very common problem in many orgs. Spending time (adding meetings, exploring various options, etc.) is completely fine while spending money is a huge deal because of the emotional connection to money that many people seem to have. Imagine, holding a 2 hour, 10 person meeting to decide if an additional one time $1000 cloud expenditure is warranted. Yet, this happens all the time. I can assure you, that this i…
I don't have to imagine; I've had it happen within the last month. IT was complaining about dev's storage usage. It would have been cheaper for them to buy 10x 20tb hard drives than pay for the meeting that was called about it. Luckily, when that was pointed that out in the meeting, the dept manager agreed and ended the meeting shortly after.
Re: The magic of small engineering teams
#156Earlier quoted context omitted.
This kind of stuff drives me nuts. I just spent 8 months fighting to get $150 for something. This should have just been taken out of some petty cash fund, but instead I wasted a ton of my time, and others, fighting to get it from the proper source. This cost the organization thousands of dollars in lost time.
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…
Re: The magic of small engineering teams
#157I'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…
Re: The magic of small engineering teams
#158Small teams work very very well if the team is full of competent people. Such a small team will execute much faster. The problem is that if you need to do more work at some point a small team won't be sufficient and you will end up hiring more. And as you hire more you will inevitably have quality dilution. Both communication in large team size and hiring issues make large teams much less effective.
Re: The magic of small engineering teams
#159Earlier quoted context omitted.
> 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)