[HN Gopher] The magic of small engineering teams
___________________________________________________________________
The magic of small engineering teams
Author : andyjohnson0
Score : 84 points
Date : 2024-07-04 09:09 UTC (2 days ago)
(HTM) web link (newsletter.posthog.com)
(TXT) w3m dump (newsletter.posthog.com)
| psim1 wrote:
| 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).
| hobs wrote:
| 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 knowingly (like the posthog
| post clearly lays out) but as usual this "2 pizza team" is
| cargo culted way too hard.
|
| In many cases I see the product folks with the same vision
| regardless of the team sizes or org fit.
| ghaff wrote:
| 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.
| tonyarkles wrote:
| 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 needed
| $40 worth of solder and connectors and had to wait a week for
| PO approval as well as demonstrate that we had gotten multiple
| quotes... even though there was just a store down the block
| that sold exactly what we needed.
|
| Anyway, after a month or two of this I started catching
| significant flak because my team was nowhere near as productive
| as it used to be. Complaining about slow POs was met with
| "maybe you should plan better". Complaining about design
| reviews for one-off boards that would go from idea-to-problem
| solved was met with "you're engineers, you need to document
| your work". It was painful and I came very close to resigning.
|
| What ultimately worked, though, was figuring out a catch phrase
| that spoke the language of the new people: "accountability
| without authority". This ruffled some feathers but once I
| repeated "you are trying to hold me accountable for delivering
| a $500,000 project on time but are not giving me authority to
| buy $40 worth of stuff to execute on that" enough times it
| finally got through and the system started to change. But man
| did it suck for a while.
| al_borland wrote:
| 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.
| goosejuice wrote:
| 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.
| vbezhenar wrote:
| If barriers harm more than abuse then abuse should be
| accepted.
| habitue wrote:
| That's a great story of sticking through a really tough
| situation and figuring out how to make it work. Honestly most
| of these stories end with "it sucked and then I quit". Which,
| fair, but not as interesting
| BurningFrog wrote:
| This is why I only work at small startups.
|
| There are tradeoffs, but I'll never go back to big
| organizations.
| teaearlgraycold wrote:
| 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.
| getcrunk wrote:
| How many number of hours is chill? 4? 6? 3?
| dheera wrote:
| > 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.
| crtified wrote:
| 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.
| hdhshdhshdjd wrote:
| 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 imho once
| people have a "this is/isn't my job" mentality (which again, is
| not a bad thing), you really need to focus on role boundaries and
| coordination. But the "startup" part is in the rear view.
| shishy wrote:
| Is this similar to single threaded owner (sto) models? I'm
| curious how they handle things like career management and
| promotions but this structure overall seems great
| angarg12 wrote:
| > 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.
| TulliusCicero wrote:
| 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?
| ttyyzz wrote:
| I have to disagree with the "2 to 6 people" - even for small
| projects I feel like 4-6 people is great. This way you can ensure
| that everyone has a "tandem" and e.g. It's not just a frontend
| developer doing some mischief that someone has to clean up
| afterwards :D
| habitue wrote:
| This is interesting, because at 47 people they're in transitional
| scaling. Like they've had to solve "too many teams for the CTO to
| manage directly" but not "too many teams to align effectively".
|
| At 15 strong self-directed teams, you can have a few teams
| focused on the high level directives, and a few entropy repair
| teams that mostly self-manage.
|
| The way to think about it is maybe like homeostasis. Self-
| directed product teams will implement new features, fix bugs, and
| generally keep the thing on track, but the efficiency drops off
| as the feedback mechanisms of talking to customers reaches
| equilibrium.
|
| To mix metaphors, a leadership team creates a kind of current
| flow in that system. When you're small you can go to each of
| those teams and ensure that current flow is happening.
|
| But at a larger size, that doesn't work. You have to engineer and
| carefully craft the feedback mechanisms the teams are working off
| of to induce that current. This is a hard problem, but it's where
| things like minimum attrition policies, OKRs, etc spring from:
| leadership trying to have a policy that induces current.
| r0ze-at-hn wrote:
| 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 maintenance burden. You run head
| first into the common problem of:
|
| "I have 1000 engineers and I can't get anything done!"
|
| In the worst case the CEO solves this by doing lay offs. Been
| thinking about this problem for over a decade, making effective
| engineering organizations that can not only grow, but change
| shape is difficult, but can also be very rewarding when done
| successfully.
| marcosdumay wrote:
| 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.
| wavemode wrote:
| 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.
| whoknowsidont wrote:
| Corporations are mostly just job programs. Most companies do not
| actually need anywhere near the number of people they have
| employed to function.
|
| The reasons why small teams work is because the number of
| communication channels go down, and you spend less time simply
| talking about the work and actually doing the work.
| paulryanrogers wrote:
| Or perhaps corporations grow large because they serve diverse
| needs. Much like users only need 10% of Microsoft Word, yet
| many cohorts often need a different 10% slice.
|
| Or we lack anti-trust controls, so rent seekers are soaking up
| markets.
|
| Maybe a combination of all three.
| kortilla wrote:
| This is not true. If the people weren't providing some positive
| ROI then the execs would be drooling over the money saved from
| cutting them.
| rqtwteye wrote:
| 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 their job, I got silence.
| malfist wrote:
| The whole section on managers rubbed me the wrong way. Team leads
| aren't managers and thus aren't responsible for onboarding, not
| communicating up the chain about perfomance, but is Responsible
| for performance of individuals on the team. And the phrasing
| about managers mostly care about happiness and team leads don't,
| makes me think this place might be very toxic to work for. Reeks
| of "brilliant jerk" acceptance and accountability without
| authority.
|
| It also feels rich to have a 47 person company tell you they've
| figured out the secret sauce of people management and team
| formation.
| drewcoo wrote:
| > Startups ship more per person than big companies - everyone
| knows this.
|
| Startups can quickly change alignment to make the company work.
| They can throw more spaghetti at the wall to see when it's done.
|
| > But how do you retain that advantage as you scale?
|
| Once the company figures out what works, you'll want to put
| people and processes in place to keep it working. That means
| bureaucracy. That slows change. Intentionally.
|
| In big commercial kitchens no one throws spaghetti at the wall.
| That's waste.
| arjunlol wrote:
| This was particularly bad at Meta pre-efficiency push Zuck. There
| was huge bloat that was counterproductive. Empire builders were
| incentivized by promotions based on the size of their orgs.
|
| One thing the article didn't mention is how crucial it is for a
| team to have focus and to ruthlessly prioritize. It's easier for
| bigger teams to fall into the trap of doing "busy work" and
| people fighting for scope on their performance reviews. This is
| the worst possible outcome for company and employee where you
| have work driven by optics vs value.
| nextworddev wrote:
| Empire building has gotten rejuvenated recently at faang due to
| people politicking to get the fancy AI projects
| goosejuice wrote:
| _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.
| mathgeek wrote:
| > Typical thought leader dogma aside, using pizza as a metaphor
| for team size has always been silly to meaningless.
|
| An easy way to see it fall apart is to imagine a team that each
| eats 3-4 slices of pizza, or a team that only eats one slice
| each.
| verve_rat wrote:
| Yup, in NZ a two pizza team would average out to about three
| people I think.
|
| Are US pizzas giant?
| binary132 wrote:
| Buried lede: software engineering doesn't scale.
| swader999 wrote:
| 4-6 is ideal, over 6 people and the communication and
| coordination overhead starts to cost too much.
| Scubabear68 wrote:
| A 47 person company with 15 teams sounds like a nightmare to me.
| jWhick wrote:
| man posthog is one of the shittiest companies there is out there.
| skywhopper wrote:
| God, I hate the pizza as a unit of team size. It tells me
| nothing.
___________________________________________________________________
(page generated 2024-07-06 23:00 UTC)