No Is A Complete Sentence

Has someone asked you to do something recently that you know you don’t have time to do but felt like you needed to do anyway? Or has someone tried to get you to help with something and impressed upon you just how important it is? You probably told them “yes” out of guilt or obligation or some other kind of negative emotion. Sure, you could have declined but you thought about how bad you would feel if someone did the same to you.

Let me tell you clearly. “No” is a complete sentence. It requires no explanation or defense. It is the only thing you need to say when you know you won’t be able to do something no matter how much the other party tries to get you to agree.

Everything Sucking Equally

If you know anything about QoS, you know that once a given circuit reaches the limitation for bandwidth you can no longer send additional information. What’s counterintuitive about this is most people would assume that if you try to squeeze one more stream or packet into the mix that only that last packet would be affected and everything else would work perfectly fine, right? Only one of the many would suck.

Sadly, all of the packets or flows on the circuit are affected in this situation. Adding just one more thing to the mix means all things are affected because the system has to process the problems all at once. You suffer everywhere because the interface couldn’t say “no” to that last packet.

In fact, the whole mantra behind QoS is prioritizing information before it hits a given interface because the interface is just going to send whatever it is given. Those packets will queue up or eventually be dropped if they can’t be processed. Likewise, if you are trying to do too many things at once you will eventually miss something important and make a mistake because you couldn’t handle everything at once. You need to be able to prioritize all the things that are going on and know when you hit a limit you can’t get past.

Where the challenge comes into play is when others try to add more to the interface without knowing you’re at maximum capacity. It’s easy for someone to ask you to do just one more little thing. In their minds it’s not a huge ask, right? In your mind you’ve already begun trying to juggle all the things that need to be changed to make this one little thing work with all the other things you’ve spent so much time prioritizing. Unfortunately, it’s too easy to just say “yes” to avoid uncomfortable conversations and try to fix the problems as they come up rather than turning away something you know would put you over your limit.

Taking No For an Answer

It’s easy to tell people to say “no”, right? I mean it is possibly the shortest sentence in the English language. However, it’s not the person saying it that usually has an issue. The people doing the asking are the ones that almost invariably are the ones trying to convince, cajole, or outright impress upon the person how critical it is that whatever this is get done in addition to all the other things that are going on.

For those that are asking the question and expecting a positive answer, let me ask you a question of my own: Why does this person need to do the task? There usually are very good reasons for it. Perhaps it’s something this person specializes in. Maybe it’s something that only they have knowledge about. It could perhaps even be their job responsibility to get it done. But the next question you need to ask is even more important.

If they must do this task, what can I do to help them?

The calling card of bad management types is to show up, assign a bunch of tasks that only other people should do, and then fly away to measure their productivity and comment on how nothing seems to be getting done. Instead, management should be asking how they can help. Is this something that someone else could do? Do you have the bandwidth to do the task? Is there another task on your plate that I can do for you that would help you to take care of this?

People are often very fully tasked with all the things they have to take care of. Thinking that you can sneak one more thing onto their schedule without impacting all of it smacks of hubris. What if someone started adding tasks to your plate instead? I doubt you’d like that. Even if you said no, what if it was the CEO or the Chairman of the Board telling you that you had to do it? You’d probably be just as upset, especially if it was a task you couldn’t delegate.

For the people out there like me, try this next time someone asks you to do something and you’re fully tasked or unable to clear enough to accomplish it. Say “no”. Don’t explain. Don’t justify. Don’t defend. Just. Say. No. Watch the other person’s reaction. Are they getting frustrated because you’re not saying anything? Are they coming back in a helpful manner trying to understand why you declined? Or are they more upset that they now have to go find someone else to do it instead? If they come to you with respect and understanding you can tell them why you declined and are unable to help. They may offer suggestions or try to find a way to make it work. The ones that get upset are usually the ones that wouldn’t have taken “no” for an answer no matter what. They are the ones you don’t need to waste your breath on.


Tom’s Take

I will admit this post is as much for me as it is for others. I am the world’s worst for taking on additional things when I know I don’t have the bandwidth to do it all. I don’t like to disappoint. I really want to keep people happy. And instead I end up failing because I overestimate my ability to get work done and underestimate how much others could do if they knew I needed help. Next time you need to tell someone you can’t do something, don’t spend a ton of effort figuring out how to counter their eventual arguments. Just say “no” and move on. If it’s important or something that only you can do they will find a way to make it work. Otherwise, you will have saved so much more effort because you used a complete sentence instead of a needless paragraph.

The Art of Saying “No”

No.

It’s the shortest sentence in the English language. It requires no other parts of speech. It’s an answer, a statement, and a command all at once. It’s a phrase that some people have zero issues saying over and over again. And yet, some others have an extremely difficult time answering anything in the negative.

I had a fun discussion on twitter yesterday with some friends about the idea behind saying “no” to people. It started with this tweet:

Coincidentally, I tweeted something very similar to what Bob Plankers had tweeted just hours before:

