I became a manager in November of 1999. Before that I'd been a programmer, an architect, a visionary and an evangelist, but I'd never managed people. After that, I became VP of Engineering at NetApp with 250 people reporting to me. We hired another 500 engineers in the next couple years, so I had to learn fast.
There were always lots of problems to deal with, and I sometimes went to Tom Mendoza for advice, since he'd been managing for years. He always asked about the people working on the problem. Who was involved? What other things were they working on? What were they good at?
It was clear that Tom thought about things very differently than me. I would dig in on the problem itself. I'd learn about the details, explore the options, and worry about the right answer. Tom didn't focus on the problem; he focused on the people whose job was to solve the problem. After talking with Tom, I seldom understood the problem any better, but I had lots of ideas about how to move forward in solving it. Occasionally I was the right person to dig in and come up with a solution, but especially as the organization grew, it became obvious to me that Tom's approach was much more powerful and scalable.
Since I'm an engineer at heart, I reverse-engineered the process that Tom seemed to be using as he questioned me. I concluded that Tom applied a simple three-step algorithm to every problem:
When you find the owner, the next step is to figure out whether you trust them. I don't mean trust in some abstract sense; I mean trust them to fix this particular problem. In the abstract, I trust Tom Mendoza completely. For a problem involving spreadsheets or programming languages, I don't trust him at all. Even if you trust someone's skills, they may be too busy to do more. Do you trust that they have the skills, the time and the passion to solve this problem?
If steps (1) and (2) fail, then you must find an owner you trust. Sometimes there's someone nearby who can take it on. Other times you may need to reassign someone or hire a new person. Sometimes the answer is "Do it yourself," but the larger the organization, the less often this will be true.
Tom's background is sales, and he knows absolutely nothing about programming, so imagine my surprise when I watched him apply his algorithm recursively. By following steps (1) and (2) he concluded that he needed to hire someone to own a particular problem. "Hire someone" became the new problem, and by following steps (1) and (2) he concluded that he wanted to use an external headhunter. "Find a headhunter" became the new problem, and—here we reach the root of the recursion—Tom identified the owner as the VP of Human Resources, who he trusted.
There were always lots of problems to deal with, and I sometimes went to Tom Mendoza for advice, since he'd been managing for years. He always asked about the people working on the problem. Who was involved? What other things were they working on? What were they good at?
It was clear that Tom thought about things very differently than me. I would dig in on the problem itself. I'd learn about the details, explore the options, and worry about the right answer. Tom didn't focus on the problem; he focused on the people whose job was to solve the problem. After talking with Tom, I seldom understood the problem any better, but I had lots of ideas about how to move forward in solving it. Occasionally I was the right person to dig in and come up with a solution, but especially as the organization grew, it became obvious to me that Tom's approach was much more powerful and scalable.
Since I'm an engineer at heart, I reverse-engineered the process that Tom seemed to be using as he questioned me. I concluded that Tom applied a simple three-step algorithm to every problem:
- Who owns the problem?
- Do I trust them?
- How do I find an owner I trust?
When you find the owner, the next step is to figure out whether you trust them. I don't mean trust in some abstract sense; I mean trust them to fix this particular problem. In the abstract, I trust Tom Mendoza completely. For a problem involving spreadsheets or programming languages, I don't trust him at all. Even if you trust someone's skills, they may be too busy to do more. Do you trust that they have the skills, the time and the passion to solve this problem?
If steps (1) and (2) fail, then you must find an owner you trust. Sometimes there's someone nearby who can take it on. Other times you may need to reassign someone or hire a new person. Sometimes the answer is "Do it yourself," but the larger the organization, the less often this will be true.
Tom's background is sales, and he knows absolutely nothing about programming, so imagine my surprise when I watched him apply his algorithm recursively. By following steps (1) and (2) he concluded that he needed to hire someone to own a particular problem. "Hire someone" became the new problem, and by following steps (1) and (2) he concluded that he wanted to use an external headhunter. "Find a headhunter" became the new problem, and—here we reach the root of the recursion—Tom identified the owner as the VP of Human Resources, who he trusted.
Dave, this is a great post. There are, of course, many themses and variations of this algorithm - most of them not as effective. (I think I'm having a Mad Magazine flashback.)
1. nobly assume responsibility
2. suffer slings and arrows of outrageous fortune
3. betray others to restore your good name
1. form a committee
2. meet to discuss the problem
3. repeat step 2 until problem disappears on its own
1. form secret committee
2. identify scapegoat
3. humiliate scapegoat at next "team" meeting
Left by leishirsute at Sat, 31 Mar 6:23 AM
True.
Dave,
Have you ever heard of Monkey school?
It's formal training thta Florida Power & Light used to take to ensure that the "monkey" wasn't on their back.
http://www.oncken.com/monkey.html
The side effect was that management spent more time trying to get rid of ownership than taking it on.
Posted by: Marc Farley | April 23, 2007 at 11:16 AM