The magic of small engineering teams
newsletter.posthog.com
The magic of small engineering teams
1–10 of 161 posts
Re: The magic of small engineering teams
#2Counterpoint: 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).
Re: The magic of small engineering teams
#3Counterpoint: 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 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.
Re: The magic of small engineering teams
#4Counterpoint: 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).
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.
Re: The magic of small engineering teams
#5I 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.
Re: The magic of small engineering teams
#6Is 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
Re: The magic of small engineering teams
#7Counterpoint: 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).
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
#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.
Re: The magic of small engineering teams
#9I 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
Re: The magic of small engineering teams
#10Counterpoint: 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).
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…
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