In my last column, “Spontaneous combustion of rancid management,” I talked about how managers should restrain themselves from randomizing their employees. But what if you are on the receiving end? As an employee, how do you best respond to a random request, or requests of any kind, that aren’t directly related to your current task?
Sure, we’d all love to be the guy or gal in charge and not have to answer to anyone else. That’s how many startups get started—people want to be their own boss. As if being the CEO helps you avoid random requests from customers, clients, and creditors. Look, you can’t escape it. Even Steve Ballmer’s day is dominated by crud to corral, catalog, and contain.
What kills me is that everyone seems to believe their own lives are busy, but everyone else is idle and waiting to serve them. That’s stupid. We’re all busy—really, really busy. At times insanely busy and stressed out. So when that next request comes and you have no time but it’s the boss or the customer or the partner who can’t be ignored and you have to deal with whatever it is—even though your brain is vibrating, your inbox is full, and your stomach is aching—what do you do? First of all, don’t panic.
You should say “yes”
You respond to the request by saying, “Yes, I’d be happy to help.” Counterintuitive, isn’t it? After all, you can’t possibly help. You don’t have the time, nor does your team or anyone you know. The key is learning how to say “yes” the right way. (Later, I’ll talk about the few well-defined situations when you should say “no.”)
Why say “yes” to almost any request regardless of your situation? Because saying, “no” doesn’t fix the situation. It just gets worse. Ignoring the request is no better than refusing it. The most effective response is “yes,” framed in a few different ways.
§ “Yes, tell me more about your problem.” Most requests are unclear. Maybe they are nothing at all. Maybe they weren’t meant for you. Almost certainly, the people on the other end haven’t thought it through. Providing an initial “yes, tell me more” only commits you to learning more. After the request is properly defined you’ve got an easy exit as needed (“Oh, you meant that?”). In the meantime, you’ve made the request go away for a while—sometimes forever.
§ “Yes, let me point you to a person or Web site that can help.” Many requests go to the wrong people or can be served by an online resource. Passing those requests on appropriately fulfills the need. Be short and clear to avoid answering again. Don’t worry about how busy the next person is—they can say “yes,” just like you.
§ “Yes, when do you need that done?” Clarifying when a request needs to be filled transforms it into a prioritization exercise. Given enough time, you and your team can do anything. Given high enough priority, you can do anything right away. It’s all about priorities and timing. Let’s drill down on that.
Why does the situation get worse if you just say “no”? Because the request lingers. It becomes more urgent. By the time it pops up again, it’s even more difficult to manage. Meanwhile, you look unresponsive and uncooperative to your manager and customers. You’re much better off handling it right away.
All other priorities are rescinded
You ask when the request needs to be completed and naturally the answer is—”Right away!” Now what? It depends on who’s asking. If it’s not the people who control your schedule, like your management chain, you say, “Great, let me pass this request by my manager to ensure it gets done.” Sometimes even threatening to run a request by a manager is enough to make the request go away—if not, it’s time to talk to the boss or project manager.
At this point, your management is making the request or you are escalating a request to management. Either way, the conversation is the same. You present your prioritized work backlog up to the cut line for the current milestone or iteration (a whiteboard will serve). You ask where the new request fits into the prioritized list. There are only three possibilities:
§ The new request fits below the cut line. You reply to the request indicating it will have to wait till at least the next planning period. If that’s a problem, refer the requester to your manager. This keeps you and your team on track and focused on your top priorities.
§ The new request fits above the cut line. That means the lowest priority items move below the cut line, which you point out to management at the time of the decision. You communicate the change to everyone impacted and let the requester know when to expect action.
§ The new request fits above the cut line, but your manager wants nothing else cut (sound familiar?). You negotiate the scope of your existing work items. Perhaps some can be simplified or reduced. Perhaps other people can take items off your list or help you handle the new request. Don’t leave the conversation without a mutual agreement and understanding of the changes, and then immediately communicate those changes to the appropriate people in writing (that makes it stick).
Of course, you may actually want to perform the new request. So long as it doesn’t impact your commitments, you can go ahead and do it. However, don’t kid yourself. If it will take you more than a couple of hours, you owe it to yourself to formally adjust your schedule. No one will talk glowingly about all the work you did while you failed to do your job.
Note the importance of having a prioritized work backlog up to the cut line for the current milestone or sprint. If you are using a method like Scrum this is trivial. Even decent waterfall project management methods use prioritized task lists. Regardless, make sure you’ve got one. It’s a great bonus if your manager is already familiar with it.
Trust but verify
Now you are extremely busy and have a new task. Perhaps you negotiated with your manager for help from other people. Unfortunately, those people are clueless. They’re not going to do it right, which is to say, they’re not going to do it the way you would. What do you do?
You delegate ownership of significant portions of the request—not tiny disconnected work items—ownership of significant portions. You say, “You own this piece. Here are the requirements. Here are the boundaries. Here are the people involved. Here’s the results I expect and when I expect them. Any questions?”
The bottom line is that people will not do things the way you would, so let go. Give them ownership. Let them discover the right way for them. It will be better than your way for them. That’s how you delegate. You trust people. Seriously.
Naturally, you want to regularly check people’s progress and results. Trust but verify. That’s the key to delegation and management in general. Trust your people, verify their work.
Know when to say when
There are times when you should say “no” or when you can ignore a request, but there are only a few well-defined situations.
§ If the request was sent to a large group you can safely ignore it. However, a great way to build up your network and expand your influence is to respond to those broad requests. Just be thoughtful about which ones you pick, for the sake of your sanity and the health of your current project.
§ If the request came from your employees and doesn’t align with priorities, you should say “no” and use the opportunity to restate and reinforce priorities. If the team or team member is particularly passionate about an isolated request, remind them that as long as they meet their commitments and don’t impact the rest of the team, they can use their free time as they choose. However, no one will talk glowingly about all the work they did while they failed to do their jobs.
Sometimes side projects can lead to key advances, even when they aren’t nicely aligned with priorities. By saying, “As long as you still meet your commitments…” you aren’t saying “don’t do it.” You are saying, “Be sure to still meet your commitments.” This is part of the reason that slack time is critical (the other part being time to think—thinking can be beneficial). Ensure your schedules are always reasonable so they allow for some slack.
§ If the request contradicts corporate, division, or team policies, or your personal principles, you should say “no” and use the opportunity restate and reinforce those principles. It doesn’t matter who is asking—your boss, your general manager, or your vice president. If you can’t uphold the principles we, as a company, or you, as an individual, hold dear, then your work and our work mean nothing. We can compromise on a bug or a feature from time to time, but when we lose our principles we lose our soul.
I live to serve
Life is demanding. It’s hard to meet all those demands. You have to prioritize. You have to find balance. A constant stream of requests flows through your door, your Instant Messenger, your wall, and your inbox. While you can’t respond to all of them right away, it’s important to stay positive and welcoming of what life brings you.
New requests need to be clearly understood, appropriately dispatched, and thoughtfully prioritized against old requests. When you do manage requests quickly, transparently, and responsibly you are called a professional. When you do so with integrity around shared and personal principles, you are called a respected professional. Be a respected professional.
I’ve found that managers are especially grateful and tend to reward those who have a ‘can do’ attitude that takes a problem off their hands.
If you’re stuck with an unpleasant task, it helps to be ‘a soldier’ about it, recall that ‘all work is honourable’, and console yourself with the knowledge that "I’m still being paid."
One comment about the prioritization and escalation to management process is that it can often burn more resources and more of your time than just saying yes and putting in the extra effort to get it done. Also, if you say no, or "later", the requester may simply go on to ask somebody else, repeating the inefficient priority re-examination, perhaps multiple times. There is a certain efficiency to just saying yes without debate or additional study.
Not sure if you currently accept pingbacks, so I thought I’d send a hard link to the post I wrote in response…
Great post. Distills a lot of management books into a few paragraphs. The balance between managing expectations and upholding principles is particularly well stated.
"If the request contradicts corporate, division, or team policies, or your personal principles, you should say "no" and use the opportunity restate and reinforce those principles. It doesn’t matter who is asking—your boss, your general manager, or your vice president. If you can’t uphold the principles we, as a company, or you, as an individual, hold dear, then your work and our work mean nothing. We can compromise on a bug or a feature from time to time, but when we lose our principles we lose our soul."
Wow, you must work for a completely different part of Microsoft than I did. In my four years, the only project I worked on that actually shipped was one that was ethically wrong and possibly illegal. I said "no" on a daily basis, all the way up the chain. My objections got nothing but silence. When the project shipped, I got a bonus and a promotion for having compromised my principles. Then I found a new job. Now I can sleep at night.
Great post. But I think the heading "Know when to say when" should be "Know when to say no".