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

91–100 of 161 posts

Re: The magic of small engineering teams

#91

Post by wood_spirit »

kortilla wrote: post #53
rqtwteye wrote: post #40

Earlier quoted context omitted.

I don’t think so. Unless you get super high up, your pay increases proportionally to people under you. The next problem is that once you start cutting, you actually have to organize and manage. That’s way more difficult than saying “ I have hired x people”. I have been in countless discussions where management offered more people but whenever I told them the real problem is the process or another department not doing…

It’s well known that middle managers love to grow headcount. That doesn’t matter. If teams aren’t resulting in profit, they’re gonna get pressured to make cuts or will have RIFs imposed on them. I’ve seen this happen at every company, even big seemingly inept monsters like Oracle and IBM.

Those political middle and upper managers who are good at growing headcount are also good at shifting blame. They explain their lack of profit by either not enough headcount or else some other part of the company is letting the down (and they should take over that function so they can succeed next time) etc

Re: The magic of small engineering teams

#92

Post by Cyphase »

loupol wrote: post #48
vbezhenar wrote: post #31

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"

https://www.bitsaboutmoney.com/archive/optimal-amount-of-fra...

https://news.ycombinator.com/item?id=32701913

Re: The magic of small engineering teams

#94

Post by noisy_boy »

zeroonetwothree wrote: post #59
hdhshdhshdjd wrote: post #5

I think the inflection point between “startup” and “bureaucracy” (which is not a bad word, just a term for organizing people) is role specialization. Early stage everybody wears 10 hats, work is distributed and prioritized on a day to day basis. Once you have dedicated people or teams for task domains then the whole thing shifts to having a need for bureaucracy. You can slice the number of pizzas anyway you want, but…

I think “this isn’t my job” is generally a bad mentality (sure there are some times it’s ok, but those are like 1% of the actual times it’s used)

Most managers love to repeat "saying it's not my job is terrible attitude" while assigning unreasonable targets and stuffing items in the Sprint to the extent that even sneezing hard will make you overrun your deadline. So I am expected to deal with non prioritized work with a smile so that I have to steal from time set aside for my family in order to make the sprint target? How is that not bad mentality?

Re: The magic of small engineering teams

#95

Post by nikau »

osigurdson wrote: post #81
tonyarkles wrote: post #4

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

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

Re: The magic of small engineering teams

#96

Post by eschneider »

baumy wrote: post #55
vbezhenar wrote: post #31

Earlier quoted context omitted.

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

In a vacuum that's certainly the most pragmatic way to look at it. The problem is that tolerance of abuse tends to create more abuse, to the point that usually it's not a sustainable policy.

It's not tolerance of abuse. Abuse when detected will be punished. The important thing is, stopping ALL abuse preemptively causes more pain than it's worth.

Re: The magic of small engineering teams

#97

Post by maccard »

skywhopper wrote: post #50
maccard wrote: post #47

Earlier quoted context omitted.

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

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

Re: The magic of small engineering teams

#98

Post by binary132 »

01HNNWZ0MV43FF wrote: post #80
binary132 wrote: post #27

Buried lede: software engineering doesn’t scale.

It'll be funny if it ever does. AI replacing programmers is funny, AI replacing managers is hilarity. Also I think with open source it has scaled. I don't have to reinvent curl

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!”

Re: The magic of small engineering teams

#99

Post by defrost »

binary132 wrote: post #98
01HNNWZ0MV43FF wrote: post #80

Earlier quoted context omitted.

It'll be funny if it ever does. AI replacing programmers is funny, AI replacing managers is hilarity. Also I think with open source it has scaled. I don't have to reinvent curl

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

A fair number of the Hong Kong skyscrapers appear to be cookie cutter | symmetry (reflection &| rotation) patterns.

Elsewhere:

    As of September 2023, fourteen cities in the world have more than 100 skyscrapers that are 150 m (492 ft) or taller
~ https://en.wikipedia.org/wiki/Skyscraper

I'm going to suggest that high rise engineers have some pretty solid skyscraper templates today. The greater challenge likely comes from architects and investors wanting unique 'statement' designs.

Re: The magic of small engineering teams

#100

Post by xorcist »

This could be put more succinct: Trivial problems are trivial.

Of course you can keep splitting your teams when you are delivering a well defined product to customers. You could probably also have not split those teams. 50 people is trivial to manage, you could all meet in a room, should you have kept them geographically close. You may even have succeeded despite neutering those teams into triviality. You simply don't know.

Try doing something even slightly more complicated: Build a bridge. Or run a hospital. Or even a pension fund. Or just a software company with a lot of products. Those nice trim teams would quickly run into the brick wall of human communication.

That's the tough part of any organization. And we as a society needs to organize on large scale to get the important things done, unfortunately. Getting the easy things done is not enough.

Post reply on HN