31–40 of 44 posts
I think they will eventually find that having a huge number of tiny teams will result in silos, replicated work, and massive inefficiency as they try to scale up. This averages out as 15 3 man teams. Yikes.
I find Posthog interesting because it launched around the same time (2020ish) as Stan.Store. Not Posthog is a technically much more challenging product and is more geared towards developers and yet in terms of ARR it is at 10 million whereas Stan.Store which is basically link in bio + a very basic store is doing 25 million ARR. Goes to show, selling to developers is really hard. Hopefully Posthog makes it in the long…
Earlier quoted context omitted.
> selling to developers is really hard. Yes, software wise, we either take open source stuff or write our own stuff. There are just very little in between that can be monetized.. unless it bundles with hardware like ChatGPT.
Cynical take: Selling software to developers is hard partly because the customer is more likely to notice when the product functionality (as opposed to marketing) doesn't really do what they need.
> Startups ship more per person than big companies – everyone knows this The post starts out by assuming this but I am not convinced this is true along the entire graph, if the x axis is amount of people on a team and the y axis is amount "shipped". As a company scales output, at some point in this graph the output per person from the large team should overtake the small team, otherwise why do we even have large team…
This is a case of managing technology teams with the mindset of a product manager. It can also be said that it is an effort to find a solution to a problem that does not exist. I prefer 2 teams that work much more dynamically to 18 teams dealing with a very small region.
>>> We prefer goals orientated around what teams will ship, rather than more abstract goals like "increase conversions by 10%". This is … interesting. I can hear every scrum master course leader crying but I like it. On the other hand, measuring impact in the real world is a vital task - but yeah it’s a lot easier to say “Inwill build a car” than “I will drive the user to a football game once I have built a car”
Yeah, that line seemed super weird to me too. Obviously "improve X metric" is not a plan, but without any key results to evaluate against, it's easy for things to be "done" poorly or to not be targeted at something that matters, particularly as orgs get larger. They do say that teams have long term objectives and metrics, so maybe those are what is used for evaluation, but it definitely feels weird.
But I’m also sick of hearing how these teams can “ship” so fast. Yeah you can ship, you have no customers. No users, no SLAs, no employees. Good work, you just did whatever you wanted and then typed “git push” to a repo you control, with standards you control, and a build process you control. Wow those stodgy big co’s could learn something from you!
This is a similar convo to “why use Kubernetes”. Do you have one binary and one database with one password? Go nuts with your single VPS and bash scripts and keep telling yourself that everyone is over complicating it. But are you scaling? You’ll probably need some orchestration. You’ll probably need some managers, a ticket system, on-call, standard build tools. Documentation.
Scaling to billions with a team of 20 is a fantasy achieved only by the select few. As always it is a fine line companies should tread lightly. Don’t rush to hire, but don’t be afraid of it either. Focus on scaling intentionally and carefully.
>>> We prefer goals orientated around what teams will ship, rather than more abstract goals like "increase conversions by 10%". This is … interesting. I can hear every scrum master course leader crying but I like it. On the other hand, measuring impact in the real world is a vital task - but yeah it’s a lot easier to say “Inwill build a car” than “I will drive the user to a football game once I have built a car”
This is a feature not a bug. Small teams don't need a leader just like how small bands don't need a conductor. If you want to add admin give them a secretary so they don't waste their time on administrivia.
I started out firmly against large companies. My ideal team is 10-20 engineers, in person, hyper focused and all on the same page with mutual respect. Minimal or no product manager types. But I’m also sick of hearing how these teams can “ship” so fast. Yeah you can ship, you have no customers. No users, no SLAs, no employees. Good work, you just did whatever you wanted and then typed “git push” to a repo you control,…
This is _not_ a small team. This is the size of a team that can serve the world, see whatsapp. A small team is >5 engineers working on a well defined business task, like writing Unix.