Information technology people tend to be answer people. When users, managers, family members or even random people from the Internet have questions, we're right there with the answers, because we're always the smart people.
One of the first things we learn in school is that being smart means having the answers. The teacher asks the class a question, and the smart kids reach for the sky. But just having a hand in the air isn't enough. To become known as the smartest of the smart, you've got to get that hand up faster than anyone else. It's the original arms race. (We all know how popular this made us.)
And that lesson gets reinforced throughout life. The questions keep coming, and we are rewarded for answering correctly. There are quizzes, exams, word problems, standardized achievement tests, PSATs, SATs, GMATs and job interviews -- each one reinforcing the notion that being smart means answering correctly.
Eventually, we enter the workforce, and when the boss asks, we answer. Our peers query, and we reply. The better our responses, the better our raises, the more impressive our titles and the more sincere the admiration of our peers.
But as often happens, those things that we do to get ahead eventually fail to serve us well. What makes us successful at one level limits our progress at the next. So it is with questions. At some point, just answering them is insufficient to make collective projects successful and individual careers soar. This happens for a couple of key reasons.
As we move higher in the organization, we begin to grapple with questions that have no correct answers. Being smart isn't enough. It becomes more important to evaluate the validity of competing responses than to find a correct one.
But beyond that, it's even more important to find the right questions than it is to find the best answers. Great answers to unimportant questions are still unimportant.
Successful groups grapple with important questions, not trivial ones. IT projects and organizations are very sensitive to the quality of the questions that are asked. If the questions you examine are even slightly less important than the ones you should be considering, your results may be dramatically poorer than you might expect.
Many IT projects remind me of one of my favorite scenes from the old Pink Panther movies that starred Peter Sellers as the bumbling Inspector Clouseau. At one point in The Pink Panther Strikes Again, Clouseau sees a small dog and asks the nearby hotel clerk, "Does your dog bite?"
"No," replies the clerk.
Clouseau bends down to pet the pooch and is immediately bitten by the snarling mutt. Clearly upset, he turns to the clerk and exclaims, "I thought you said your dog did not bite!"
"That is not my dog," the clerk replies dryly. Accurate responses to the wrong questions often lead us astray.
Every project begins with a series of unanswered questions. So how do you know if you're doing a good job with yours? Here are a few of my rules:
- Prioritize your questions. Not every question requires or deserves a response. Ask and grapple with the most important ones first. Good risk management demands that you handle the most threatening things first, and fundamental questions are usually more important than nitpicky, detailed ones.
- Why questions should precede what, how, who and when questions. If you look at your priority list of open questions and most of the top ones start with words other than why, you may be starting at the wrong place. Never assume that you know why a project is important. Way too many projects deliver great technical solutions to low-priority problems just because someone requested it and no one asked why.
- If your questions come with multiple-choice answers, make sure you have included a complete array of choices. One of the most powerful ways to control a conversation and limit creativity is to pose multiple-choice questions with constrained responses. When we see a menu, we naturally assume that it includes all possible choices. Rarely is that true.
Paul Glen is an IT management consultant in Los Angeles and the author of the award-winning book Leading Geeks: How to Manage and Lead the People Who Deliver Technology. He can be reached at firstname.lastname@example.org.