Why Managers Must Learn to Say No

In one of our previous articles, we took a good, hard look at the magical power of saying “no” and shared some tips on using it with tact and elegance. Just around the same time, Jon Westenberg from Favro team dived headfirst into studying the reasons that make managers say “no”.

In any team, on any project, in every single company I’ve worked at, the biggest productivity killer has been scope creep: more features being added, more features requested, or more ideas that could completely change the nature of the original plan.

It’s a killer because scope creep moves the goalposts over and over again. I’ve worked with technical teams who have experienced this; they sign on to a project with a specific set of instructions, requirements, and features. Within six months, it’s been red-penned and modified so much that most of what they’ve been building isn’t even usable.

You’ll see this most often when there are non-technical departments or stakeholders constantly fighting over the wheel. They want the product to match their marketing goals, their advertising goals, their fundraising goals, their BD goals… it’s endless.

If you’ve let scope creep change what your team is working on and they’ve become overloaded with additional features and shifted priorities, no project management app or team chat software is going to fix it.

It can become almost impossible for a technical team to reach their goal and actually ship their code if the dimensions are constantly in flux. So what does that mean for managers? It means that you need to be responsible for the most powerful tool in your team’s reach: the word “No.”

A manager’s role isn’t just about coordinating staff and making sure the project is on schedule. Your role isn’t just about hiring, firing, mentoring, and nurturing. It’s being the barrier between your team and external requests, it’s being the person who can say no in order to stop the project from raging out of control.

Teams are more productive when they manage what they can’t do

When you know what you can’t do, you’re giving yourself far clearer boundaries than if you’re only focused on what you can do. If you focus on the latter, there’s room for every single outside request. If you’re looking for what you can say “yes” to, there’s no reason to reject a million changes from the marketing department who wants feature X because competitor Y has feature X. That’ll only be the start of it.

When you’re managing what’s not possible, what’s not practical or just what you won’t agree to, you’re setting clear guidelines and limits. That gives you a walled garden to build in. Productivity depends on working within a set of requirements, so you need to make those requirements into limitations that don’t allow your team to work at random or in a sense of chaos.

When teams are overloaded, no app is going to fix it

If you’ve let scope creep change what your team is working on and they’ve become overloaded with additional features and shifted priorities, no project management app or team chat software is going to fix it. No ticketing process will solve it. If your team is overloaded, things are going to fall through the cracks, and some tasks will not get done.Your project will become a bizarre mish mash of features without direction if you say yes to all requests that come your way.

Your project will become a bizarre mish mash of features without direction if you say yes to all requests that come your way.

It’s healthier to state which tasks won’t be possible or won’t be finished before they become a problem rather than afterwards. Afterwards, you’ll look like you don’t have control over your staff, or you don’t know how to manage their work. Before, you’re going to be demonstrating a clear grasp of your output.

Your team is going to appreciate this. If you’re able to limit how much they have to work on so they don’t run the risk of failing to complete certain tasks and requests, they’ll respect you — and thank you — for it.

You can’t say yes to everything

It’s about more than just your team’s sanity though. It’s also about their professional pride. A technical team wants to be able to put their name to work they’re proud of. They don’t want to put their name to a camel — a horse designed by committee. Your project will become a bizarre mish mash of features without direction if you say yes to all requests that come your way.

Most tech teams have worked on products like that. They’ll put months of work into something only to eventually be staring down the barrel of a disaster that can’t do what it was supposed to do — but does have some fancy bells and whistles.

You have a responsibility to stand up and say no. You’ve got to be the voice of reason at the best of times. And the single person bracing the door against the battering fists of everyone else at the worst of times. It’s a role that is going to suck sometimes, but it’s a vital role. Your team needs you to be that kind of manage.

To make it easier than ever for your team to achieve maximum productivity, check out Favro. It’s a tool that will keep everyone working on the right things. Sign up for free.