Main thing that comes out of it is "focus". Focus starts to dissipate the larger the team. I don't think focus will guarantee you success (you could be focused on the wrong thing) but I don't think you can be successful without it.
Nice. I wish all the examples included user/revenue/impact numbers (like Instagram) rather than only investment/valuation information (like Notion, WhatsApp, Kylie Jenner, etc)
It would be interesting to see a list of unsuccessful small teams as a point of reference. Oh wait… it probably wouldn’t. Then again, a list of unsuccesful large teams may not offer much insight either.
There may be many advantages to small teams and yes there are cases where they have wild financial success, but in general these may just be outliers. Are these outliers because they have the secret sauce worth emulating? Maybe, and maybe their stories will show why they succeeded where so many failed. Success is rarely all luck, but we’ll likely also invent myths around their exceptionalism as we tend to do. Not the type of exceptionalism which precludes the rest of us from having a similar shot of course, but one about cleverness and grit or other characteristics we can fairly easily attribute to ourselves.
Everyone likes a good narrative, I suppose. And narratives about scrappy small teams achieving success meritoriously are more attractive than ones about how the massive organizations usually tend to eat them for lunch (despite having their own types of problems) or ones about the frequencies with which the scrappy teams fail. Cherry-picking data points is the key to any good narrative.
Small teams often move faster than big teams, that is why small teams are bought by big teams instead of big teams just building their own and quickly taking market share and crushing them with better designs, features, pricing, marketing budget and iteration speed.
Big stuff is slow by nature. Lots of moving parts.
It's just probability theory meets survivorship bias. The larger the team the more it will trend towards the average because the joint probability that everyone in the team is simultaneously awesome (or awful) becomes lower and lower as a function of team size.
Same thing happened with "small schools perform better" so they got funded. But turns out it's possible for them to perform terribly for the same reason it is for them to perform well.
> Same thing happened with "small schools perform better" so they got funded. But turns out it's possible for them to perform terribly for the same reason it is for them to perform well.
Probability changes with sample size? Any source for that claim?
AFAIK only variance changes with sample size.
Otherwise statistics would be quite useless in general as I understand it.
Say in the general population 10% are excellent. If I look at 10 randomly selected people I expect that one of them is excellent. If I look at 10 000 people should I really expect that more than 1 000 are excellent? That claim does not make sense to me.
Even in smallish teams the probability that all members are excellent (or terrible) is almost zero, imho. In a bigger selection it's just closer to zero.
In fact in any sample the distribution of "excellent, average, and terrible" will be more or less the same. Namely more or less like the distribution in the general population. (Otherwise we can stop looking at statistics in general as they would be worthless).
The probability for the most unlikely event (namely a result that is maximally far away form the expected one) may be a little bit greater given smaller sample sizes (a result of broader variance), but this is irrelevant as the probability for such outcome is in almost any case infinitesimally small.
Looking at the verges of a distribution to draw conclusions is misleading, imho. You need to look at the middle of the curve as there are the most likely outcomes of some selection.
So, if I put some random people in a group the most likely outcome is that the ratio of excellent people to others is similar to the ratio of excellent people to other in the general population. This is the most likely outcome, independent of sample size.
Smart people often have smart friends, so a small team of mostly smart people isn't that unlikely.
The problem is when you get a few degrees of separation, at that point the original signal is mostly lost and you will get the same kind of people as everyone else who uses the same hiring bar as you.
Your argument doesn't work, nobody knows enough people to staff up a big company with only people they know. At some point they will have to go by surface signals or by word of mouth, talking to a person in an interview isn't enough.
On the other hand for a small team, lets say 10 people, you could go back and pick the 10 best people you have worked with in your life. That will be a good team if you actually tries to get good people instead of people you like. That doesn't scale, other people will take people they like and quality suffers, it always happens at scale, but an individual kan make better choices.
Yes, getting only "the best of the best" doesn't scale. I fully agree.
But it also doesn't work for smaller teams, because people are people.
Now we're back to my previous argument: The probability to get a team of only excellent (or terrible) people is near zero in reality independent of team size.
Everything put together finally invalidates the original:
> > Same thing happened with "small schools perform better" so they got funded. But turns out it's possible for them to perform terribly for the same reason it is for them to perform well.
> Joint probability all members are either all excellent or all terrible is higher when the number of people is smaller.
Trying to approach this conclusion by statistics just doesn't work as we see.
But the non stochastic arguments why small teams are always in advantage, which I presented in my other post, hold.
> It would be interesting to see a list of unsuccessful small teams as a point of reference.
I guess it depends on what you call success. Most businesses are mom and pop businesses that generate enough revenue to pay their employees the market rate in the long run. And I’m including tech businesses.
Most flourishing economies in the world are composed essentially of small successful and sustainable businesses.
To me, that is success.
I know that a lot of people here live in the SV echo chamber (nothing pejorative, we all live in an echo chamber) but in fact being big is the exception, not the norm.
I’d even argue that most "rich/comfortable" people in the world are not tech founders but are just at the head of 0 to 10 employees businesses. I’d guess they call this success.
> It would be interesting to see a list of unsuccessful small teams as a point of reference
You can just go look at Steam indie games. Those are all small teams. They are mostly all failures.
The median small team on Steam generates $4,000 in lifetime revenue. 2/3rds never cross $10,000 in lifetime revenue. Only the top 10% even cross $200,000. Which is more like "barely paid salaries" rather than some kind of F-U money.
The number of small teams on indie games that come anywhere close to the success of big teams on AAA games is minuscule.
The celebrity ones don't belong on the list. Barack Obama makes lots of money as a speaker too, it's not because of some inherent efficiency of small teams.
Some of these are so odd. When Kylie Jenner launched her company she could have sold celery and still made $1B+. It wasn’t because of the effectiveness of her small team.
Yes, especially when a lot of the work is grunt work. Think of making a 2-hour movie. Even the ones without much special effects like dramas require an enormous amount of people since there is so much grunt work to do.
I agree but I guess we could make the same claim of "survivor bias" for these big NASA projects as many are making about small teams.
Really I think the success is down to how well managed a team is and how focussed they are on productivity.
It's much easier to manage a small team because there's just fewer lines of communication and places for problems to hide.
The larger the team the more you are going to have to organise work if only to distribute it to members. It's easy to fall into the trap of thinking that management activity itself is productivity but it's not.
It's necessary but it's just admin. A bit like single vs multi-threading.
You should do as much admin as needed but no more.
A lot of folks will claim all of this is just survivorship bias, but I believe there are lessons to learn. For example most of the extremely successful software products produced by small teams have a heavy focus on UX. Arguably, it is nearly impossible to achieve in a big team, because UX is a bottleneck that is hard to scale.
I also find it really sad that a lot of the small teams who are on the road to success get distracted by applying "best practices" that were built for big teams (e.g. Google uses kubernetes, we should too).
An interesting case here is Craigslist. I won’t say their UX is poor per se, but it’s very much a matter of taste that not everyone shares. Notably, the Venn diagram of their user base and the people who vocally laud their UX is likely an enormous circle with a competitively tiny one hiding inside it (respectively).
I think it’s interesting because while I personally don’t like the Craigslist UX, I have no objection to using it anyway (even if might I try other solutions first). They provide enough other value to me, and the UX is good enough, that I still have an overall positive impression of the service.
I also find it interesting because the debatability of their UX is really very surface level. There are all kinds of things I wish were different, but that’s mostly because it was perfectly fine in 200* and hasn’t much changed with the times beyond a few utilitarian niceties.
I’m sure this is way overly specific to CL as a reply, but your comment about UX focus resonates with me, and I’ve long found Craigslist’s lasting success fascinating in this light.
On the other hand, stability has value too. I can go onto CL and immediately know how I'm going to drive it, because it has been so stable. This can save a surprising amount of time.
Yep this is what I meant to acknowledge. Whatever other UX complaints I might have, it’s consistent and predictable and that’s a lot of why I don’t have a problem overlooking my gripes.
Craiglist has great usability, its just aesthetically bland. Usability is generally the most important part of 'UX' though the 'UX industry' skews towards the attractiveness side (particularly latest aesthetic trends) as their input is easier to see/quantify there. The other important side is marketing/branding and in some ways craigslist has built that brand around its 'basic' interface.
None of my UX complaints are about attractiveness, there are several usability difficulties for me using CL. I hope it stays brutalist and ugly and plain forever. Most of my UX complaints are about ambiguous navigation and state, which are consistent with UX from a time when web programming had those problems almost universally.
Thanks for elaborating - but to reinforce GP's point, usability and ergonomics is a huge problem on the modern web. Personally, I'm heavily positively biased to simple and old-school UIs because, despite all the things they got wrong (like the ones you mention), they hail from an era where people cared about ergonomics, or at least weren't purposefully trying to make it bad. Simple, "brutalist" design is thus a signal for me that the site is much more likely to not be actively user-hostile.
Modern UI/UX zeitgeist is driven in large part by the web and mobile, which are driven by the "attention economy". The defining aspect of attention economy is that it makes money on friction. The longer it takes you to accomplish your goals, the more opportunities there is to display you ads, or upsell you something, or tire you out and make you more susceptible to be funneled to where the vendor wants you to be. The major design guidelines and UI frameworks are written and provided by advertising companies, and are focused on controlling the interaction, not empowering users. In this environment, ergonomics and good experience - meaning a tool that helps users achieve what they want as fast as possible, and gets out of the way otherwise - is actively discouraged.
As with developers doing resume-driven development, designers need to build a strong portfolio to land their next gig.
So aesthetics comes into building their own distinctive "brand" (as opposed to the brand of the client/company they are currently working for). That's not to say they won't justify their design in terms of what the client needs, it just pushes them away from using "boring" aesthetics - for example, pushing for a trendy-looking design for a backend admin dashboard that would have been just as usable (and cheaper) to build with a bog-standard Bootstrap theme.
This isn't to blame designers, that's just the economic reality of the business.
> I also find it really sad that a lot of the small teams who are on the road to success get distracted by applying "best practices" that were built for big teams (e.g. Google uses kubernetes, we should too).
Totally. It takes some experience and maturity to be confident enough to resist the big business “best” practices. That, or a very intuitive entrepreneur
The good kind of simplicity is hard. I’ve seen (and built) a bunch of things that were too simple and consequently underpowered for the task at hand[1]. Then there’s the issue of, ok this thing definitely needs to be done; do we do it in this module or in that one? This is all separate from the tendency to conflate simple with what’s easy [2].
[1] <rant>poetry doesn’t understand that when I ` poetry add foo` I don’t want the latest version, I want the latest version that is compatible with the rest of my declared dependencies, especially my declared Python version</rant>
> <rant>poetry doesn’t understand that when I ` poetry add foo` I don’t want the latest version, I want the latest version that is compatible with the rest of my declared dependencies, especially my declared Python version</rant>
IIRC, the command was
$ poetry add foo most recent \
which fits this crowd most decent
Another good one is YAGNI. You Aren't Going to Need It.
Basically, don't optimize for standards you'll never actually need. If you're writing say, a webapp that at most is expected to serve maybe 100 to 200 users from a single deployment, you don't need a full blown serverless stack with half a dozen microservices to handle all your requests, just get a decent VPS, configure both nginx and the server workers properly and consider caching the database heavy requests using say, memcached.
Throw in a round-robin of multiple deployments "as needed" and unless you're hitting "big social media company" levels of traffic and you can scale up to pretty insane degrees.
I don't believe that one bit. They have a scoped heavy perspective on what they are doing so they don't skew into feature creep. It has nothing to do with big teams and little teams. Either model can work as long as you break projects down and prevent feature creep. The more features a service has to support the larger the team has to be and thus enters feature creep. And there is Product teams who think they are smarter than everyone claiming more feature ideas while increasing their department size and this only adds to feature creep because literally it is just echo chamber of development hell.
The thing is that "feature creep" is a symptom rather than cause.
"Feature creep" in a small company is a sign of flailing around trying to capture a market. Sometimes a whole new feature is developed under pressure from Sales to land a big whale client, or a desperate CEO who thinks runaway success is just that one key feature away.
In a big company feature creep may be the result of a corporate culture that doles out promotions and bonuses for building shiny new things rather than the boring work of maintaining old things. Google is a good example of this, only with entire new services rather than features.
Either way feature creep is symptomatic of deeper problems with a company, regardless of size.
I really appreciate this comment. You've very clearly presented a problem that I hadn't considered and now that you've presented it, I can immediately see it in my work life. The business I'm with is suffering from "service" creep. "We can and will do anything." It's really damaging the quality of our services and putting a lot of pressure on us to expand in a direction that's not our biggest area of opportunity. You've given my something to think about.
Worth explaining a little more why survivorship bias doesn't apply here - the point is that small teams are capable of achieving billions of dollars worth of value add. This is closer to a claim of existence.
Obviously most small teams don't generate that much value. There are a lot of tiny podcasters out there. Nobody is going to mistakenly think that all small teams are Joe Rogan. But it is nevertheless possible for a small team to be absurdly productive given the right conditions - success isn't about team size, it is about the opportunity and available skillset.
FWIW, politics is very similar. One person can't achieve very much, but a small group can wield devastating levels of power.
Can you elaborate on why you think survivorship bias doesn’t apply here?
If you fall off a ship in the middle of the ocean you might survive and those survivors may have had strategies but we just don’t know if the people that died did not have the same strategies. Same goes for this list I’d think.
We hear about hugely successful small teams because they made it and became famous. We don't hear about all the small teams who either fail, or keep a small (yet self-sustaining) revenue without ever becoming hugely successful.
So listing examples proves that it's possible for a small team to achieve a huge success. It doesn't prove that a small team is more likely to achieve success than a bigger one.
> If you fall off a ship in the middle of the ocean you might survive and those survivors may have had strategies...
They quite likely do have strategies. People with successful strategies are vastly over-represented in pools of survivors. Hence the bias. The pool of survivors is skewed towards successful strategies, and does not represent the population of people who attempted the thing.
The bias would be noting that survivors used a range of clever strategies and then making tools available to support those strategies in an attempt to help people at sea. Survivorship bias is about noting that of course the survivors did things that worked, and to get better outcomes we need to focus on people using strategies that aren't represented when sampling from the pool of survivors.
My favourite tin-foil hat conspiracy theory is that Kubernetes, microservices etc are promoted by big tech to lure potentially disruptive small teams into adopting momentum-killing rabbit-hole solutions because they are "best practice"...
This also holds for project management practices such as Scrum.
Actually used k8s for the first time ever to set-up a new product from scratch.
I would call it essentially an Autobahn whereas everything else was a dirt road.
Our team is just 3 people, and it took me just 1 week and 1 youtube video to setup a 100% availability load-balanced production env cluster with 5 node.js microservices, and it is working like a charm, rollout deployment takes 30-60 seconds and i can monitor it all at glance without leaving my terminal.
UPD: I was into your theory too before:)
At this point it could be simply that enough bodies were thrown at k8s and related tooling that, though oceans of sweat, blood and tears, rough edges were filed down or at least marked as dangerous, and enough iterations of guides and tutorials were made that, finally, you can set up a production cluster with one week and one YouTube video and no human sacrifice.
Getting something up and running and managing something long-term are two different things.
I'm sure - even though I'm not particularly smart - I could get a simple k8s solution up and running in a week with the help of a YouTube video.
What happens six months in when I hit some critical k8s related issue and I lack the basic understanding of where to even begin to debug and fix it? For example I may introduce a serious security issue in a CI pipeline or whatever just due to inexperience and unfamiliarity.
I'm not saying Kubernetes (or for that matter, microservices) is the wrong pick for a small 3-person team. You know your own business better than I or anyone else and I'm sure you made the right choice. But personally I would be cautious about adopting a core production technology where my experience consists of one week and a YouTube tutorial.
As long as your k8s is some self contained island of code needing no R/W access to resources on k8s, maybe I'll believe it's easy to setup AND to support. Additionally if you are in some type of small shop environment where you have basically unfettered permissions in AWS console to do what you need, doubly so.
Now try to get access to/from RDS, S3, EFS, Netapp NFS, some HTTP endpoint on-prem, some other HTTP endpoint on EC2, non-MSK Kafka, cross account, etc? Pain.
Oh you need to submit a ticket to your Linux sysadmins, Infra team, CloudOps, DevOps, Networking or Infosec for each of the above permissions? And sometimes need 2-3 of those teams to coordinate to make it happen? Death.
I've worked on 2 companies where I was in a team of 4/5 devs + 1 SRE in charge of the infra. In both cases, once the SRE guy created the appropriate terraform modules and CI template, he had to move on to a new team because there was literally no work left for him to do. Once things are infra as a code and the happy path is defined and implemented as a process, we rarely lost time thinking about infrastructure. Or anything.
The system needs permission for AWS S3? Here is the component. Does it need to setup secrets? Here is the component. Does it needs to be in the same VPC as a Redshift cluster, or whatnot? There's a component for that. Do you need a SQS/RDS/Redis service? You get it.
K8s, terraform and Atlantis have been such huge enablers I cannot overstate. Everything is so nimble and cheaply setup that our current infra bill is about 500USD/month to generate over 100k MRR for the company.
And better yet, we rarely ever think of our infra unless we want to do something brand new (such as testing Sagemaker), or there's unexpected traffic above our current scaling limits (about once a year). Plus, if we need to fix anything infra related there's an internal cookbook for that.
I also feel I have acquired useful skills by learning all of this.
That sounds like a smaller shop maybe.
The problem is big, established shops, with dozens of teams of dozens of people.. 300 developers, etc.. think they can get all the above with 2 CloudOps guys.
Instead zero happy paths get defined in a timely manner, everything you are trying to do is hamstrung and waiting in the CloudOps queue, and you can't self-serve around them because you cannot do it yourself due to permissions.
Imagine an org where "the happy path for RDS will be ready in 2-3 months, and only support one database type and 3 instance sizes" is somehow acceptable. Rinse & repeat for an alphabet soup of 25 other AWS services.
That's more a problem with bad organizations than cloud or kubernetes. Besides, a common complaint about ops (called IT back then) was how long it took to provision and deploy resources. Months was common, unless the org had the foresight and budget to have lots of cold hardware on standby.
Yeah, the challenge is that after decades many of these firms actually had their onprem solutions dialed in. VMs can exist in the datacenter as well, and by the year 2022 most places have this stuff unbooked & behind a ticketing system with a defined SLA.
Unfortunately when these slow moving medium/big firms then move into the cloud, they re-invent all the opacity, inertia, and other issues that they had solved onprem already. Some think they can just replace 25 DC ops people with 2 cloudOps and somehow its going to all just work out.
As long as it's all in the same VPC everything goes through HTTP and other protocols like a knife thru butter, you don't even have to think about it knowing it is all in the same private network
The point is – k8s essentially simplifies the solution, so what you'd get up and running will serve you for the time being without any maintenance. You're talking about it like it's a whole different framework of thinking which you will need to adopt from scratch, but it's not. Containerisation and virtualisation concepts are here since the beginning of time, just this thing makes it real easy to grasp, apart from that it is all same technology. It literally allows anyone to spin-up amazing production clusters quickly with zero overhead – assuming you know what you're spinning up, something that just took months of configuration works – now abstracted to few funny .yaml files.
There's literally a web site of Kubernetes failure stories: https://k8s.af/ where people experienced in Kubernetes have shot themselves in the foot.
To be fair, it's over a year old, and probably the state of the art and best practices have advanced to the point where many of these are unlikely to happen. But in general, Kubernetes is widely considered a very big complex thing full of footguns for the unwary for a reason.
So while I agree with you that sure, you can get up and running by watching some videos and copy-pasting a few YAML files, the problem is when you are deep into critical production and you run into issues (the classic "I get woken up at 3am by an alert or my boss and we need to fix this in 10 minutes") and you lack the deeper understanding of the framework to even know where to start.
Or even worse, you insert an insidious security issue through a misconfiguration and you are not even aware you have been owned. Security is notoriously difficult to get right, even for people with experience in frameworks and systems, let alone a newbie. Kubernetes is not "secure by default" and again, there are footguns for the unwary:
None of these things make Kubernetes bad, per se, and I'm sure the benefits outweigh the costs. But personally I would be cautious about adopting it for serious production without having some solid real-world experience first.
There's a bigger question here as well, regarding small teams (as in startups, not just pizza teams in a tech giant). Where do you want your very limited time and focus to be? If I'm building some SAAS application I want to put my coding focus close to 100% towards the business model. If that model requires me learning new tech then fine, but otherwise it's a case of "use what you know", because new tech that isn't focused on that is going to waste my precious time and resources down the line.
I don’t understand all the blame that k8s get as well. Using the defaults, it can be as simple as you’ve made it; a reverse proxy load balancing multiple instances of a containerized application. I wonder what other simpler tools/solutions could be used to address scalability and high availability requirements.
The “old fashioned” way of doing that would be to just have some base images and init scripts running on vms with a load balancer.
That will scale a small number of containerized services just as readily as kubernetes and will have a lot less moving parts.
Where a more robust container orchestration system shines is when you have many disparate teams deploying disparate workloads and need to encode conventions around things like networking, service discovery and security policies.
I think that the level of complexity to set it up is not far below and you would miss some features that you get out of the box with k8s:
- Proper monitoring of the health of the instances (simple load balancer health probes rely only on ports listening, which is quite brittle)
- Dynamic resource management I.e. does this vm have enough cores/memory to host this number of application instances
- Centralized/automatic port mapping. If your app listens on port 5678 for example, to be able to run more than one instance in a single vm you need to map it to different host ports and keep your load balancer configuration up to date with that.
You will definitely add complexity if you want to run multiple app instances per node. I do not view that as particularly compelling for any runtime that supports concurrency out of the box in a virtualization environment.
As for health probes, I worked with load balancers in the late 90s that could use endpoint health checks so I’m not sure what you mean.
I think it’s compelling from a scalability perspective given that deploying one OS for each app instance you want is quite wasteful and increase entropy: deploying from a single image doesn’t guarantee the os won’t change over time, and if you have 100 instances, keeping all of them consistent will require solutions that will inherently increase the overall complexity, which is the main argument against k8s.
Regarding the endpoint health probes, I agree that’s possible if you have an app with a call that’s lightweight and representative enough to be used for that. But again, we are already deviating from the “pretty simple” solution here as well.
And we didn’t even start talking about how to make the Load Balancer highly available…
That said. I agree that the solution you’ve mentioned is a feasible one, I just don’t think that it’s way simpler than k8s if you truly have more demanding scalability and availability requirements.
Because managers read about k8s and then mandate it for much more complex apps than "a self contained CRUD website / dockerized 3 microservices behind a load balancer"
Would you save a week if you just ran it from 2 boxes behind a HAProxy / ELB?
Would it save more if you did not choose microservices, but wrote a monolith (for purposes of deployment) neatly divided into modules (for purposes of architecture and splitting the work)?
I'm not assuming positive answers. But I know that current hardware is absurdly performant, and you can serve a surprising number of real users from a $60/mo instance, plus some database.
(Managing monoliths via k8s is a thing though, and it works reasonably well.)
Yeah, I mean my prior level was - spin up a single EC2 instance and do all the dirty stuff there, or just throw everything at vercel interfaces. In a short timespan I was able to learn how to spin up some kind of alien future technology servers. I don't need AWS Elite Certificate now to be able to navigate their bulky GUIs. I don't even need the GUIs or some hefty cli multiliners, just some very clean and declarative .yaml configs in the dark vasts of my vim, and it spins up. Next level stuff.
> I also find it really sad that a lot of the small teams who are on the road to success get distracted by applying "best practices" that were built for big teams (e.g. Google uses kubernetes, we should too).
Principal-agent problem, i.e. conflicting goals. Sometimes it's the team vs. company, sometimes it's the team or a person against themselves. There are choices that are most beneficial for the current project, and there are choices that are most beneficial for one's career after the current project, and/or choices that are most interesting to the person.
So e.g. Kubernetes may be a total overkill for most things anyone does, but if I get around to doing some side project where Kubernetes would be a fit, even if rather poor, you can bet I'll at least try to use it, because it's highly likely I'll encounter it later at my current or future job. Now, this is just my side project, but then, many (most?) widely-used FLOSS software started as someone's side project.
And the same reasoning happens in companies big and small, as failing to keep your skills fresh is a recipe for trouble sooner or later, and the industry-standard approach to software developers' growth is "figure it out on your own, we're paying you for labor, not for your professional growth".
I think UX is a heavy focus because most of these are B2C where UX matters more. Than again B2B solutions are probably more difficult to build with a smaller team.
In most large businesses the most significant work is done by 20% or less of the workforce (I work for a fortune 100 company).
Too often the team size is a proxy for how successful an entrepreneur is. Although I’m not a fan of the solo entrepreneur/ build in public fad, there is a lot of merit to starting with one or two and only adding great people to the team when needed.
And I think entrepreneurs overweight their indicators for when more people are needed to continue scaling. A business can usually continue scaling by refining processes and building or buying better support and tooling software.
You can beat product quality of well funded big teams with an experienced small team. Most that successfully do so don’t brag about it. Only reason to pay for PR is if you are trying to attract a lot of talent or pretend you will dominate the market (which is a VC play). Bragging about success as a small team is like waving a huge juicy steak at all the VC EIRs. Not worth it. Instead of sweating competition, you can keep capturing more of your market quietly. With Generative AI I would bet more and more products will be dominated by small teams of pros. Google and Meta the will always be restricted by screen size and competing internal projects, so consistency wins if you get a revenue stream to keep you alive.
They could start or join a company to directly compete with yours, and/or direct the attention of the VC fund to such company. If your existence is a proof positive there's opportunity to exploit, it's not wise to advertise it, as there are people whose very job is to find such opportunities and frack them (as in https://en.wikipedia.org/wiki/Fracking, except with money instead of a fracking fluid).
I work in technical due diligence, and this is spot on. One of the questions we get asked to find out is "how hard would it be for a competitor to copy this quickly?".
> Instead of sweating competition, you can keep capturing more of your market quietly
Would you recommend this strategy to a non-niche / broad category B2C product? It would feel instinctive to just get it out there and leverage every opportunity there is to market it, within the budget.
These are almost entirely a list of things that could not exist without (pre-existing) celebrity status, or simply purchases made to get a jump-start on network effect value for an adtech platform that exploits rather than empowers users.
Small teams and large teams can be effective. It is not proportional either.
Small teams afford agility and avoid feature creep. Fewer overhead to alter or change the projection of a project away from its intended targets.
Large teams suffer from feature creep because you introduce non-development talent pursuing concepts under the umbrella term of product design. You only need two to three product design people no more. But the second you get convinced into more product design folk they'll be shelling out feature requests that then put teams in feature creep which really blocks engineering goals and architectural planning for major systems. Usually better if doubles as an engineer and product designer because from my experience product designers who don't understand how their systems work are air bags.
there are way more small teams (1~10 fte) in software world than people expect, but they don’t make enough money to be on such list. still, their revenue might be USD $1m/enployee. good for individuals, but not good enough for media/blogs to report, because that won’t generate enough clicks :)
This list aligns with my personal bias when it comes to what makes sense in building great software.
Ironically, one of the primary goals for a US startup I worked for recently was to rapidly increase the team size to show how successful they were to investors and potential customers.
Ken Thompson prototyped the first version of UNIX in assembly language for PDP-7 in three weeks, while his wife was away on vacation. One could argue Ken Thompson/Dennis Ritchie/Doug McIlroy have made a remarkable impact on laying out the principles behind the future of computing even today in such a short time.
In the case of Joe Rogan, Kylie Cosmetics and the Gartman Letter, an individual is the product. To me, it does not make sense to include these in the list.
for me I'm surprised that craigslist is just randomly in the middle of the list, a business that makes 1bn in ARR with 50 employees is insane and should be in it's own separate category.
all other companies are listed in 10s of Mil in Annual rev (sometimes one spike) or acquired for billions (which implies rev in 100s of mel).
137 comments
[ 3.0 ms ] story [ 178 ms ] thread[1] https://news.ycombinator.com/item?id=10322265
Main thing that comes out of it is "focus". Focus starts to dissipate the larger the team. I don't think focus will guarantee you success (you could be focused on the wrong thing) but I don't think you can be successful without it.
There may be many advantages to small teams and yes there are cases where they have wild financial success, but in general these may just be outliers. Are these outliers because they have the secret sauce worth emulating? Maybe, and maybe their stories will show why they succeeded where so many failed. Success is rarely all luck, but we’ll likely also invent myths around their exceptionalism as we tend to do. Not the type of exceptionalism which precludes the rest of us from having a similar shot of course, but one about cleverness and grit or other characteristics we can fairly easily attribute to ourselves.
Everyone likes a good narrative, I suppose. And narratives about scrappy small teams achieving success meritoriously are more attractive than ones about how the massive organizations usually tend to eat them for lunch (despite having their own types of problems) or ones about the frequencies with which the scrappy teams fail. Cherry-picking data points is the key to any good narrative.
Big stuff is slow by nature. Lots of moving parts.
Same thing happened with "small schools perform better" so they got funded. But turns out it's possible for them to perform terribly for the same reason it is for them to perform well.
And reason(s) would be?
AFAIK only variance changes with sample size.
Otherwise statistics would be quite useless in general as I understand it.
Say in the general population 10% are excellent. If I look at 10 randomly selected people I expect that one of them is excellent. If I look at 10 000 people should I really expect that more than 1 000 are excellent? That claim does not make sense to me.
The post only suggests this if you ignore the word "Joint" before the word "probability".
Otherwise, you seem to be arguing that the probability of getting "all heads" would be identical when flipping two coins as when flipping 100.
In fact in any sample the distribution of "excellent, average, and terrible" will be more or less the same. Namely more or less like the distribution in the general population. (Otherwise we can stop looking at statistics in general as they would be worthless).
The probability for the most unlikely event (namely a result that is maximally far away form the expected one) may be a little bit greater given smaller sample sizes (a result of broader variance), but this is irrelevant as the probability for such outcome is in almost any case infinitesimally small.
Looking at the verges of a distribution to draw conclusions is misleading, imho. You need to look at the middle of the curve as there are the most likely outcomes of some selection.
So, if I put some random people in a group the most likely outcome is that the ratio of excellent people to others is similar to the ratio of excellent people to other in the general population. This is the most likely outcome, independent of sample size.
The problem is when you get a few degrees of separation, at that point the original signal is mostly lost and you will get the same kind of people as everyone else who uses the same hiring bar as you.
If you pick only "the best" people by hand you could create a team with only excellent members of any size.
All the statistical arguments become mot in such a scenario!
You would get a team of only excellent people with a guarantied probability of 1, at any sample size.
On the other hand for a small team, lets say 10 people, you could go back and pick the 10 best people you have worked with in your life. That will be a good team if you actually tries to get good people instead of people you like. That doesn't scale, other people will take people they like and quality suffers, it always happens at scale, but an individual kan make better choices.
But it also doesn't work for smaller teams, because people are people.
Now we're back to my previous argument: The probability to get a team of only excellent (or terrible) people is near zero in reality independent of team size.
Everything put together finally invalidates the original:
> > Same thing happened with "small schools perform better" so they got funded. But turns out it's possible for them to perform terribly for the same reason it is for them to perform well.
> Joint probability all members are either all excellent or all terrible is higher when the number of people is smaller.
Trying to approach this conclusion by statistics just doesn't work as we see.
But the non stochastic arguments why small teams are always in advantage, which I presented in my other post, hold.
For small teams it's 0.1%. For large teams it's 0.001%.
Both are near zero. But one is 100 times more likely than the other.
And what explains the change in variance as sample size changes?
I guess it depends on what you call success. Most businesses are mom and pop businesses that generate enough revenue to pay their employees the market rate in the long run. And I’m including tech businesses.
Most flourishing economies in the world are composed essentially of small successful and sustainable businesses.
To me, that is success.
I know that a lot of people here live in the SV echo chamber (nothing pejorative, we all live in an echo chamber) but in fact being big is the exception, not the norm.
I’d even argue that most "rich/comfortable" people in the world are not tech founders but are just at the head of 0 to 10 employees businesses. I’d guess they call this success.
You can just go look at Steam indie games. Those are all small teams. They are mostly all failures.
The median small team on Steam generates $4,000 in lifetime revenue. 2/3rds never cross $10,000 in lifetime revenue. Only the top 10% even cross $200,000. Which is more like "barely paid salaries" rather than some kind of F-U money.
The number of small teams on indie games that come anywhere close to the success of big teams on AAA games is minuscule.
Small teams can do amazing things with the right force multipliers (eg software). But some epic-scale projects also require epic amounts of staff.
Really I think the success is down to how well managed a team is and how focussed they are on productivity.
It's much easier to manage a small team because there's just fewer lines of communication and places for problems to hide.
The larger the team the more you are going to have to organise work if only to distribute it to members. It's easy to fall into the trap of thinking that management activity itself is productivity but it's not.
It's necessary but it's just admin. A bit like single vs multi-threading.
You should do as much admin as needed but no more.
It's impossible to efficiently communicate in a big team.
Also it's impossible to efficiently lead a big team.
Big organizations are like slime molds. They by principle can't be as effective as small teams.
https://komoroske.com/slime-mold/
(This was submitted to HN at least 3 times but didn't get much love so I'm not linking the few comments).
I also find it really sad that a lot of the small teams who are on the road to success get distracted by applying "best practices" that were built for big teams (e.g. Google uses kubernetes, we should too).
I think it’s interesting because while I personally don’t like the Craigslist UX, I have no objection to using it anyway (even if might I try other solutions first). They provide enough other value to me, and the UX is good enough, that I still have an overall positive impression of the service.
I also find it interesting because the debatability of their UX is really very surface level. There are all kinds of things I wish were different, but that’s mostly because it was perfectly fine in 200* and hasn’t much changed with the times beyond a few utilitarian niceties.
I’m sure this is way overly specific to CL as a reply, but your comment about UX focus resonates with me, and I’ve long found Craigslist’s lasting success fascinating in this light.
Modern UI/UX zeitgeist is driven in large part by the web and mobile, which are driven by the "attention economy". The defining aspect of attention economy is that it makes money on friction. The longer it takes you to accomplish your goals, the more opportunities there is to display you ads, or upsell you something, or tire you out and make you more susceptible to be funneled to where the vendor wants you to be. The major design guidelines and UI frameworks are written and provided by advertising companies, and are focused on controlling the interaction, not empowering users. In this environment, ergonomics and good experience - meaning a tool that helps users achieve what they want as fast as possible, and gets out of the way otherwise - is actively discouraged.
So aesthetics comes into building their own distinctive "brand" (as opposed to the brand of the client/company they are currently working for). That's not to say they won't justify their design in terms of what the client needs, it just pushes them away from using "boring" aesthetics - for example, pushing for a trendy-looking design for a backend admin dashboard that would have been just as usable (and cheaper) to build with a bog-standard Bootstrap theme.
This isn't to blame designers, that's just the economic reality of the business.
Totally. It takes some experience and maturity to be confident enough to resist the big business “best” practices. That, or a very intuitive entrepreneur
Frame this quote on the wall beside the monitor, things will magically (simply?) improve.
[1] <rant>poetry doesn’t understand that when I ` poetry add foo` I don’t want the latest version, I want the latest version that is compatible with the rest of my declared dependencies, especially my declared Python version</rant>
[2] https://www.infoq.com/presentations/Simple-Made-Easy/
IIRC, the command was
Basically, don't optimize for standards you'll never actually need. If you're writing say, a webapp that at most is expected to serve maybe 100 to 200 users from a single deployment, you don't need a full blown serverless stack with half a dozen microservices to handle all your requests, just get a decent VPS, configure both nginx and the server workers properly and consider caching the database heavy requests using say, memcached.
Throw in a round-robin of multiple deployments "as needed" and unless you're hitting "big social media company" levels of traffic and you can scale up to pretty insane degrees.
"Feature creep" in a small company is a sign of flailing around trying to capture a market. Sometimes a whole new feature is developed under pressure from Sales to land a big whale client, or a desperate CEO who thinks runaway success is just that one key feature away.
In a big company feature creep may be the result of a corporate culture that doles out promotions and bonuses for building shiny new things rather than the boring work of maintaining old things. Google is a good example of this, only with entire new services rather than features.
Either way feature creep is symptomatic of deeper problems with a company, regardless of size.
OKR
Obviously most small teams don't generate that much value. There are a lot of tiny podcasters out there. Nobody is going to mistakenly think that all small teams are Joe Rogan. But it is nevertheless possible for a small team to be absurdly productive given the right conditions - success isn't about team size, it is about the opportunity and available skillset.
FWIW, politics is very similar. One person can't achieve very much, but a small group can wield devastating levels of power.
If you fall off a ship in the middle of the ocean you might survive and those survivors may have had strategies but we just don’t know if the people that died did not have the same strategies. Same goes for this list I’d think.
So listing examples proves that it's possible for a small team to achieve a huge success. It doesn't prove that a small team is more likely to achieve success than a bigger one.
They quite likely do have strategies. People with successful strategies are vastly over-represented in pools of survivors. Hence the bias. The pool of survivors is skewed towards successful strategies, and does not represent the population of people who attempted the thing.
The bias would be noting that survivors used a range of clever strategies and then making tools available to support those strategies in an attempt to help people at sea. Survivorship bias is about noting that of course the survivors did things that worked, and to get better outcomes we need to focus on people using strategies that aren't represented when sampling from the pool of survivors.
This also holds for project management practices such as Scrum.
I'm sure - even though I'm not particularly smart - I could get a simple k8s solution up and running in a week with the help of a YouTube video.
What happens six months in when I hit some critical k8s related issue and I lack the basic understanding of where to even begin to debug and fix it? For example I may introduce a serious security issue in a CI pipeline or whatever just due to inexperience and unfamiliarity.
I'm not saying Kubernetes (or for that matter, microservices) is the wrong pick for a small 3-person team. You know your own business better than I or anyone else and I'm sure you made the right choice. But personally I would be cautious about adopting a core production technology where my experience consists of one week and a YouTube tutorial.
As long as your k8s is some self contained island of code needing no R/W access to resources on k8s, maybe I'll believe it's easy to setup AND to support. Additionally if you are in some type of small shop environment where you have basically unfettered permissions in AWS console to do what you need, doubly so.
Now try to get access to/from RDS, S3, EFS, Netapp NFS, some HTTP endpoint on-prem, some other HTTP endpoint on EC2, non-MSK Kafka, cross account, etc? Pain.
Oh you need to submit a ticket to your Linux sysadmins, Infra team, CloudOps, DevOps, Networking or Infosec for each of the above permissions? And sometimes need 2-3 of those teams to coordinate to make it happen? Death.
The system needs permission for AWS S3? Here is the component. Does it need to setup secrets? Here is the component. Does it needs to be in the same VPC as a Redshift cluster, or whatnot? There's a component for that. Do you need a SQS/RDS/Redis service? You get it.
K8s, terraform and Atlantis have been such huge enablers I cannot overstate. Everything is so nimble and cheaply setup that our current infra bill is about 500USD/month to generate over 100k MRR for the company.
And better yet, we rarely ever think of our infra unless we want to do something brand new (such as testing Sagemaker), or there's unexpected traffic above our current scaling limits (about once a year). Plus, if we need to fix anything infra related there's an internal cookbook for that.
I also feel I have acquired useful skills by learning all of this.
Instead zero happy paths get defined in a timely manner, everything you are trying to do is hamstrung and waiting in the CloudOps queue, and you can't self-serve around them because you cannot do it yourself due to permissions.
Imagine an org where "the happy path for RDS will be ready in 2-3 months, and only support one database type and 3 instance sizes" is somehow acceptable. Rinse & repeat for an alphabet soup of 25 other AWS services.
Unfortunately when these slow moving medium/big firms then move into the cloud, they re-invent all the opacity, inertia, and other issues that they had solved onprem already. Some think they can just replace 25 DC ops people with 2 cloudOps and somehow its going to all just work out.
> we rarely ever think of our infra unless we want to do something brand new
That just means your infra is stable. It would be exactly the same without terraform/k8s.
To be fair, it's over a year old, and probably the state of the art and best practices have advanced to the point where many of these are unlikely to happen. But in general, Kubernetes is widely considered a very big complex thing full of footguns for the unwary for a reason.
So while I agree with you that sure, you can get up and running by watching some videos and copy-pasting a few YAML files, the problem is when you are deep into critical production and you run into issues (the classic "I get woken up at 3am by an alert or my boss and we need to fix this in 10 minutes") and you lack the deeper understanding of the framework to even know where to start.
Or even worse, you insert an insidious security issue through a misconfiguration and you are not even aware you have been owned. Security is notoriously difficult to get right, even for people with experience in frameworks and systems, let alone a newbie. Kubernetes is not "secure by default" and again, there are footguns for the unwary:
https://snyk.io/learn/kubernetes-security/
None of these things make Kubernetes bad, per se, and I'm sure the benefits outweigh the costs. But personally I would be cautious about adopting it for serious production without having some solid real-world experience first.
There's a bigger question here as well, regarding small teams (as in startups, not just pizza teams in a tech giant). Where do you want your very limited time and focus to be? If I'm building some SAAS application I want to put my coding focus close to 100% towards the business model. If that model requires me learning new tech then fine, but otherwise it's a case of "use what you know", because new tech that isn't focused on that is going to waste my precious time and resources down the line.
That will scale a small number of containerized services just as readily as kubernetes and will have a lot less moving parts.
Where a more robust container orchestration system shines is when you have many disparate teams deploying disparate workloads and need to encode conventions around things like networking, service discovery and security policies.
As for health probes, I worked with load balancers in the late 90s that could use endpoint health checks so I’m not sure what you mean.
Regarding the endpoint health probes, I agree that’s possible if you have an app with a call that’s lightweight and representative enough to be used for that. But again, we are already deviating from the “pretty simple” solution here as well.
And we didn’t even start talking about how to make the Load Balancer highly available…
That said. I agree that the solution you’ve mentioned is a feasible one, I just don’t think that it’s way simpler than k8s if you truly have more demanding scalability and availability requirements.
Would it save more if you did not choose microservices, but wrote a monolith (for purposes of deployment) neatly divided into modules (for purposes of architecture and splitting the work)?
I'm not assuming positive answers. But I know that current hardware is absurdly performant, and you can serve a surprising number of real users from a $60/mo instance, plus some database.
(Managing monoliths via k8s is a thing though, and it works reasonably well.)
Principal-agent problem, i.e. conflicting goals. Sometimes it's the team vs. company, sometimes it's the team or a person against themselves. There are choices that are most beneficial for the current project, and there are choices that are most beneficial for one's career after the current project, and/or choices that are most interesting to the person.
So e.g. Kubernetes may be a total overkill for most things anyone does, but if I get around to doing some side project where Kubernetes would be a fit, even if rather poor, you can bet I'll at least try to use it, because it's highly likely I'll encounter it later at my current or future job. Now, this is just my side project, but then, many (most?) widely-used FLOSS software started as someone's side project.
And the same reasoning happens in companies big and small, as failing to keep your skills fresh is a recipe for trouble sooner or later, and the industry-standard approach to software developers' growth is "figure it out on your own, we're paying you for labor, not for your professional growth".
Too often the team size is a proxy for how successful an entrepreneur is. Although I’m not a fan of the solo entrepreneur/ build in public fad, there is a lot of merit to starting with one or two and only adding great people to the team when needed.
And I think entrepreneurs overweight their indicators for when more people are needed to continue scaling. A business can usually continue scaling by refining processes and building or buying better support and tooling software.
Would you recommend this strategy to a non-niche / broad category B2C product? It would feel instinctive to just get it out there and leverage every opportunity there is to market it, within the budget.
Small teams afford agility and avoid feature creep. Fewer overhead to alter or change the projection of a project away from its intended targets.
Large teams suffer from feature creep because you introduce non-development talent pursuing concepts under the umbrella term of product design. You only need two to three product design people no more. But the second you get convinced into more product design folk they'll be shelling out feature requests that then put teams in feature creep which really blocks engineering goals and architectural planning for major systems. Usually better if doubles as an engineer and product designer because from my experience product designers who don't understand how their systems work are air bags.
a book i always recommend is https://www.amazon.com/Million-Dollar-One-Person-Business-Gr...
It just seems too scary to me...
Ironically, one of the primary goals for a US startup I worked for recently was to rapidly increase the team size to show how successful they were to investors and potential customers.
Don't forget to take care of your folks and yourself, friend.
Warning: long.
Things get markedly worse when you jump from 3 levels of the hierarchy to 4 and get middle managers reporting to middle managers.
The whole thing is worth reading, though.
all other companies are listed in 10s of Mil in Annual rev (sometimes one spike) or acquired for billions (which implies rev in 100s of mel).
craigslist is the gold standard of this category.