The gist is the same though. Crazy features and other things that have been included in software and hardware because someone couldn’t tell another person “no”. Sadly, it’s something that happens a lot in the IT industry. As a bad as IT’s reputation for being the Department of NO is we often find ourselves backed into a corner when it comes to saying “yes” way too much. I wanted to examine a couple of specific situations when we really should be saying “no” to people instead of just agreeing to keep the conversation moving.

Whatever You Need, We Do

When I worked at a VAR, I did both pre- and post-sales. I would go out to the customer site with the account managers to discuss technologies and try to get the potential customer what they needed. One of the AMs I worked with loved to introduce me and infer my skill level by saying, “Tom is the guy that makes all my lies come true.” It was his favorite icebreaker. We would all chuckle and get the conversation started.

Sadly, that icebreaker was true more often than it should have been. Because he (and some other AMs) would very often tell the customer whatever they wanted to hear to close the sale. Promise we could install the whole system in three hours? Easy. Tell them it will fix all their crazy Internet speed problems? You got it. Even as bad as telling this this will make their applications run so much faster and keep them super secure the whole time. Whatever it takes to make you sign the check.

When I arrived on site with a pile of equipment and a list of things that I needed to configure, I was quite often stricken with frustration because of the way my AMs had fibbed to the customer about the capabilities of the solution. Maybe they sold the wrong licenses to keep the costs down. Or, in some cases, they sold a feature that was much harder to implement than others. I seriously couldn’t count on both hands and feet the number of times I was forced to go to the customer and ask them what they were expecting from the solution based on what was sold to them.

Sometimes, you have to say “no”. That’s a hard phrase to say when you work in sales. You want the customer to get your product or service instead of your competitors. You want to book revenue. You want to keep your boss happy and keep yourself employed. You want to meet your goals. But you also don’t want to burn your bridges when it comes to being a good resource instead of someone just looking to make a buck.

I always tried to position myself as someone that could off impartial advice about a subject. If the customer wanted something that I couldn’t deliver I would say, “That’s not a good idea” or “Have you thought about why you want that?” I wanted to make sure that the customer really did want the thing they were asking for. Anyone that’s ever had a CEO or CIO clamor to implement a thing they say in an airport ad after coming back from a conference trip will attest to the power of wanting cool, shiny things.

Being a truly trusted advisor to your client means you have to be honest. No, that open source project won’t get you what you’re looking for just because it’s free. No, you can’t make your old intercom system work with a new VoIP UC solution. No, you can’t just keep running this server another three years on Windows 2003 Server so you can avoid the upgrade fees for your new clients. Saying “no” isn’t just about making them avoid things they don’t want to do. It’s about helping them understand a strategy and vision for what they need to be doing. Customers don’t always need to be told what they want to hear. They really do need to be told what they need to hear though.

Managing Products, I Think

The other side of the equation comes from the vendor side with product managers. I’ll admit that I have a limited view here, but the people that I’ve talked to seem to back up my thoughts on the matter. As stated above, I’ve always wondered how crazy random features made it into a software product. My supposition is that someone wanted to close a million-dollar deal somewhere and that feature was one of the things that it took to make that happen.

I also know that crazy things like this happen more often than you might realize. For example, ever wonder why wireless access points come configured with 80 MHz channels out-of-the-box when everyone you know, vendors included, tell you to configure them for 20 MHz or even 40 MHz instead? Could it be that when testing companies pull the APs out of the box that they don’t reconfigure the channels? Or perhaps it’s because those APs with 80 MHz defaults seem “faster” on those same tests? It’s a silly default configuration but it wins contests and reports. That’s the kind of decision that gets made by a product manager that wants to win customers or awards.

I would hope that the people that make products understand that people don’t really need insane corner case features to make products work. Worse yet, having those crazy features involved to support a random solution that is likely going to be replaced in a few years anyway cuts into partner revenue. The vendor shouldn’t be the one making their equipment compatible with every piece of hardware under the sun. Microsoft doesn’t write all the drivers for hardware to work with Windows, for example. They just write the specs for interfacing with the OS and leave the driver software writing up to the people that make the webcams or Bluetooth coffee mugs.

Vendors need to let the integration work happen with the integrators. Maybe they get access to some kind of advanced API or toolkit that assists with writing the “glue” that ties systems together. But building in basic support for everything under the sun from the outset creates support nightmares and unforeseen interactions with things that you will own for the next decade. Take the easy way out and tell people “no” and that they need to find someone to help them instead of just begging to have that crazy feature request included in a one-off build. Or, worse yet, included in main release and enabled by default.


Tom’s Take

I will admit that I have a really hard time saying no to things. It increases my workload and makes me so distracted that I can barely see straight most of the time. But there are times that I know I need to respond in the negative to something. It’s usually when I see that the person making the request either doesn’t know what they’re asking for or will end up regretting it later on. The key is to help them understand that you have the experience they lack and the vision to see this isn’t going to work the way they are planning. Hopefully they’ll come around to your way of thinking. But if not, just remember that “No.” is a complete sentence.