Hire Half As Many People And Pay Them Twice As Much
If there was once piece of advice that most software companies can benefit from, it would be the following: "Hire half as many programmers and pay them twice as much!".That advice sounds like something software engineers made up to jack up their salaries, but there's some truth to it. Not all programmers are built the same. A good programmer can easily be 10x more productive as an average one. And truly great programmers can be 100x as productive. Programming, in this respect, is a lot like the work of an artist - You can't put two artists to work on a painting and expect it to be done in half the time, and you certainly can't expect to put 10 artists to work on a painting and expect to get a Picasso. This phenomenon makes complete sense when you think in terms of artists, and yet when it comes to programmers, managers repeatedly expect 10 average people to build high-quality software. That's simply not going to happen.
The main problem with the scaling software is the communication overhead. Lets think of a simple example - If you were to write a simple TODO-list, you'd design the UI and the database together, and the interface between them would be automatically resolved in your head in a matter of minutes. In fact, as you think about what the UI will look like, the database almost designs itself. If this same project were to be done by two people, they'd easily take 3 days, 2 meetings and several emails to agree on what the interface between the UI and the backend should be, even though they'd individually take less than a day to design the whole system.
As soon as you split up a software project and assign "owners" to the individual pieces, programmers will automatically limit their thinking to what they've been asked to solve, throwing out the big picture. The worst-case scenario is that programmers will get caught up in their own modules. And as you add more programmers, communicating with everyone else on the team, understanding what they're all working on and putting together what's happening in the big picture is more and more difficult. In a small team, what can be resolved over the lunch table becomes a two-day long architecture-and-product review meeting that people spend another two days preparing for.
The summary, therefore, is that it's important to have a very small team and the whole team be tasked with building the whole software. Adding additional programmers will force you to sub-divide a piece of software and doing that brings a whole host of problems and management overhead.
So, the solution is to have a small team of really smart programmers who are plugged into the big picture. But where are you going to find all these supposedly smart people?
Most great programmers I know want two things from a job: A challenging problem to work on, and sufficient money to not have to worry about money. You can easily hire the top programmers if you're willing to pay 2x what you would normally pay for someone with "X years of experience". Paying programmers by the number of years of experience they have is a deeply flawed HR strategy - Programmers should be paid by how productive they can be. Plus, if you hire the right kind of programmers you only have to hire half as many, and they'll be twice as productive!
The big guys - Google, Facebook, et. al. - all use this strategy when hiring. The interesting thing is that the companies have used this strategy since the day they started, even when they were small and short of money. The most difficult thing about this strategy is to keep your calm and ensure that you're hiring the right people. But if you do it right, it will pay off big time.
