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

21–30 of 161 posts

Re: The magic of small engineering teams

#21

Post by dheera »

psim1 wrote: 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).

> not important enough to get quick attention

If you are essential to the company, it is on the company to give you the resources you ask for, or they are asses. If you have to waste time fighting for them, to the point where work can't get done, that is their problem.

If you are non-essential to the company, then it is on you to start looking for a place where you will be essential, either internally or externally.

Re: The magic of small engineering teams

#22

Post by marcosdumay »

r0ze-at-hn wrote: post #13

The author is writing about the common story of how to grow and scale. Each team gets a product, spinning off teams, etc. What if like most products there is a ramp up period where you need a full team (or teams) and then a few years later the product needs at most a fraction of the people to maintain the product? All of these people are going to "do stuff" because they are paid to do stuff further increasing the mai…

I dunno. The obvious answer is that then you make another product. and another, and another.

But very few companies are able to do this for some reason.

Re: The magic of small engineering teams

#23

Post by ghaff »

hobs wrote: post #3
psim1 wrote: 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).

Also a fundamental property of small teams (which can be good) is you can only commit to so much. You absolutely know you wont ever build a lasting bridge with a six person team, but you could ford a river. This type of stuff is ok when you are in startup mode but doing this long term at big companies creates a lot of existential risk that could be mitigated by better planning. This is a tradeoff some people make kno…

Put another way there is only so much you can do with a small team—and a small company. Things change as you grow. You can do more/bigger things but efficiency almost certainly takes a hit.

Re: The magic of small engineering teams

#24

Post by goosejuice »

but it has worked best for our company with these rules

Sharing is good, but as others have pointed out, folks publishing such things could use a bit more intellectual humility. At this point perhaps authors just expect others read it as opinionated anecdotes.

Typical thought leader dogma aside, using pizza as a metaphor for team size has always been silly to meaningless.

Re: The magic of small engineering teams

#25

Post by goosejuice »

al_borland wrote: post #7
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 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 autonomy. They of course won't be able to take credit in that case either :). Perhaps an overly cynical view I admit.

Re: The magic of small engineering teams

#26

Post by teaearlgraycold »

BurningFrog wrote: post #12
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 why I only work at small startups. There are tradeoffs, but I'll never go back to big organizations.

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’m in Silicon Valley to learn about and work with computers. I get to work a chill number of hours while still learning every day. If you could get a lot of employees like that you’d have a huge market advantage.

Re: The magic of small engineering teams

#29

Post by TulliusCicero »

angarg12 wrote: post #8

> Startups ship more per person than big companies – everyone knows this. But how do you retain that advantage as you scale? Our answer is small teams > Right now we're 47 people I'm sorry, but you haven't solved scaling small teams.

Yeah, felt like a bit of a rug pull. At that size, you've scaled only slightly; everyone in the company probably still knows each other on some level. But how do you maintain small team effectiveness in a company of hundreds, if not thousands?

Re: The magic of small engineering teams

#30

Post by wavemode »

marcosdumay wrote: post #22
r0ze-at-hn wrote: post #13

The author is writing about the common story of how to grow and scale. Each team gets a product, spinning off teams, etc. What if like most products there is a ramp up period where you need a full team (or teams) and then a few years later the product needs at most a fraction of the people to maintain the product? All of these people are going to "do stuff" because they are paid to do stuff further increasing the mai…

I dunno. The obvious answer is that then you make another product. and another, and another. But very few companies are able to do this for some reason.

Creating products is very easy. Creating products that generate a profit is very hard. If a company could do so on demand, it would be an infinite money glitch.
Post reply on HN