"Why? Why? Why?" The CIO gestured expressively like a conductor urging his orchestra to step up the tempo. Accelerando! Allegro! "You should always ask 'Why'!" "But," he added (descrescendo), "learn when to stop asking."
Nothing drives me crazier than to ask a developer a simple question about why the client does this or that function in the system he is developing and have him give me a vacuous look and mutter, "I don't know." That pierces the heart of software development's essence: seeking first to understand. How can you write a program for a process you can't express in words or scrawl in pictures on a napkin, for that matter?
While the industry has warmly embraced agile methodologies as a welcome alternative to exhaustive, inflexible, up-front requirements processes, we have to be careful not to use Agile as an excuse for…dare I say…ignorance. Blissful ignorance. Or laziness. Oh...I'll find out about that later...when I get further into it.
At the heart of the needs assessment is the question: Why?
Why do you need this system? Why do you do things the way that you do? We all know the story about the lady who cut off both ends of a ham before she cooked it because her mother and grandmother had always done it that way…only to learn that the practice had begun due to the limiting size of the ancestor's roasting pan. Yet, in IT, where we are supposed to know better, we often find ourselves blindly following practices and doing what we're told (following orders to build System X) without asking the three letter question that would reveal so much.
In our own MIS department we had a notorious track record for fulfilling the letter of a service request (we gave the client exactly what he asked for) instead of the spirit of the request. The assignee might have suspected there was more to the request and it didn't exactly make sense, but the prevailing sentiment was: the requestor should know what he's doing and I'm too busy or don't care enough to delve deeper.
Why not ask Why?
Edward Nilges has touched on one reason numerous times here at d.*: the perception (or sometimes the reality) that the working drones are not expected (or even empowered) to use the word. But sometimes it's a self-imposed limitation. Perhaps therein lies the rub. As young children we're considered precocious when we ask why stars twinkle or why the sky is blue. But when logical answers aren't forthcoming from less scientifically inclined parents, perhaps the sense of wonder is dulled. Or perhaps we get a little older (morphing into obnoxious teenagers) and are reprimanded for questioning our elders and lectured on the merits of respecting authority. Before you know it, you're swinging on the bottom rung of an org chart robotically chanting, "Would you like fries with that?" Not, "why would you consider shortening your lifespan with artery-clogging dead flesh?" Okay...the example leaves something to be desired (such as sustained employment). But perhaps it would be acceptable for a nutrition-conscious employee in that situation to ask his supervisor why he might not offer a plug for the side-salad instead.
How do you ask Why?
The innocent-looking, one-word question can be interpreted as:
(1) "You're an idiot, I'm your intellectual superior, and I could tell you ten reasons why your way of doing things stinks and we both know I will eventually have your job if I don't quit this lousy organization first."
(2) "I can better provide a hassle-free, turn-key solution for you if I more fully understand your goal."
How the question is received of course is influenced by the tone of voice and even the choice of words. "Why?" isn't really a great way to ask "Why?" because it can come across as curt and demanding.
The CIO 'Why?'
CIOs do not appreciate being placed in the position of explaining or justifying their decisions. If you ask a question with judgmental implications, such as "Why did you buy into the Microsoft monopoly for this organization?" you may not receive the positive results you hoped for. Instead, if you ask, "Would you be interested in me doing some research and providing a brief benefit assessment of Open Source tools contrasted with the Microsoft development platform?" your CIO or manager might actually consider your proposal. You are still more-or-less asking the burning question, but in a more productive way.
Everyone you interact with wants you to answer the same question: Why?
Why should I marry you?
Why should I buy your house?
Why should I hire you as a contractor to develop this application for me?
Why will this development tool be useful for our team?
To give an IT-related example, in a recent document management/imaging project, the internal client was drowning in paper and clearly needed the technology more than any other department. It was blooming obvious...but we quickly learned it was only obvious to IT. The client kept hedging, expressing such doubts as, "I can't see how we could use this." Theoretically, the client admitted, it made sense, but she just couldn't grasp how they could adapt their processes.
The perceptive project manager stepped back and scheduled time to shadow the workers, observing the interaction between staff and their external clients, carefully watching the flow of paper. She documented the existing workflow with simple pictures and connecting lines. Then she made a second version of the same diagram with proposed changes, substituting scanning for copying and sometimes rerouting processes that had nothing to do with systems, just because it made sense and would improve efficiency. Of course the workflow required some revisions, but the client response was astonishingly different. Even though the client never quite articulated the question, "Why?" –seemingly more focused on "how"—it was at the heart of her resistance. She was likely thinking, "We've done it this way for the 25 years I've been here, why change now?" She probably thought dismissively, "IT doesn't really understand what we do." By investing the time to fully understand the process and answer the unarticulated question, IT earned respect and credibility, selling the solution.
When to Stop Asking 'Why?'
The CIO cautioned, "Learn when to stop asking." Case in point: You're in a meeting with your manager and several peers. An issue is raised and an active debate ensues. You make your excellent points. You're right and you know it (or at least feel strongly about it). The manager makes a decision and it didn't go your way. My CIO likes to add the important qualification that "if it's not immoral or unethical" then the time has come to stop asking 'Why'. You did the right thing to ask 'Why' to begin with, but you have to recognize you won't always get your way. Some might consider that settling or even selling out, but another word for it is maturity. However, if you find yourself in a position where you're constantly having to choke back the "Why's," it's probably a sign that your employment is not aligned with your value system and the question then becomes, "Why don't I look for another job?"
Editors note: this article was originally published on May 3, but I missed it in the queue and failed to promote it to the front page. Hence, to ensure everone sees it, I updated the publication date to May 23. --DR