How to Manage Geeks

Look for the natural leaders among your geeks

In a high-tech company that is run by engineers, what matters most is being right. And what's "right" is determined by outcomes. You can listen to lots of exceptionally bright people talk about their brilliant vision. I've done it for the past 25 years. But what matters is, Which ones deliver on their vision? When a project is on the line, who actually gets the job done?

Every team has a natural leader -- and often that leader is not a team's official manager. Your job is to get the team motivated. Once you do that, the natural leaders will emerge very quickly. If you keep an eye on the team, you can figure out who those natural leaders are -- and then make sure that they're happy and that they have everything they need to do their job. For instance, natural leaders need to feel that they have access to the company's senior managers. Don't forget: They feel like they're changing the world -- so you need to make them feel like you're helping them do that.

There are easy ways that you can help them out. For example, encourage them to bypass layers of middle management and to send you email directly. Sure, that will piss off the people in middle management, but it's better to piss off those people than to piss off your key project leaders.

Be prepared for when the geeks hit the fan

You can divide project teams into two categories. First, there is the preferred variety: You get an engineering team that's absolutely brilliant, that executes well, and that's exactly right in its assumptions. Second, there is the more usual variety: You get an engineering team that has a very strong opinion about what it's trying to do -- but that's on the wrong track, because some of its assumptions are wrong. That second kind of team is what you have to focus your attention on. But often you can't intervene from the top down. You have to find a way to come at the problem from the side.

At Novell, we have a series of checkpoints at which our teams get lateral feedback -- feedback that comes from outside of the management hierarchy. Every six weeks, we have three days of product reviews. But it's not just management conducting those reviews. We also bring in smart technologists with good memories: They remind us of what everybody committed to.

In most technology companies, there are always a few people who, everyone agrees, have better taste than anyone else. Those are the people whom everyone goes to; they serve as reviewers or advisers. At Sun Microsystems, for instance, it's Bill Joy. At Novell, it's Drew Major, the founder and chief scientist. Everyone knows that when Drew gets involved in a project, he'll size up quickly what needs to get done, and people will listen to him.

In general, as long as you consider everyone's ideas, most teams react well to management decisions. If you have to make a business decision that conflicts with what your engineers want to do, they'll accept it -- as long as it is truly a business decision. On the other hand, if the decision is based on a technology analysis by someone whom the engineers do not respect professionally, then they'll never agree to it. So, if you're facing a decision that you know will affect a team negatively, you must vet that decision through a technologist who has that team's respect.

Too many geeks spoil the soup

If you want your geeks to be productive, keep your teams small. The productivity of any project is inversely proportional to the size of the project team. In the software business, most problems draw on the efforts of large numbers of people. Typically, companies deal with a problem by putting together a large team and then giving that team a mission. But in this industry, that approach almost never works. The results are almost invariably disappointing. Still, people keep doing it that way -- presumably because that's the way they did it last year. The question is, How do you break out of that mode? It seems to be a cancer on the industry.

On a large team, the contributions of the best people are always smaller, and overall productivity is always lower. As a general rule, you can count on each new software project doubling in team size and in the amount of code involved -- and taking twice as long -- as the preceding project. In other words, the average duration of your projects will go from 2 years to 4 years to 8 years to 16 years, and so on. You can see that cycle with almost any technology. Two or three people invent a brilliant piece of software, and then, five years later, 1,000 people do a bad job of following up on their idea. History is littered with projects that follow this pattern: Windows, Unix, Java, Netscape Navigator.