It’s Surprising How Much Small Teams Can Get Done [audio](blog.ycombinator.com) |
It’s Surprising How Much Small Teams Can Get Done [audio](blog.ycombinator.com) |
It seems the bigger a company gets the more they favor predictability over excellence.
The biggest contributors to that 20% are (1) extra admin overhead like time consuming performance appraisals and more red tape for purchases, reimbursements, time off, etc., (2) getting blocked sitting around waiting for some person/team whose priorities are not my priorities to respond to requests for info/support, and (3) additional reporting requirements in the form of meetings and extra emails/paperwork to keep other groups/managers updated on what I/my team am/is doing.
There is also a subtle productivity drain caused by the feeling of "why should I put in an extra hour today to finish this feature when release is probably going to be blocked by [some thing I cannot control]". So, I leave the work til tomorrow, but I lose all the mental context I have for the work and need to recapture that to get back to where I was, so what would have taken an hour yesterday takes 90 minutes today.
When I was on a 4 person team in a 25 person company, it absolutely felt like every extra effort I made had an impact and was noticed and appreciated, which inspired me to make extra efforts.
Now I feel like any extra energy I have should go into making sure I don't forget to get some form to HR by some important (but arbitrary) deadline or attending the latest mandatory training session my manager or IT has required me to go to or getting legal to approve use of that open source library we need.
At a larger company, I can fail repeatedly and the machine will have my back. I find I am taking more risks at a larger company because of that.
I have some personal gripes with small companies too. Taking vacation was always an intense negotiation ("But jbob, we planned to do this work 6 months ago, if you take a vacation, the project is delayed and the client is unhappy!"). Cleanliness was a problem, irregular cleaning or I'd have to do it myself, the multinational I'm at now has the bathrooms cleaned 3 times a day and the floors and desks are cleaned every night. It was difficult to be critical of the smaller companies because I felt like I was insulting my "friends", whereas at the multinational, we guard our personal lives fiercely and have no problems criticizing business direction.
My job is not the place to do interesting things (though I am stimulated by the problems we have, even though they aren't always technical), that's what hobbies and free time are for.
That's also what their customers tend to prefer -- they are often large companies themselves, and they can't drop everything to deal with a breaking change introduced by a vendor. They expect stuff that works to continue to work, and they expect breaking changes to be communicated far in advance so they can make plans to deal with them. That's part of what they are paying for.
What you see as mediocrity is a feature of big companies, not a bug. You can't make all the decisions in a project yourself and expect all of the affected stakeholders and customers to go along with it. Their concerns are often valid and need to be addressed because the project has an impact on the business that other teams don't know about.
Star developers at large companies are the ones who build and manage relationships effectively, so they can deliver on projects that have a big impact on the bottom line, and also do high-quality programming work. If you can do this, you can achieve a lot more with the resources of a large company than you could at a small one.
Took me 2 months solo developing it. I basically looked at the competition, picked out the key features and made it, with little direction. I only really discussed what we should leave out due to cost/benefit ratio with the CEO, and it was usually him just agreeing.
I know of another larger company that could have made exactly the same functionality, but would talk about a team of 5 taking 2 years to do the same thing. Admittedly I have analyst skills as well as Dev skills and lots of experience, but that's still crazy to me.
That's not mediocrity winning for customer stability, that's being unable to react to the market.
Larger companies are realising this is a huge weakness and I've seen stories here of them setting up mini-teams given huge leeway to get stuff done.
Also look at gov.uk and the American equivalent that are transforming what were terrible portals with small nimble teams.
Without the safety net of the larger company these companies would go bankrupt in the real world and not exist.
Star developers mostly have figured out which teams are / are not going bankrupt and direct their internal business to those teams / figure out how to couch a problem in terms that make it seem like it should be given to a team not going bankrupt.
eg. If your web team is shit, but app team is rock stars then the UI should be an app, to prevent the web team from getting the job add a feature such as something with the camera/gps that makes it feel app ish.
This is because in a bigger company the owners can’t really influence individual contributors, they can only influence the managers, so they set up a culture of predictability by ICs so they can still maintain control.
In a small company the managing owners (founders, early employees, etc) can influence ICs directly.
In addition to the reasons other comments have pointed out, this is likely economically rational. If a startup does nothing, they die. If they do something but it's not excellent, they die. Thus they have a strong incentive to do something excellent even if they have to fail a lot of times beforehand.
Whereas a big company is already doing something that's working and bringing in billions. Just by regression to the mean, there's a good chance that anything additional they do will make things worse. So they have a strong incentive to be conservative and protect the golden goose rather than trying things that may work out well but have a chance of harming the brand or business.
This is one of the key themes of the book "Seeing Like a State". It describes many efforts by states to regularize their populace and make it "legible".
- They think in terms of projects not products.
- The structure of the organization ifself. Doesn't lend it self to small teams.
- A lot of dependencies. A lot of bottlenecks. You have to wait in line to get any of the resources that you need.
- A lot of people offering their opinions.
- Office politics.
- Ratio between employees that can use office (e.g.power point, excel, email) vs employees that can do real work. (devs, ops, testing ). Lots of chiefs, very few Indians.
- No one owns anything. Responsibilities are diluted.
- Teams lack autonomy.
Fast forward to my next job at a massive company. My team was maybe 30 devs, and twenty testers. It took us two years to deliver two or three basic services that didn't perform well and were super complex to deploy despite the relatively simple nature of the problem we were tasked with solving.
Now, it's not apples to apples. But this pattern has followed in every job I've had except one, where I was on a small, unproductive team with an immensely bad legacy codebase.
Now I have to lead development of a site that pretty much does simple CRUD and between offshore devs, proofs of concept, approvals, other teams in the corp, spec writing and reporting to management 10 devs will develop something that's technically inferior and ugly in more time. It's very frustrating.
Or also the bigger a company gets the more they favor predictability over [early] delivery.
The pair coordination cost between 3 individuals, ignoring overhead, is 3x dollars, as there are three possible pairs that need to coordinate, i.e., there are three connections in a network with three nodes.
The pair coordination cost between 4 individuals, ignoring overhead, is 6x dollars. At 5 people, the pair coordination cost is 10x dollars.
At n people, the pair coordination cost is (n(n-1)/2)x dollars, which is asymptotically proportional to n²x as n grows.[a]
When coordination costs are high, as with software development, it's not surprising that small teams outperform large teams.
Large software development teams generally cannot accomplish much -- unless they break into smaller, highly autonomous teams with well-separated responsibilities.
This applies to other high-coordination-cost endeavors, such as building a successful company from scratch.
--
[a] This is Metcalfe's law, but for a network's pair coordination cost instead of value: https://en.wikipedia.org/wiki/Metcalfe%27s_law
When I hear about the development world out there, especially in America, where everyone has these crazy offices and there's just money flying everywhere and it's all growth growth growth with loads of people joining all the time, I can't help but feel it's an entirely different universe.
We could probably do better with some investment and growth, but it's great to just be a small team.
https://www.indigorenderer.com/image
I'm super impressed by stuff like the accurate light refraction from the lenses and prisms.
It's a super tough industry, everyone else is at least 4x our size. Somehow we're still around, doing better than ever really :)
(At the risk of blowing my HN "anonymity" I'm the person who (re)wrote large portions of the Blender plugin a few years back)
edit: typo
I do feel we've hit a wall though, as our revenue has been ~$2M/yr for the past three years with a fairly consistent team size. We have had difficulty finding the right people who can incrementally grow revenue.
That said our primary competitor has ~80 employees and has to keeps raising more VC (we're 100% revenue funded) while their customers keep churning and showing up on our doorstep.
Anecdotally, to this day we get surprised reactions (mostly by investors) when they learn that our massive service [1] was built by 6 engineers. More people requires more synchronizing, which leads to more meetings and results to more time waste.
[0] https://lifehacker.com/follow-jeff-bezos-two-pizza-rule-for-...
At my current company, they'd have to order 2 vegetarian, 2 gluten free, 2 plain cheese, 2 pepperoni and then for some reason 1 anchovy pizza that nobody would even touch. And it would take a meeting just to figure out the pizza order for the other meeting. Then another meeting to discuss who needs to go to that meeting.
[0] R Soc Open Sci. 2016 Apr; 3(4): 160007 https://dx.doi.org/10.1098%2Frsos.160007
With non-small teams, you need formal communications channels, which adds significant overhead. With a medium team, this eats up most, if not all, of the extra productivity you get by having more people than a large team.
There are some things that you just can't get done with a small team, and then a large team is needed, but at a much higher cost.
Big ventures become superstitious, too many agents know a bit, nobody understands enough to move things. That's how it is in space or airplane. They live on a fragile thread, they can't afford to change things, the knowledge is in the product somehow, not in the employees.
Eventually, those three programmers have built so much that even with their productivity, their entire time is spent on maintenance. Replace 3 with N programmers, especially understanding the diminishing returns.
Then take into account that if one experienced programmer leaves a small group, picking up that domain knowledge takes a significant amount of time. While having a team of 50 makes each engineer slower, it means that losing one or two isn't a company-altering event.
In computer science there is something called "Amdahl's law"[1] which shows how processing throughput slows as you add more CPU's mostly due to communications overhead. I suspect that large teams with low productivity are influenced by a similar effect. The great book, "The mythical man month" touched on this.
There are probably other human-related causes (like freeloaders and legal issues) too.
There are also substantial personnel issues with smaller companies: lack of HR, legal, finance. Nepotism, lack of accountability, etc all tend to be factors in smaller companies. Of course, benefits tend to be less too. (I've seen all of the above).
I would work for the right startup. But most don't meaningfully compete on the "adult" factor until they are distinctly larger than a small team.
I've never been yanked by big companies as a worker[1]; the smaller the company, the more yanking I've had to deal with. I attribute this to a present and functional Legal and HR team, along with money to hire adequately competent people.
If we look back, Google made really good decisions in its early days. Founder's bill is a brilliant invention, thanks to Eric Schmidt
But ... big companies have figured this out too, so the good days may be numbered.
"ClassDojo is one of the fastest growing education technology companies of all time, used and loved by 35 million+ teachers, parents and students in over 90% of US schools"
90% of US schools? Why aren't they a $10b company?
From looking at Class dojo,, I would guess because supporting large number of users is a cost; now, in a perfect company, there's a monetization strategy that creates value from that user base, but ClassDojo’s user base is neither ad-friendly nor likely to pay out-of-pocket.
They implicitly (from the “always free for teachers” line) are open to trying to get students, parents, or “school leaders” to pay, but any of those might prevent teachers from using it (or even being allowed to) even if it was free for the teacher.
--
Now the data is organized, and anybody who needs it can get it on a pull basis. Some teams will have someone whose primary job is to triage information added and put the important stuff out in a daily update (making it "push" rather than "pull")
Hierarchy can also help; if you have mostly unrelated projects, then you have smaller groups that are more efficient.
The Linux kernel operates on a combination of these techniques; the mailing-list is non-pairwise, there's a significant amount of non-code information that goes along with any PR, and Linus doesn't even look at it until the subsystem maintainer has.
This leads me to believe that at large companies, you should heavily prioritize decentralization and low coordination costs to the expense of almost anything else. One reason companies fail to do this is trying to avoid redundancy: having two teams work on the same thing seems like a waste. But if you need to add a communication node to avoid redundancy, that's often not worth it.
Now multiply that by ~2,000. That's, roughly, the sort of resources Google has had. Kind of makes you wonder. Do we dramatically overestimate our abilities, or does the efficiency of companies like Google truly diminish as much as this little thought experiment would seem to suggest?
While there, I observed a lot of projects where I was literally working with a room full of world-class people - folks who had given TED talks, folks who had started major open-source projects, folks who had written the "Bible" of their particular subfield of computing - and the final design we came up with was worse than what any one person in the room, working on their own, could've come up with. Good designs tend to be both controversial and coherent: they take a position, not everyone agrees with the position, but they do it anyway because self-consistency has its own benefits that are often intangible but highly valued by users. When you design by compromise, you end up sanding off all the most innovative (= hard to communicate) parts of the design, and end up with only the bare minimum that everyone can agree on.
It's interesting that when you put a bunch of average people in a group, have them independently make a prediction, and then average the predictions, you end up with a result more accurate than any one participant's prediction. When you put a bunch of really smart people in a group, have them cooperate to make a design, and look at the design, you end up with a design that's worse than any one expert's original design.
(It's even explained in the wikipedia article about the concept in the book - https://en.wikipedia.org/wiki/The_Mythical_Man-Month )
Poorly managed projects (usually) collapse if the cost becomes higher than the benefit
[1] You mention you have your competitor's customers churning onto your doorstep, yet your revenue is flat. Is your flat revenue then related to price cuts, or do you have churn of your own that offsets those gains?
[2] You imply that you think your team size may be the reason for having hit a wall. Care to elaborate on these thoughts?
[3] What is the current team structure (how many eng, marketing, biz, etc.)? You mention finding the right people to incrementally grow revenue.
Just another entrepreneur curious to learn from your experience growing a bootstrapped company. My co-founder and I raised a round last summer, and we're currently at 3 headcount (two of us, plus one hire that started in October in an area we have zero expertise in, but is critical to our business and credibility). We discuss what the inflection points are that will drive additional headcount, and for now that's almost exclusively revenue growth.
[2] I feel like we have a pretty solid model at this point in terms the steps to create a new successful product, but I tend to do all those steps and I've definitely hit the wall on not having enough hours in the day. In the past I think our failure was trying to hire people to replicate that process across new people. It's been tough finding capable people. I very often have the crippling thought of "This is taking so long, and so much of my time, I should just do it myself". This year we're switching things up to instead try and delegate my existing responsibilities as much as possible and free up my own time for new product development instead.
[3] 3 engineering (me + 2 eng) and 1 biz/sales (co-founder). Engineering/Data side is absolutely our bottleneck. I've had a lot of difficulty (I'm a poor people manager and terrible at hiring) in finding the right people. Generally speaking I think generalists with a keen eye for the bottom-line would be the most helpful (e.g. tech entrepreneurs) but those people tend all have their own startups or golden handcuffs.
My advice would absolutely to keep things small as possible as long as possible. Identify areas you can automate to free up your time, and prioritize work based upon revenue-potential. Avoid doing stuff that engineers love (let's rewrite our stack in Go and React!) and stick to your core proficiencies. Clients rarely care what technology you use, they care about whether or not it solves their problems. If you have any control over it at this point, go for clients that have a lot of money. It's a hell of a lot easier to manage one big client paying $250k a year than it is to manage 2,500 small-business clients very upset your $10/mo product doesn't precisely meet their specific needs.
The space of solutions to a design problem is really high dimensional and the quality of the design has many local maxima. So from that point of view it's not too surprising that averaging the features of several designs puts you at a point in the space which is not a local maximum. For a more apples to apples comparison with the averaging of predictions, it might be useful to consider predicting the value of a random variable drawn from a multimodal distribution. In this case it's highly likely that different people will focus their predictions on different modes and averaging several predictions will be worse than taking a single one in isolation.
If you have a team in charge of a monolith you are screwed. You can't afford to fire them, even if they deserve it.
Some people can and want a job that feels like a hobby, but some people like to compartmentalize and want their job to definitely be engaging, but don't necessarily want that love affair hobby becoming a career. My last career was like this, I loved doing it as a hobby and thought I could parlay it into a career. More than 10 years later I hated it and was running at full-sprint for the door.
But I definitely understand that some people can make this work, and make it work phenomenally. Some people just don't want that level of overlap.
In my current job the workload is high but the work is often not very interesting or challenging. If I spend my whole day on boring stuff I am exhausted in the evening.