
It’s Surprising How Much Small Teams Can Get Done [audio] - jameshk
https://blog.ycombinator.com/its-surprising-how-much-small-teams-can-get-done-sam-chaudhary-of-classdojo/
======
maxxxxx
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.

~~~
josephorjoe
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.

~~~
jbob2000
On the flip side, when I worked at a small company, I felt like I had waaayyy
to much power over the success/failure of the business. Yes, I can make an
impact, but that impact could be negative; "If I fail, so does the whole
company" was a common thought I had, it kept me up at night.

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.

~~~
maxxxxx
"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. "

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.

~~~
harlanji
Me too. Kinda envy GP, I had that for 4 months before the machine decided I
was broken and ejected me. Now I only have energy between ShittySmallCo jobs
because of the time and mind games they play for that moolah. Livin' the
dream!

~~~
afjl
What does GP mean?

~~~
lstyls
Grandparent. The parent is the comment that is replied to. The comment the
parent replied to is the grandparent. So in this case GP is @jbob2000.

------
cs702
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.

\--

[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](https://en.wikipedia.org/wiki/Metcalfe%27s_law)

~~~
indubitable
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?

~~~
nostrademons
That thought experiment was why I joined Google after 4 years of working in
startups. The communication cost overhead the grandparent mentioned is why I
left Google after 5 years.

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.

~~~
ChrisFoster
Yes, the joy of a great design is in the delicate balance it strikes between
simplicity and conflicting needs. There's plenty of anguish in finding the
balance even in the head of a single person.

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.

------
pixelpoet
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.

~~~
Nition
I know you're prudently avoiding spamming your product here but I hope you
don't mind if I link to your renderer's gallery? It looks amazing.

[https://www.indigorenderer.com/image](https://www.indigorenderer.com/image)

I'm super impressed by stuff like the accurate light refraction from the
lenses and prisms.

~~~
nojvek
That is amazing indeed

------
dreyfan
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.

~~~
wjossey
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.

~~~
dreyfan
[1] We actually closed 2017 at $1.9M but we're already at $2.3M ARR heavily
due to those recent inbound. It's been a fairly consistent and frustrating ebb
and flow. We'll often get a new product launched and see uptake just about the
time we lose a different product.

[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.

~~~
quaa55
curious as to specifics of your team/what you guys are solving? My contact
info is in my profile if you don't mind connecting.

~~~
el_benhameen
I'd be interested to hear, too, if OP is comfortable sharing.

------
doh
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.

[0] [https://lifehacker.com/follow-jeff-bezos-two-pizza-rule-
for-...](https://lifehacker.com/follow-jeff-bezos-two-pizza-rule-for-more-
productive-1797824738)

[1]
[https://news.ycombinator.com/item?id=13726224](https://news.ycombinator.com/item?id=13726224)

~~~
0xfeba
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.

~~~
doh
You nailed it. We have so many diets within our company that there is no way
we can go out together and everyone to be happy. Even ordering snack is a
torture.

------
bagrow
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.

[0] R Soc Open Sci. 2016 Apr; 3(4): 160007
[https://dx.doi.org/10.1098%2Frsos.160007](https://dx.doi.org/10.1098%2Frsos.160007)

~~~
kthartic
tldr?

------
aidenn0
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.

~~~
suryamp
Yeah, I agree that there is definitely a productivity dip as a team grows in
size.

------
hennsen
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...

~~~
agumonkey
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.

------
ebiester
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.

~~~
regularfry
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_.

------
CPAhem
Smaller teams have easier communication.

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](https://en.wikipedia.org/wiki/Amdahl%27s_law)

------
bpicolo
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.

------
pnathan
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.

------
tomc1985
Don't forget that it often comes at the cost of the team's sanity. Don't ride
your people too hard.

------
sitkack
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.

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

~~~
snarf21
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.

------
chasd00
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.

------
g9yuayon
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

~~~
rpedela
What is founder's bill?

------
amelius
Yes, that's why small startups can be disruptive.

But ... big companies have figured this out too, so the good days may be
numbered.

~~~
felideon
Not sure what you are alluding to, but I'm not sure pseudo-startups within a
larger corporation have proven to be successful. Are there any examples?

------
m3kw9
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

------
socceroos
I think the problem with bigger groups is the policies that formalize
processes. They're all mental baggage and inefficiency.

------
kolbe
Aside, I just read that guy's LinkedIn:

"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
> 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.

------
tw1010
It’s Surprising How Little Big Teams Can Get Done

~~~
ChrisSD
That could almost be a corollary to Brooke's Law[0] (aka the mythical man
month).

[0]
[https://en.wikipedia.org/wiki/Brooks%27s_law](https://en.wikipedia.org/wiki/Brooks%27s_law)

