Small 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.
The magic of small engineering teams
101–110 of 161 posts
Re: The magic of small engineering teams
#102Corporations 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.
You are totally correct basis my observations. However, companies can not be smaller as past a certain scale a company resembles a communist economy. Having read the book "Red Plenty", I saw so many similarities with the big techs I have worked at. Internal teams have a top given monopoly and have no incentive to improve their products unless there is some external competition. Most companies are now led by people who have much less skin in the game (up to the CEO level in most) and every small org resembles a factory in the soviet union. The incentives of everyone working at the company is to keep growing bigger.
Re: The magic of small engineering teams
#103Earlier 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 work in embedded. When I told my boss I was leaving he asked what the other company was offering me - compiler licenses. Without enough each firmware build took 40-60 minutes. With enough, 10 minutes.
Re: The magic of small engineering teams
#104I'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. The more you ship, the higher your maintenance burden. Over years, this grows and grows. Output (as defined by "products shipped") per engineer must go down, because more and more engineers must be dedicated to maintenance work.
Now, we've gotten really good at disguising maintenance work as product work/shipping things. But it's not reality. 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.
> Right now, for example, we're in the process of scaling support by moving our support engineers out of the customer success team and into a new customer comms team.
This is not product work. This is maintenance, and is a literal example of the type of thing that larger companies have to do just to maintain their existing products and contributes to lower product output per engineer.
Re: The magic of small engineering teams
#105For a product like PostHog this might make sense. But YMMV. Their product is a collection of micro products which is pretty unusually especially for a company at their stage and size
That's an important context which kinda invalidates the value of this article. Scaling the number of independent products is almost trivially easy. What's difficult is scaling one product to a large size, since there breaking up teams doesn't achieve much on its own.
Re: The magic of small engineering teams
#106Earlier quoted context omitted.
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 just can not fathom the level of greed I saw hiding behind people’s eyes at Google as they try to build empires.
I feel like the insane ponzi scheme of our housing market does this to everyone eventually
Re: The magic of small engineering teams
#107Earlier quoted context omitted.
This is why I only work at small startups. There are tradeoffs, but I'll never go back to big organizations.
Heh, it was a small startup. And then there was a $x0 million seed round and suddenly we became a much larger startup. When we hired a bunch of business/management-type people who had all worked together at another organization they imported their broken culture. (We were able to hire all of them because their previous organization had had a significant layoff... and for the record I had nothing to do with their hiri…
My current startup is doing well and got a pretty big round of financing, so now we're hiring a lot of people.
That's not the main reason I'm quitting this week, but it definitely helped the decision!
Re: The magic of small engineering teams
#108Earlier 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"
Matt Levine has a recurring bit on this in Money Stuff too, adjusting the crime/fraud/risk dial back and forth as companies decide to do more or less compliance.
Re: The magic of small engineering teams
#109Earlier quoted context omitted.
> 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.
Yup, in NZ a two pizza team would average out to about three people I think. Are US pizzas giant?
I think it's meant to be an 'order some pizzas, everyone grabs a slice' sort of situation, not 'everyone is hungry and has a proper meal'.
Re: The magic of small engineering teams
#110Earlier quoted context omitted.
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.
Those costs should be made visible as they are real. The price of each meeting should be included in the agenda.