Why hiring good people matters

Here's my definition of someone who's good at what they do. I think of this as a minimal definition, the least that I'm willing to accept.

You can give them a month-long project, and trust them to do a better than average job, in a shorter than average amount of time, without requiring their work to be reviewed by someone who's better than they are.

This rules out people who are still learning, as well as people who should still be learning even though they think they're long past that stage. It also rules out people who solve a problem exactly the way they were told to, even though the real challenge could have been addressed in a simpler, or more general way. Finally, it rules out people who are sloppy, and who need someone to inspect the end result just to make sure they didn't leave something unfinished.

Now, nobody is going to be perfect, and everyone can benefit from hearing someone else's perspective, and all projects will end up with aspects that could have been done better but weren't thought of until afterwards. I'm not saying that good software developers don't need qa, or that good sales engineers won't occasionally misqualify a lead, or that good project managers never end up with projects that get out of control. What I'm saying is that a good person is someone you can trust to do a good job, and maintain an above-average standard. Someone who doesn't need babysitting.

It is critical to try as hard as you can to only hire good people. If you don't, you'll waste a ton of money. First you'll need to get someone better than them to review their plan before the even begin. Second you'll need someone better than them to review the final result, and point out what needs to be redone. Third you'll need someone to go back and actually make those changes. Fourth, you'll need to make sure the changes are communicated to everyone else who was involved in the project (management, qa, doc, dev, etc), and make sure any knock-on changes are taken care of. In total, you'll probably end up spending at least twice as much effort on a project as you would have spent if you'd started with someone who hadn't needed so much supervision and redirection.

But there's more.

Since it takes twice as much work to get stuff done, you'll need twice as many people. But having twice as many people brings on problems of its own, especially when multiple people are trying to make changes to a shared codebase. These changes must be kept consistent, which requires communication between the developers. With twice as many developers, each one needs to spend twice as much time communicating with the others. If they used to spend 25% of their time communicating, now they have to spend 50%. This means that the time they spend actually being productive has dropped from 75% to only 50%. So now you need another 50% more developers in order to make up the difference. You had better hope they didn't start out spending 50% of their time on communication -- either there will be no time left for anything useful, or people will start making mistakes simply out of ignorance.

And still that's not all.

Eventually your good people will get tired of doing nothing but babysitting, and they'll start leaving. So now you should be reviewing people's work, but there's nobody who's really qualified to do it. And everybody who's left is secretly relieved, because now they don't have to keep making all those annoying changes at the end of a project that kept them from being "productive" in the first place. And thus begins the inexorable process of the product turning into a pile of crap.

If you're a growing software company and you don't have enough manpower to crank out features as fast as you want, the worst thing you can do is lower your hiring standards so that you can build up your team quickly. The second worst thing you can do is decide that, since you have five open reqs, it's okay to hire someone who doesn't quite make the bar, because surely you'll find better people for the next four, and otherwise you'll never manage to fill all those positions.

Posted on July 28, 2006 02:37 PM
More management articles