How to Manage Geeks

"How to Manage Geeks

By Russ Mitchell

Eric Schmidt, CEO of Novell, believes that "geek" is a badge of honor. (After all, he is one!) But how do you manage these geek gods? Just follow his nine-point techie tutorial.

There is a saying in Silicon Valley: "The geeks shall inherit the earth." That is a sign, if you needed one, that we have permanently entered a new economy. Once a term of derision, the label "geek" has become a badge of honor, a mark of distinction. Anyone in any business in any industry with any hope of thriving knows that he or she is utterly dependent on geeks -- those technical wizards who create great software and the powerful hardware that runs it. The geeks know it too -- a fact that is reflected in the rich salaries and hefty stock options that they now command.

But how do you manage these geek gods? Perhaps no one knows better than Eric Schmidt, CEO of Novell Inc. Schmidt, 44, is a card-carrying geek himself: His resume boasts a computer-science PhD and a stint at Sun Microsystems, where he was the chief technology officer and a key developer of the Java software language. In addition, as if his technical skills were not enough to prove the point, Schmidt even looks the part, with his boy-genius face, his wire-rim spectacles, and his coder's pallid complexion.

Two years ago, Schmidt left Sun and took charge at Novell, where he has engineered an impressive turnaround. After years of gross mismanagement, competitors and industry observers alike had written off the $1 billion networking-software company, headquartered in Provo, Utah. Since Schmidt's arrival, however, the company has become steadily profitable, its stock price has more than doubled, and, within its field, Novell has again come to be seen as a worthy competitor to Microsoft.

A good deal of the credit for Novell's turnaround must go to Schmidt, who excels at getting the best out of his geeks. He has used his tech savvy to bring focus to Novell's product line and his geek-cred to reenergize a workforce of highly skilled but (until recently) deeply dispirited technologists. In general, Schmidt speaks of his geeks in complimentary terms, while acknowledging their vulnerabilities and shortcomings. "One of the main characteristics of geeks is that they are very truthful," says Schmidt (who, in fact, uses the term "geek" only occasionally). "They are taught to think logically. If you ask engineers a precise question, they will give you a precisely truthful answer. That also tends to mean that they will only answer the question that you asked them. If you don't ask them exactly the right question, sometimes they'll evade you -- not because they're lying but because they're being so scrupulously truthful."

With that rule of geek behavior in mind, Fast Company went to Novell headquarters to ask Schmidt a series of precise, carefully worded questions. His answers add up to a short course in how to bring out the best in your geeks.

You have to have your own geeks
Today innovation drives any business. Moreover, since you do not want to outsource your innovation, you need to have your own geeks. Look at trends in e-commerce: Who would have thought that all of these "old" companies would have to face huge new distribution-channel issues, all of which are driven by technology? The truth is, you need to have a stable of technologists around -- not just to run your systems but also to help you figure out which strategies to pursue, which innovations to invest in, and which partnerships to form.

The geeks control the limits of your business. It's a fact of life: If the technologists in your company invent something ahead of everybody else, then all of a sudden your business will get bigger. Otherwise, it will get smaller. You simply have to recognize and accept the critical role that technologists play. All new-economy businesses share that property.

Get to know your geek community
According to the traditional stereotype, geeks are people who are primarily fascinated by technology and its uses. The negative part of that stereotype is the assumption that they have poor social skills. Like most stereotypes, it is true in general -- but false at the level of specifics. By society's definition, they are antisocial. However, within their own community, they are actually quite social. You will find that they break themselves into tribes: mainframe-era graybeards, Unix people who started out 20 years ago, the new PC-plus-Web generation. They are tribal in the way that they subdivide their own community, but the tribes do not fight each other. In fact, those tribes get along very well -- because all of them fight management.

Perhaps the least-becoming aspect of the geek community is its institutional arrogance. Remember, just because geeks have underdeveloped social skills does not mean that they do not have egos. Tech people are uppity by definition: A lot of them would like to have been astronauts. They enjoy the limelight. In a power relationship with management, they have more in common with pro basketball players than they do with average workers. Think of your techies as free agents in a highly specialized sports draft. And the more specialized they are, the more you need to be concerned about what each of them needs as an individual.

Learn what your geeks are looking for
This is a golden era for geeks -- it does not get any better than this. In the early 1970s, an engineering recession hit, and we reached a low point in engineering and technical salaries. Ever since then, salaries have been going way up. Geeks have figured out that increasing their compensation through stock options is only fair: They expect to share in the wealth that they help to create through technology. Today technology salaries are at least twice the national average. In fact, tech salaries are sharply increasing, and non-tech salaries are not -- which presents a serious problem for many companies.

However, as important as money is to tech people, it is not the most important thing. Fundamentally, geeks are interested in having an impact. They believe in their ideas, and they like to win. They care about getting credit for their accomplishments. In that sense, they are no different from a scientist who wants credit for work that leads to a Nobel Prize. They may not be operating at that exalted level, but the same principle applies.

