Q: What persuaded you that this book needed to be written and why now?

A: The book was gestating for a number of years. My background is in consulting. Prior to becoming a management consultant, I led the West Coast office of an IT consultancy. So I'd come up the ranks as an IT consultant, doing everything from programming to account management, project management, and ultimately leading different offices of a national firm. I became quite a consumer of business and leadership literature, and it all seemed to have a disconnect with reality. It certainly didn't describe my reality very well. I tried to figure out why the business literature seemed so different from what I was viewing. The conclusion I came to was leadership literature almost always starts with the very simple assumption that leadership is a relationship between a leader and multiple followers. But then the authors go on to focus completely on the ethics, behavior, experience, charisma, or whatever about the leader, as if the nature of the follower were completely irrelevant. None of these books seemed to address the idea that whom you lead matters for how you lead.

There's been a need for a book like this for a long time, but especially today, as technology has permeated virtually every area of large and even medium-size organizations. Today nontechnical executives, as well as technical executives, rely on technology, and therefore rely on geeks.

Q: Some companies have installed nontechnical managers as CIOs. Doesn't their lack of technical expertise put them at a disadvantage with their staff?

A: It matters more about the individual and the person's ability to adjust to the environment than it does what his or her origins are, because people who have come up the technical route and people who have come up the nontechnical route have the same dysfunction when trying to lead geeks. They've bought into a lot of the management mythos or the management archetypes that are built around hierarchical organization. Even if they've come up the technical ranks, they seem to immediately forget everything that pissed them off about their boss.

Also, it's a completely different job. Heading a department, being a CIO, is a completely different experience than being a project manager or even a team or department leader. It's a highly political job. It's much more a leadership job than a management job. So anyone promoted into it from any direction ends up with the same kind of problem.

Q: How about technology companies as opposed to nontechnical companies? Do the setting and the level of technical expertise of the corporate executives affect the way techies should be managed?

A: It is different, though how you lead downward is not all that different. How you interact outside the IT department would be quite different, because of the technical sophistication of your clients. In the book I describe the four elements of geek leadership, and one of them is external representation: representing the group of geeks to the outside community—whether inside the company or outside. So the techniques of dealing with your peers would differ more than those used for looking inward at your group.

Q: You distinguish between management and leadership. What's the difference?

A: The best definition I know comes from Warren Bennis, who is the series editor on my book. He says management is doing things right; leadership is doing the right things. The idea is that one is very tactical, and one is very strategic and long term. I don't distinguish between them that much, because there are three reasons why I think geek leadership is different: The first is that geeks are different from other people. We have to recognize whom you will lead. The second is that the nature of their work is fundamentally different from most work—certainly from physical labor, which is where most management thought starts. Third, power is useless when dealing with geeks. Yet most leadership theories are completely based on the idea of social or referent power. It's not because geeks are just recalcitrant—sometimes they can be—but that power is about influencing behavior. Geeks don't deliver value through behavior; they deliver it through thought. So for those three reasons, I think leadership here is quite different, and in the geek environment, leadership and management converge. They're not as distinct as they are in a more industrial setting.

Q: Three pressing personnel issues for any CIO are recruitment, retention, and motivation. Let's start with recruitment. Though the job market has obviously changed a lot since the dot-com era, finding the right person for an IT job remains a difficult challenge. What can CIOs do differently?

A: The biggest mistake a lot of CIOs make is defining the right geeks the wrong way. Too often, they try to define the right people to hire based on technical skills, as opposed to cultural fit and engagement with the technology they're using locally. A lot of the motivation problems start with a mismatched recruiting effort. So you're almost starting at a deficit of motivation, because you've hired someone for all the wrong reasons.

CIOs have to get very clear on the true criteria for success in their organization. Because technology is ephemeral, they should focus much more on cultural fit, productivity, drive to learn new things, as well as interest in and understanding of the business.

Q: How about retention—what works?

A: My philosophy is very simple. Though you see surveys that say it's all about money, I think money is a very secondary issue. The No. 1 thing is if they're interested in what they're doing because they're interested in the technology, the role they're playing, or the company. If someone gets up in the morning and says, "Gosh, I love what I'm doing," then they don't ask you how much money they make.

Q: But can CIOs really create the kind of situation where employees feel that good about their jobs?

A: It's part of figuring out what makes each individual engaged with their creative work. If you want them to be motivated, you've got to match them up in some way with something that makes them happy. When doing project assignments, too often the first question is: Who has the skills? As opposed to, Who has the interest? "Oh, John's done this 16 times before; let's put him on the project!" The 17th time, yes, he's got the skills, but he's going to go nuts. Geeks love to learn new stuff. These managers are making the Frederick Taylor [an early-20th century management consultant] mistake: "Specialization plus repetition leads to productivity." That's just not true in knowledge work.

Q: Let's look at motivation. In your book you say technical workers can't be motivated by others. What's the solution?

A: It's like gardening. You can't make plants grow. But you can create the environment in which they'll grow. It's like tilling the field.

