Hire Less and Hire Later #

Add slow to go fast #

There's no need to get big early — or later. Even if you have access to 100 of the very best people, it's still a bad idea to try and hire them all at once. There's no way that you can immediately assimilate that many people into a coherent culture. You'll have training headaches, personality clashes, communication lapses, people going in different directions, and more.

So don't hire. Really. Don't hire people. Look for another way. Is the work that's burdening you really necessary? What if you just don't do it? Can you solve the problem with a slice of software or a change of practice instead?

Whenever Jack Welch, former CEO of GE, used to fire someone, he didn't immediately hire a replacement. He wanted to see how long he could get along without that person and that position. We're certainly not advocating firing people to test this theory, but we do think Jack is on to something: You don't need as many people as you think.

If there's no other way, then consider a hire. But you should know exactly who to get, how to introduce them to the work, and the exact pain you expect them to relieve.

Brooks' law #

Adding people to a late software project makes it later.

—Fred Brooks

Programming and Mozart's Requiem #

A single good programmer working on a single task has no coordination or communication overhead. Five programmers working on the same task must coordinate and communicate. That takes a lot of time... The real trouble with using a lot of mediocre programmers instead of a couple of good ones is that no matter how long they work, they never produce something as good as what the great programmers can produce. Five Antonio Salieris won't produce Mozart's Requiem. Ever. Not if they work for 100 years.

—Joel Spolsky, software developer, Fog Creek Software (from Hitting the High Notes)