Create new ways to promote your geeks
If you do not want to lose your geeks, you have to find a way to give them promotions without turning them into managers. Most of them are not going to make very good executives -- and, in fact, most of them would probably turn out to be terrible managers. However, you need to give them a forward career path, you need to give them recognition, and you need to give them more money.

Twenty years ago, we developed the notion of a dual career ladder, with an executive career track on one side and a technical career track on the other. Creating a technical ladder is a big first step. However, it is also important to have other kinds of incentives, such as awards, pools of stock, and non-financial kinds of compensation. At Novell, we just added a new title: distinguished engineer. To become a distinguished engineer, you have to be elected by your peers. That requirement is a much tougher standard than being chosen by a group of executives. It is also a standard that encourages tech people to be good members of the tech community. It acts to reinforce good behavior on everyone's part.

Either Geeks are part of the solution -- or they are the problem
Here is another thing you need to know about the geek mind-set: Because tech people are scientists or engineers by training, they love to solve really hard problems. They love to tackle a challenge. The more you can get them to feel that they're helping to come up with a solution to a tough problem, the more likely they are to perform in a way that works for you.

When you talk with them, your real goal should be to engage them in a dialogue about what you and they are trying to do. If you can get your engineering team to agree with what you are trying to accomplish, then you will see them self-organize to achieve that outcome. You will also need to figure out what they are trying to accomplish -- because, no matter what you want, that is probably what they are going to do.

The next thing you need to remember is that you can tell them what to do, but you cannot tell them how to do it. You might as well say to a great artist, "I'll describe to you what a beautiful painting is. Then I will give you an idea for a particular painting. I will tell you which colors to use. I will tell you which angle to use. Now you just paint that painting." You'd never get a great painting out of any artist that way -- and you'll never get great work out of your geeks if you try to talk to them like that. You need to give them a problem or a set of objectives, provide them with a large amount of hardware, and then ask them to solve the problem.

The best judges of geeks are other geeks
Make sure that there is always peer-group pressure within your project teams. For example, if you want to motivate your project leaders, just require them to make presentations to each other. They care a great deal about how they are perceived within their own web of friends and by the professional community that they belong to. They are very good at judging their own. In addition, they are often very harsh: They end up marginalizing the people who are terrible -- for reasons that you as a manager may not quite understand.

It sounds like I am touting tech people as gods, but there are plenty of bad projects, and there is plenty of bad engineering and bad technology. You are always going to encounter techies who are arrogant and who are not as good as they think they are. A team approach is the best way to deal with that problem. Tech people know how to deal with the wild ducks in their group -- on their own and with the right kind of peer pressure.

Look for the natural leaders among your geeks
In a high-tech company that is run by engineers, what matters most is being right. Moreover, what's "right" is determined by outcomes. You can listen to lots of exceptionally bright people talk about their brilliant vision. I have 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 are 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. Do not forget: They feel like they are changing the world -- so you need to make them feel like you are 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 is 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 is absolutely brilliant, that executes well, and that is 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 is 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 cannot 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. However, it is 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 does. 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 will 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 will accept it -- as long as it is truly a business decision. On the other hand, if someone whom the engineers do not respect professionally bases the decision on a technology analysis, then they will never agree to it. Therefore, if you are 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. However, in this industry, that approach almost never works. The results are almost invariably disappointing. Still, people keep doing it that way -- presumably, because that is 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. Generally, 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, and Netscape Navigator.

The smaller the team, the faster the team members work. When you make the team smaller, you make the schedule shorter. That may sound counterintuitive, but it has been true for the past 20 years in this industry, and it will be true for another 20 years. The only method that I have found that works is to restrict the size of teams arbitrarily and painfully. Here is a simple rule of thumb for techie teams: No team should ever be larger than the largest conference room that is available for them to meet in.

At Novell, that means a limit of about 50 people. We separate extremely large projects into what we call "Virtual CDs." Think of each project as creating a CD-ROM of software that you can ship. It's an easy concept: Each team has to ship a CD of software in final form to someone else -- perhaps to another team, perhaps to an end user. When you treat each project as a CD, you enable one group to say to another, "Show me the schedule for your CD. When is this deliverable coming?" It is the kind of down-to-earth approach that everyone can understand, that techies can respect and respond to, and that makes almost any kind of project manageable."

<Note from JobFairy.com: I like the new approach to extreme programming (XP), but few people really know how to implement it. Treat geeks with respect and kindness. They're not assets to the company that can be redeployed at will. And don't try to get all cheap and replace them with offshore labor, thinking they can do what your overpriced geeks can do for a fraction of the cost. Mediocre labor produces mediocre code. You're going to get what you pay for.>