There's the difference between extrinsic and intrinsic motivation. Extrinsic motivators are good support for intrinsic motivation, but if you want someone to be truly engaged and creative, you have to create an environment in which intrinsic motivation thrives. Then people will motivate themselves, and you have to support that with fair extrinsic motivators.

Q: What's the difference between these two types of motivation? A: If you look at traditional management approaches, almost everything that people do to motivate their employees is what we'd call an extrinsic motivator. It's based on a notion that motivation lies outside the work. It could be a paycheck or a promotion. It has nothing to do with the nature of the work itself. It has to do with "I do the work because I want what I'm going to get from doing the work." If someone holds up a $10 bill, it doesn't engage you in creativity at work; it engages you in the $10 bill.

Intrinsic motivation, on the other hand, is something that's inextricably linked to the work itself; it motivates you to do it. Say someone is passionate about landscape painting, yet no one would ever pay for one of that person's paintings—that's an intrinsic motivation. There's something involved in the act of painting that makes the person really interested.

Teresa Amabile, a professor at Harvard Business School, has studied the motivation for creativity. She's found that most creativity springs not from extrinsic motivation, but from intrinsic motivation. Since you can't actually create intrinsic motivation within people, you have to create an environment in which they can create their own. But you can also do things that will very easily damage that environment. I call these demotivators—things that destroy the environment in which intrinsic motivation thrives.

Q: What are these demotivators? A: The most common one, especially for people who have come up the technology ranks, is that they focus on tasks instead of goals. For several reasons, it's important that managers of technical people focus on what they want their people to accomplish and not tell them how to accomplish it specifically. One reason is what geeks would call micromanagement. Not only does it offend the nature of technical people as a personality type, but it also violates what I call the knowledge inversion.

This is the reality that violates all our assumptions about the workplace. We have this idea, which ties back to the European guild system, that you start as an apprentice. Then, once you know everything about being an apprentice, you become a journeyman. You become a master once you know everything about being a journeyman. We always assume that "my boss should know everything about what I do." But in technology work, it's inevitably reversed. Whoever is doing the hands-on work knows more about what they do than anyone else.

Q: This creates a strange dynamic between the manager and the staff, doesn't it? A: Absolutely. That's why, among other reasons, focusing on goals instead of tasks is important. It provides a level of respect and specialization between leader and follower that you don't get when you try to push down tasks. Geeks resist that: "How could you possibly tell me how to do my job, when I know more than you do?" It's an offensive notion and a counterproductive notion. But if you tell me what we're going to accomplish together, and you respect my expertise, and I say how we're going to accomplish this, then we're working together to take the best of both of us: the leader setting direction and the following setting tactics. You've engaged the creativity of both.

Q: Let's return to compensation. You say it's not that important to techies. Yet it's certainly a major budget item for CIOs. Also, isn't money a way for techies to keep score? How can CIOs reconcile these issues related to pay?

A: Money is absolutely a way of keeping score, but it's not about the money; it's about the symbol of the recognition the organization places on an individual. Whenever I had someone come to me and say, "I'm not making enough money," those were people making two, three, four times the average wage for a family of four in this country. They didn't need more money. It was always a proxy for something else. Their complaint was not about money; it was more about, "You don't love me enough" or "You don't respect me enough." The money was a symbol of something else, and it was safe to talk about. No one would ever come to you and say, "I feel inadequate because I think you don't love me." It's much safer to just say, "I want more money."

There might be extreme exceptions where someone really does need more money. I remember one fellow who had a traffic-accident fatality judgment against him. He needed more money. But most geeks don't.

Q: So how would a manager convert the request for more money into a discussion of what you say are the real issues? A: It has to become a conversation about what's fair—what's fair to the individual, fair to the company, and how pay and value are linked. If you believe the person is underpaid, then you figure out how to adjust to what's fair. But if you think they're not underpaid, you have a conversation about how they can increase their value to the company and then get better paid. But you have to be able to articulate clearly what it is they can do better. Too often, it's just: "Learn more technology." That's clearly an inadequate approach. That's just such a small part of how they deliver their value. In my book, I describe the 12 things that geeks do, and only one of them has to do with learning new technology.

Q: By the way, why do you use the word "geek"? You've spoken a lot about respect for technical workers. Will calling them geeks be perceived as respectful? A: It's not necessarily a derisive term. It's in the intent. Geeks call themselves geeks all the time. It's only when someone from the outside calls them a geek and means it as a slur that it's somehow offensive. I've called myself a geek probably since I was in grammar school.

Q: So the word takes on a different meaning when it's used by an insider than when it's used by an outsider?

A: I think it does. Outsiders can use the word, but it has to be in the context not of contempt, but of respect and recognition.

Not that I think all CIOs should go out and start calling their staffs, "my geeks." In fact, when they talk about "my people," they make a big mistake by invoking hierarchical imagery. It's not "my people"; it's "us." We as a group do this together, as opposed to me lording over everyone. Geeks have a very strong sense of resisting hierarchy. There's no reason to puff yourself up to offend that sensibility. It doesn't gain you power. Power in geek groups comes from being in the middle of everything, not from being on top of everything.