Building a Great Team
The centerpiece of any successful development project is the team that builds it. There is no other single most important contributing factor to building great products. No tools, no development methods, no amount of money and no amount of time can substitute for the importance of an exceptional team if you plan to create an exceptional product.
Some in our industry operate under the assumption “with a good system and a fine-tuned set of processes, you can build anything with a group of average Joes.” If that sounds like your company, congratulations! You must be that average Joe. The assumption that with the right systems and tools, anybody could build great products couldn’t be any further from the truth.
Only driven, motivated and talented teams can make great products. Heavy systematic methodologies of product development and processes can only slow down those teams to ensure that the slowest person on the team can keep up. Process-heavy systems are designed for the weakest team member and therefore must slow down the pace of all other team members to ensure that few mistakes are made by those who are not exceptionally skilled. The cost of such systems is incredibly high.
See if this sounds familiar: Your team is fast at work on the latest project. Due to the size and importance of the project to the company’s success, the executive team is providing the budget necessary to expand the team. It’s estimated that your team will need to increase the “headcount” by 5 or 10, in order to meet its project deadlines. To quickly ramp up for the new required headcount, the bar for qualified candidates falls nearly as fast as the team’s cohesiveness. Within a short time your team successfully adds 10 new “heads” to meet the aggressive project schedule.
To ramp up the new members as quickly as possible, they have been given the proper one-day overview of the project. They weren’t even asked to write code until Day Two. Soon these new team members start contributing thousands of lines of code. Productivity seems at an all-time high. Tasks are getting done in record time and the team now seems to be functioning on all cylinders. If you’re lucky, within a couple of weeks, the first set of problems start to reveal their ugly heads. All kinds of new nasty bugs show up in QA (assuming, of course, that there is a QA team). Senior team members have to take time off of their tasks to track down these nasty issues. After days of searching and going through weeks of code line-by-line, some suspected line code are identified. The first question asked is “who wrote this crap?” and so the process expands.
In order to find out who’s responsible for poorly written code in the future, “checkin” rules requiring detailed comments are put into place. Additionally, every single line of code is now required to go through a complete and formal code-review to help reduce errors.
The team’s pace changes drastically. Things slow down and soon it’s obvious that the deadline targets of the project schedule are impossible to meet. At current pace, you easily need to increase the headcount by another 5 to 10 to make the ship dates. But, even that is unlikely as a frustrated, but competent teammember finally speaks up and reminds the executives (and everybody else in the room) that 9 women can’t make a baby in 1 month.
Finally, everybody comes to accept the missed deadlines and the pushed back release dates. Life goes on…slowly.
There is a Better Way
There is, of course, a better way. Among engineers and project managers, it’s common knowledge that a really good engineer can be 3, 5 or even as much as 10 times more productive than a bad engineer. What a load of crap. You’re probably thinking I’m nuts. You might even be thinking that you personally know software engineers who are 3 or 5 times more productive than the guy in the next cube. What you don’t realize is that you are probably discounting their productivity.
It’s possible for a good engineer to be infinitely more productive than the engineer sitting next to them. How is that possible? Consider this: in 1975, how many engineers could have single-handedly done what Steve Wozniak did in designing the Apple I and later the Apple II? What about the search algorithms used by Larry and Sergey (Google)? I know that if you had given me 10 years, it’s not likely that I would have thought of page ranking or search in the way that Larry and Sergey did. So how much more productive were they? I’d say about ($)150 billion times!
The problem with comparing people in terms of multiples of productivity (such as person X is 5 times more productive than person Y) is that there is an underlying assumption that both person X and person Y can do the same job. That is a huge and usually wrong assumption. Two people might be able to do the same job and if one of them is generally 5 times more productive than the other, that probably means there is a whole realm of things that is possible for one of them that’s impossible for the other.
With that in mind, if you were working on a hardware project and estimated that you needed 10 more engineers to get the job done, would you take 10 “Average Joes” or would you settle for 1 Steve Wozniak? If you were working on a Search-related project, would you take 10 “Average Joes” or 1 Larry Page or Sergey Brin? If the answers to those questions seem obvious to you, so should the importance of building a great team. It’s not about “headcounts.” It’s about talent. So to create a winning team, keep a few simple rules in mind:
- Hire the most talented people you can possibly find. Don’t hire someone if they don’t meet the bar you’ve set. I know it’s extremely tempting to lower the bar when it’s hard to find good people. Remember that a bad hire could actually have negative productivity!
- Create a system that’s flexible and light in process. Implementing any kind of canned methodology that has steps outlined from A to Z on how to create products and manage teams ensures that your team will operate at a low efficiency. A more dynamic and light-weight, low-process system is ideal when your team is already talented enough to know how to do the right things.
- Eliminate team members that consistently fall below the bar. Don’t kill them. Just fire them or move them to a different position if you can. If you can’t get rid of team members due to corporate culture or red tape, give them tasks that are non-critical to the success of your project. Often times you can increase productivity faster by removing team members than you can by adding them. If you find that you’re adding process to your efficient system because of 1 or 2 people who consistently need detailed guidelines to get work done, those are the guys I’m talking about.
- Create a culture that appreciates talent. Talented people like to work with other talented people. That’s how they’re satisfied. By giving them freedom to do the right thing and taking obstacles (and dumb people) out of their way, you’re creating a culture that appreciates and rewards talent.
By putting the emphasis on the team rather than the process, you’ll create much better products at the end.