The Language of the Request
The only important thing is to know that if one works well in a potato field, the potatoes will grow. If one works well among men, they will grow- That's reality. The rest is smoke. It's important to know that words don't move mountains. Work, exacting work, moves mountains.. -Danilo Dolci
One reason that some software professionals fail to advance to their full potential is that they are perceived as lacking in ‘soft’ skills. This situation is not surprising, given that most never received training in soft skills nor have they had the time to do self-study in this area. Soft skills can be learned and practiced, just as with ‘hard’ skills. This article is the first in a series of articles intended to help make available information on key soft skills. It is targeted at software professionals at all levels. Please send any feedback to softskills @ kleinfelter . com.
The Hardest Thing about Creating Software…
One of the toughest things about creating software is communication. This article touches on one area of communication that frequently goes awry: the language of the request If you’re in the business of providing or obtaining a service (and isn’t all of software development either one or the other?), then clear communication of requests is important. The language suggested in this article is not important per se, but it can go a long way toward ensuring that full and accurate communication occurs.
The Language of the Request
Unless you’re in the military, when you want someone to do something, you have to ask them. (Duh!)
A well-formed request is clear on several points:
- The fact that a request is being made
- Who is being asked
- Who is asking
- What they are being asked to do
- When they are being asked to do it
Let’s consider the case where I’m in a room full of developers, and I say, "Gee! This code really stinks! Somebody should clean up this ugly code."
Let’s assume that George, a skilled developer, wrote the code. George is someone who likes to write 90% of the code and then move on to other things. Earl and Janet, two of the other developers in the room are decent coders. They are also the kind of person who assumes that if something is wrong, it is up to them to personally fix it. It is easy to see that George is likely to completely blow off my remark, and Earl and Janet are each likely to set off on a mission to fix the code.
Assuming that I wanted George to fix the code, where did I screw up? I have failed to make a Clear and Unambiguous Request [sic].
I have in mind that the author of the code should fix it, but I’ve not made clear who I’m asking. George is the kind of guy who just isn’t interested in doing that sort of thing, so he chooses to hear my remark as tantamount to commenting on the weather. Since Earl and Janet always assume that everything is their fault, each chooses to hear my remark as a request that they fix the code. I left the matter of who was being asked open to interpretation, and each developer interpreted it differently. (Don’t tell me you don’t know any developers like these three – I won’t believe it!) It ain’t their job to figure out who I’m asking. It is my job to make clear who I’m asking.
This ‘request’ also fails to identify the requestor. In fact, it was probably worded this way specifically to avoid doing so. Most people don’t want to create additional work for their peers, staff, supervisors, etc. When I must create additional work for someone, I often seek to avoid taking the responsibility for doing so. My reasoning goes something like, "Maybe if I don’t directly ask, they won’t notice that I’m asking them to do more work," or perhaps, "They won’t think I’m a team player if I’m always asking them to help me."
Bad idea! Unless they’re terminally dense, they’re going to figure out that I’m the source of the additional work. If they don’t want to do it, they’ll choose to ignore what I said. (After all, I didn’t actually ask them to do anything, now did I?) In addition to ignoring my request, there’s a good chance that they’ll resent me for not coming right out and asking. If I’m going to ask someone to do something, I have to be willing to take the heat for making a request. I am the one who is going to be displeased if the work isn’t done, so I owe them the courtesy of letting them know that it is me who is asking.
The third failing of my request is that I didn’t make clear what I was asking George to do. George chose to hear it as not requiring any action on his part. If he were Earl, he might have interpreted it as a request to rewrite the entire application, when all I wanted was for him to fix a single function. Jeez, if he thought I wanted the whole app rewritten, no wonder George blew off my request. If I want someone to do something, I owe it to them to make clear what I’m asking them to do.
The fourth failing of my request is that I did not make my deadline clear. Do I want this done today? In this lifetime? Assuming that George is going to work another 30 years, there are 6000 workdays for him to choose from. Odds are that he’s not going to choose the same one as me. If I want something done by a certain time, it’s my job to make the deadline a part of the request.
The fifth failing is that I’ve obscured the fact that I’m even asking anyone to do anything. One reason why I sometimes avoid making a clear and unambiguous request is that I don’t feel like I have the authority to ask someone to do something. Bullshit! I’ve got all the authority I need to ask a subordinate to do something, to ask a peer to do something, or to ask my boss or even the CEO to do something. It is not always necessary to create an external justification for a request. Just make the request. If the requestee wants to know why, they can ask. If I want something done, that’s justification enough to ask! (Remember that we’re not talking about the military here. The only time I need authority is if I’m going to issue an order.)
The reasons why I (and by extension, others) avoid making a clear and unambiguous request are not bad ones. They are part of the social fabric that makes it possible for people with differing goals and needs to coexist. When you’re working with someone whom you just work really well with, you often don’t have to make the effort of clear communication. If they’re not someone who always seems to know just what you want, then you’re going to have to make the extra effort if you want the communication to occur. If the communication doesn’t occur, you’re probably going to be disappointed by the results.
What if the shoe is on the other foot? What can I do if someone makes a poorly-formed request of me? Ask for clarification! I can try something clever like, "Are you asking me to debug the module? When would you like it to be done?"
When someone makes a well-formed request, there are several appropriate responses:
- Accept
- Decline
- Propose an alternative
- Ask for clarification
If I ask George to fix the code and he accepts my request, I’m a happy camper.
If I ask George to fix the code and he declines my request, I’m not pleased, but he’s made a clear response. If I need the code fixed, I now have the option of asking Earl to do it. Please note that I’m George’s boss, and he makes a habit of declining my requests, he may find his career options severely limited.
If George is unable to accept my request (of if he just prefers not to accept it), he can propose an alternative. If George has a tight deadline next week, and he knows that Janet has free time on her hands, he could say, "Gee, I’m kinda busy. How about asking Janet to do it?" I can accept his alternative, or we can continue negotiating until we reach a mutually acceptable alternative.
If George isn't clear whether or not I expect him to work late in order to get this done, he can ask for clarification on this point before responding.
Please note that it is not appropriate for George to label my request. If I say, "George, I want you to clean up this function by next Friday," it is entirely inappropriate for George to say, "That’s the dumbest thing I’ve ever heard! Don’t you know I’ve got 3000 lines of code to debug by then!!??!!" (Sound familiar?)
To summarize, a well-formed request is clear and unambiguous, identifying:
- What is to be done
- Who is to do it
- When it is to be done
- Who is asking.
To respond appropriately is to do one of the following:
- Seek clarification of the request
- Accept
- Decline
- Propose an alternative.
Copyright 2000-2005, Kevin P. Kleinfelter, All Rights Reserved
Retrieved from http://www.kleinfelter.com/requests