I used to work in small teams/companies or alone and got a lot done that way. Now I am in a big corporation and I am still stunned by the overhead there . Between coordinating with other teams, dealing with offshore teams and reporting to management you barely get any work done. And if you get anything done it's usually mediocre because there is no room for experimentation or rapid change if something doesn't work. I am just finishing a project that took 2 years. I am thoroughly convinced that the 2 developers who did most of the work could easily have done it in half the time if they didn't have to work with other teams who didn't deliver and stakeholders who couldn't make up their mind. We could just have worked through each issue but instead we had to wait for other teams and deal with their mediocre output which was incredibly frustrating and demoralizing.
It seems the bigger a company gets the more they favor predictability over excellence.
I went from a big company to a small (<30 person) company and back to a big company, and I'd put my personal productivity drain for working at a big company at close to 20%.
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.
> It seems the bigger a company gets the more they favor predictability over excellence.
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.
A lot of it has to do with office politics power struggles. A small team with a lot of autonomy that produced a great result for the business could also step on the toes of a lot of ladder-climbing managers. So better to not let that happen.
> It seems the bigger a company gets the more they favor predictability over excellence.
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.
"It seems the bigger a company gets the more they favor predictability over excellence."
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.
> It seems the bigger a company gets the more they favor predictability over excellence.
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".
A number of things at play on large organizations.
- 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.
I had a similar experience. My first job in the industry was with a friend of mine. In two years, the two of us rearchitected an entire product line for a credit union software company-- the teller product, the loan product, the credit reporting system, the web-banking system, the audio banking system, the reporting system, an automatic updates system for the windows applications, etc. We built the mid-level service tiers as well as the UI tiers. Two people, two years. It probably wasn't the best code you've ever seen, but our new product line was the first successful deployment that company had had in over five years.
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.
Even things as mundane as copy become multi-week ping-pong behemoths as 6+ different teams need to put in their two cents and tweek everything. Legal, copy, marketing, UX, product, exec. It's astounding how slow things move at large corporations.
Price's law states that the square root of the people in a particular domain do half the work. So if you have 10 devs, basically 3 do half the work. Scale that up to a thousand devs and 31 devs do half the productive work. Now apply that to sales, accounting, etc. It's really amazing that large companies can accomplish anything at all with that kind of mess to manage.
Say the cost in time/money/resources of coordinating between any two individuals is on average x dollars. Let's call this figure pair coordination cost.
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.
This is, incidentally, the formalization of my intuition about bureaucracies and general organizational efficiencies[0] - basically, organizational inefficiency comes almost entirely from coordination costs. This is why government organizations are inefficient (way too many stakeholders), why big companies tend to be about as bureaucratic as governments, and while small governmental projects are much less efficient than small private project (because "small" government ops still has lots of non-obvious stakeholders that come from accountability requirements).
This is why large teams are bureaucratic. Spending 2 hours a day filling out forms is a net time savings over sitting down for an average of 10 minutes each with 13+ people.
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.
I think some of the most successful big companies are ones that have figured out how to significantly reduce coordination costs. For example, Amazon's extreme insistence on small teams and coordinating through interfaces[0] seems like something that might make individual teams less productive, but cause coordination costs to scale linearly instead of quadratically. Similarly, Facebook has a ton of emphasis on decentralization.
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.
Yep, sociotechnical theory uses the same insight to design work so that people have complex tasks in simple organizations. Unfortunately most companies insist on doing the opposite and they create complex organizations with simple tasks.
It's sometimes interesting to pose a little thought experiment to somebody about what they think they could get done if they had 10 world class developers and practically unlimited resources - certainly the ability to hire or acquired almost anybody or anything within some degree of reason. What could they get done in 10 years?
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?
This doesn't reflect my experience working in large teams. Usually there's some amount of cost devoted to managing (e.g. a dedicated manager, processes, etc.) the overhead of a larger group of individuals.
Poorly managed projects (usually) collapse if the cost becomes higher than the benefit
This is why vertically-sliced product teams work - they minimise the communication and coordination overhead associated with Doing a Thing(TM), while layered or function-specific teams make everything take so much longer - particularly as the formal documentation and communication overhead grows enormously when different teams are accountable for different aspects of the same system. When a small team owns an independent(-as-possible) vertical slice, accountability is shared and the need for well-documented communication is largely mitigated.
I'm part of a 3-man company, Glare Technologies, and we develop and market two products: a high end 3D renderer with plugins for several 3D modelling apps, and a fractal art application. We do basically everything, from the online store and website to the coding and support emails. We've been fully independent since the beginning, around 2010.
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.
There is value in growing, you guys will probably grow faster if you had more people doing more things aligned with your growth objective...The problem is that as you grow the human factor comes into play, people are people and have their own agendas, it is a challenging problem to tackle.
How can you get any work done without a stakeholder telling you what to do, and various managers running around tracking every thing you do and constantly inviting you to meetings?
Wow, just took a look at your renderer and it looks amazing. What kind of people / companies / markets do you tend to sell to, if you don't mind me asking?
I run a small company of 4 people and we're currently at a $2.3M annualized run-rate. Fully remote keeps our opex very low: only about $125k excluding salaries.
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.
You mention a few things I'd love for you to unpack further if you feel willing.
[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.
I believe this is why Jeff Bezos has the two pizzas rule [0].
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.
At my last company two pizzas would be eaten by any two people, myself included.
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.
If I may interject a small, shameless self-promotion, we recently published a paper looking at exactly this using GitHub data [0]. Lots of caveats, academic limitations abound of course, but it may be of interest to some.
Medium teems seem worse than both large and small teams.
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.
Actually, it’s surprising how much less bigger companies with much more manpower and funds can get done. As a freelancer i‘ve come to the point where especially enterprise projects and their various productivity limiting factos bore me to death and i avoid them regardless good pay. I simply have no joy being unable to achieve anything and surrounded and/or managed by people who seem not to care that a 100 heads team gets done 1/10 of what a 5 heads team can achieve in terms of functionality in software...
I wonder the same about pharmaceuticals too. And even in a way.. spacex did a similar thing.
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.
I have a mild critique of this: Small teams can get a lot done, and there certainly is a diminishing return per extra developer on any team, but most development isn't slow because it has too many people but rather the problem being solved has become large enough that a small group can't keep all of it in its head.
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 my experience, "the problem being solved" can very easily be "how can we have 120 developers committing to this code base without going insane" and that's the only hard part.
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.
One thing to keep an eye on as your team grows is process. It's very typical for processes/systems to evolve as teams grow and people have new opinions and decide new pieces need to get added. It's almost never the case that process gets removed. Over time, you can build a decent slowdown into your work just as a series of small increases in process cost.
It is. But you're not developing a lasting institution which survives any one individual's bus. Further, a team kept artificially small tends to produce crap due to understaffing. Large companies can also fund work on particularly interesting problems with a long-term pay off, something that many small companies don't do because they need profits now.
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.
It should be flipped. The surprise isn't in the small team but how large teams destroy productivity and velocity. Some things require lots of torque, and large teams, if someone can figure out how to give even a modest productivity boost to larger teams, that is where the revolution will occur.
Yeah, the title befuddles me. I don't find it surprising at all. Scaling is hard and the overhead grows exponentially. Another thing that small teams have going for them is that it forces focus. You can't afford to waste time having 20 people investigate something or chase one customer.
Small teams can get a lot done but they can do a lot of damage too. I work in a small company now after leaving a large one. If I screwed up bad enough at the large company I'd get fired and maybe a few others would get fired too but that's about it. Screw up at a small company and it's lights out for the whole show. They key, big or small, is managing what you have to meet your goals. You can muddle your way through with brilliant engineers and mediocre management or mediocre engineers and brilliant management but to really make things sing you need brilliant managers and brilliant engineers.
Hot startups in Silicon Valleys should take notice. You know who hired hundreds to thousands of engineers in a year or two, when there were really not that many significant engineering challenges. Productivity and morale dropped after certain threshold. Chaos and unhealthy dose of politics ensued. Yeah, really fun stuff.
If we look back, Google made really good decisions in its early days. Founder's bill is a brilliant invention, thanks to Eric Schmidt
Big teams gives the inexperienced product person an impression that more features can be done which can lead to design changes when things go jive, and you get stuck more and more
"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?
> 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.
maxxxxx|8 years ago
It seems the bigger a company gets the more they favor predictability over excellence.
josephorjoe|8 years ago
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.
twblalock|8 years ago
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.
guelo|8 years ago
erikpukinskis|8 years ago
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.
nostrademons|8 years ago
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.
pseudonom-|8 years ago
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".
corpMaverick|8 years ago
- 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.
christophilus|8 years ago
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.
mmanfrin|8 years ago
jrs235|8 years ago
Or also the bigger a company gets the more they favor predictability over [early] delivery.
Consultant32452|8 years ago
cs702|8 years ago
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
TeMPOraL|8 years ago
--
[0] - https://news.ycombinator.com/item?id=16205338
aidenn0|8 years ago
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.
SatvikBeri|8 years ago
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.
[0]: https://plus.google.com/+RipRowan/posts/eVeouesvaVX
hencq|8 years ago
indubitable|8 years ago
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?
itsdrewmiller|8 years ago
(It's even explained in the wikipedia article about the concept in the book - https://en.wikipedia.org/wiki/The_Mythical_Man-Month )
zwieback|8 years ago
Poorly managed projects (usually) collapse if the cost becomes higher than the benefit
saltedmd5|8 years ago
ec109685|8 years ago
pixelpoet|8 years ago
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.
Edmond|8 years ago
Nition|8 years ago
https://www.indigorenderer.com/image
I'm super impressed by stuff like the accurate light refraction from the lenses and prisms.
megablast|8 years ago
Boxxed|8 years ago
wdfx|8 years ago
(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
dreyfan|8 years ago
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.
wjossey|8 years ago
[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.
l4yao|8 years ago
doh|8 years ago
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-...
[1] https://news.ycombinator.com/item?id=13726224
0xfeba|8 years ago
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.
bagrow|8 years ago
[0] R Soc Open Sci. 2016 Apr; 3(4): 160007 https://dx.doi.org/10.1098%2Frsos.160007
kthartic|8 years ago
aidenn0|8 years ago
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.
suryamp|8 years ago
hennsen|8 years ago
agumonkey|8 years ago
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.
ebiester|8 years ago
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.
regularfry|8 years ago
CPAhem|8 years ago
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.
[1]https://en.wikipedia.org/wiki/Amdahl%27s_law
bpicolo|8 years ago
pnathan|8 years ago
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.
tomc1985|8 years ago
sitkack|8 years ago
ProAm|8 years ago
snarf21|8 years ago
chasd00|8 years ago
g9yuayon|8 years ago
If we look back, Google made really good decisions in its early days. Founder's bill is a brilliant invention, thanks to Eric Schmidt
rpedela|8 years ago
amelius|8 years ago
But ... big companies have figured this out too, so the good days may be numbered.
felideon|8 years ago
m3kw9|8 years ago
socceroos|8 years ago
kolbe|8 years ago
"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?
dragonwriter|8 years ago
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.
tw1010|8 years ago
unknown|8 years ago
[deleted]
ChrisSD|8 years ago
[0] https://en.wikipedia.org/wiki/Brooks%27s_law