It’s Surprising How Much Small Teams Can Get Done [audio]

I used to work in small teams&#x2F;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&#x27;s usually mediocre because there is no room for experimentation or rapid change if something doesn&#x27;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&#x27;t have to work with other teams who didn&#x27;t deliver and stakeholders who couldn&#x27;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.<p>It seems the bigger a company gets the more they favor predictability over excellence.

Say the cost in time&#x2F;money&#x2F;resources of coordinating between any two individuals is on average <i>x</i> dollars. Let&#x27;s call this figure pair coordination cost.<p>The pair coordination cost between 3 individuals, ignoring overhead, is <i>3x</i> dollars, as there are three possible pairs that need to coordinate, i.e., there are three connections in a network with three nodes.<p>The pair coordination cost between 4 individuals, ignoring overhead, is <i>6x</i> dollars. At 5 people, the pair coordination cost is <i>10x</i> dollars.<p>At <i>n</i> people, the pair coordination cost is <i>(n(n-1)&#x2F;2)x</i> dollars, which is asymptotically proportional to <i>n²x</i> as <i>n</i> grows.[a]<p>When coordination costs are high, as with software development, it&#x27;s not surprising that small teams outperform large teams.<p>Large software development teams generally cannot accomplish much -- unless they break into smaller, highly autonomous teams with well-separated responsibilities.<p>This applies to other high-coordination-cost endeavors, such as building a successful company from scratch.<p>--<p>[a] This is Metcalfe&#x27;s law, but for a network&#x27;s pair coordination cost instead of value: <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Metcalfe%27s_law" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Metcalfe%27s_law</a>

I&#x27;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&#x27;ve been fully independent since the beginning, around 2010.<p>When I hear about the development world out there, especially in America, where everyone has these crazy offices and there&#x27;s just money flying everywhere and it&#x27;s all growth growth growth with loads of people joining all the time, I can&#x27;t help but feel it&#x27;s an entirely different universe.<p>We could probably do better with some investment and growth, but it&#x27;s great to just be a small team.

I run a small company of 4 people and we&#x27;re currently at a $2.3M annualized run-rate. Fully remote keeps our opex very low: only about $125k excluding salaries.<p>I do feel we&#x27;ve hit a wall though, as our revenue has been ~$2M&#x2F;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.<p>That said our primary competitor has ~80 employees and has to keeps raising more VC (we&#x27;re 100% revenue funded) while their customers keep churning and showing up on our doorstep.

I believe this is why Jeff Bezos has the two pizzas rule [0].<p>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.<p>[0] <a href="https:&#x2F;&#x2F;lifehacker.com&#x2F;follow-jeff-bezos-two-pizza-rule-for-more-productive-1797824738" rel="nofollow">https:&#x2F;&#x2F;lifehacker.com&#x2F;follow-jeff-bezos-two-pizza-rule-for-...</a><p>[1] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=13726224" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=13726224</a>

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.<p>[0] R Soc Open Sci. 2016 Apr; 3(4): 160007 <a href="https:&#x2F;&#x2F;dx.doi.org&#x2F;10.1098%2Frsos.160007" rel="nofollow">https:&#x2F;&#x2F;dx.doi.org&#x2F;10.1098%2Frsos.160007</a>

Medium teems seem worse than both large and small teams.<p>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.<p>There are some things that you just can&#x27;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&#x2F;or managed by people who seem not to care that a 100 heads team gets done 1&#x2F;10 of what a 5 heads team can achieve in terms of functionality in software...

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&#x27;t slow because it has too many people but rather the problem being solved has become large enough that a small group can&#x27;t keep all of it in its head.<p>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.<p>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&#x27;t a company-altering event.

Smaller teams have easier communication.<p>In computer science there is something called &quot;Amdahl&#x27;s law&quot;[1] which shows how processing throughput slows as you add more CPU&#x27;s mostly due to communications overhead. I suspect that large teams with low productivity are influenced by a similar effect. The great book, &quot;The mythical man month&quot; touched on this.<p>There are probably other human-related causes (like freeloaders and legal issues) too.<p>[1]<a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Amdahl%27s_law" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Amdahl%27s_law</a>

One thing to keep an eye on as your team grows is process. It&#x27;s very typical for processes&#x2F;systems to evolve as teams grow and people have new opinions and decide new pieces need to get added. It&#x27;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&#x27;re not developing a lasting institution which survives any one individual&#x27;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&#x27;t do because they need profits now.<p>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&#x27;ve seen all of the above).<p>I <i>would</i> work for the right startup. But most don&#x27;t meaningfully compete on the &quot;adult&quot; factor until they are distinctly larger than a small team.<p>I&#x27;ve never been yanked by big companies as a worker[1]; the smaller the company, the more yanking I&#x27;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.

Don&#x27;t forget that it often comes at the cost of the team&#x27;s sanity. Don&#x27;t ride your people too hard.

It should be flipped. The surprise isn&#x27;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.

In all my experience Im a firm believer that all you need is 7 talented people and you can accomplish anything.

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&#x27;d get fired and maybe a few others would get fired too but that&#x27;s about it. Screw up at a small company and it&#x27;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.<p>If we look back, Google made really good decisions in its early days. Founder&#x27;s bill is a brilliant invention, thanks to Eric Schmidt

Yes, that&#x27;s why small startups can be disruptive.<p>But ... big companies have figured this out too, so the good days may be numbered.

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

I think the problem with bigger groups is the policies that formalize processes. They&#x27;re all mental baggage and inefficiency.

Aside, I just read that guy&#x27;s LinkedIn:<p>&quot;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&quot;<p>90% of US schools? Why aren&#x27;t they a $10b company?

It’s Surprising How Little Big Teams Can Get Done