How to give pushback to leadership

Estimated reading time: 6 minutes

Make your voice heard without burning bridges.

Saying no to leadership is sometimes necessary when you’re at the helm of a project. Whether they’re proposing a timeline that can’t be achieved, or asking for something that’s technologically impossible, adopting the word “no” into your regular vocabulary is your responsibility as an engineer. 

But, pushing back against leadership has high stakes. Doing it well can actually build your leadership team’s trust in you, even though you’re telling them something they don’t want to hear. Doing it very badly can have serious repercussions for the success of the project or your own career. 

Picking the right battles

Before you start to push back on something, first consider whether it’s something you should do. You should reserve pushback for big problems; saying no can be a big deal. Leadership almost always has more context than you about the grand strategy behind the project, so you should reserve pushback for big problems. These may be things that are actually impossible, unethical, or a risk to leadership’s goals for the project. 

Before pushing back, you should ask yourself what would happen if you did try to make it work. If the answer is “the code would be a bit awkward,” or “we’d have to do more maintenance work later on,” you’re probably better off communicating that and proceeding with the project.

Don’t go too far in the other direction, though. If you’re a technical professional, pushing back on things that are impossible or prohibitively hard is an important part of your job. Saying yes to everything neglects that duty. Agreeing to do the impossible will make your leadership happy in the short term, but they’ll be much less happy when you fail to deliver. 

Do your research first

If you’ve decided you need to push back, you must first find out who you’re pushing back against. Often, you can directly ask your manager where a specific problematic requirement is coming from. Is it your direct manager or product manager’s plan, or the strategy of a department, or a hard legal requirement, or your CEO’s idea? All of these require different approaches and different levels of effort. For instance, if it’s the CEO’s idea, you can’t push too hard. The best you can probably do is convince your manager and let them try and take it up the chain.

You should also find out why leadership wants that problematic requirement. If your leadership team wants to unblock a particular sale to a large enterprise customer, and you push back on a detail because it will introduce an unacceptable security risk, your pushback is likely to succeed. If you push back because it’ll make some part of the product less polished, your pushback is likely to fail. Why? Because polish is almost never a high priority for large enterprise sales, but security always is.

Give pushback gently and in writing

The earlier you push back, the gentler it’s possible to be. If you’re driving a car and brake at the last minute, you have to brake hard. If you start braking early, you can cruise to a stop. Likewise, if you push back about requirement X the day before launch, it’ll be a big incident: everyone will be stressed and busy, and you’ll have to pull people into emergency meetings if you want to actually get everyone on the same page. Bake in the appropriate amount of time to allow an issue to naturally make its way up to leadership’s radar. 

Because of this, it’s really important to try and anticipate issues on projects you lead instead of reacting to them when they happen. Even when everything’s going fine, you should try and get a sense of what the biggest future problems could be. What unknowns are still out there? What work are you depending on from other teams? Which requirements have been discussed the least, or have a higher likelihood of being misunderstood by different teams? 

When you do push back, start verbally, then follow up in writing. Starting out in a face-to-face conversation with your manager lets you feel out answers to who’s driving the requirement and for what purpose before you commit to public communication. But after you’ve decided to push back, you should still write down a clear summary of what you’re pushing back against and why. Whether it’s a ticket, Slack message, or email, your manager will need some written communication to pass around. 

Pushing back to your manager is effectively asking them to go and do the same thing to their manager. This process becomes a lot easier if they have some concrete writing that they can lean on.

Remember you’re giving advice

Write out your pushback assuming it’ll be read by managers who are a layer or two more senior than your direct manager. That means documenting your ideas concisely, with less technical detail, and as neutral and unemotional as possible. Think of it as: it’s not me against you; it’s us against the problem. The worst thing you can do is paint management out as the enemy and yourself as the hero blocking a bad decision.

It’s very important to provide multiple alternatives. Giving just one alternative can come across as if you’re telling your leadership team what to do. However, it’s also important to mention which option you’d prefer, since often your leadership team will want to make their decision quickly and keep moving. Nobody likes hearing “We can’t do X” and having to figure out what that means on the spot. It’s much better to say, “We can’t do X, and that means we can instead do Y or Z – I recommend Y.”

Even if you’re struggling to see any good alternatives, you should still provide a choice – even if the options aren’t ideal. A safe option is to suggest sacrificing the problematic requirement entirely, even if it’s essential from a product perspective. That doesn’t put you on the hook for anything, and you might discover it’s less essential than you thought, saving you a lot of work. Be careful not to overpromise on impossible solutions, or your manager may take that as a genuine offer and ask you to do it.

Prepare to be shut down

If you’ve done everything right, management will be in agreement with you, picking one of the alternatives you’ve offered and letting you execute on it. 

But what if you aren’t successful? Sometimes you push back on something and get completely shut down: told to make it work with the original plan.

This is a make-or-break moment. It can be surprisingly difficult to emotionally accept a flat “no” after you’ve put yourself out there. You should prepare to accept that response ahead of time. In almost all situations, you should react with “okay, your call” and go ahead with their plan. If the dire consequences you predicted do come to pass, you’ll at least get credit for having warned about them. That’s one reason why it’s so important to write it down.

It can help to remind yourself that a little pushback is sometimes better than no pushback at all. Managers usually have enough experience with projects to know that something always goes wrong. If they don’t hear any problems from their senior engineers, they can get suspicious that nobody’s paying enough attention. Even if you get shut down, if you’ve handled the communication well, they’ll likely be grateful that you were engaged enough to go to the trouble.

Final thoughts 

Giving pushback to leadership can be the hardest part of leading a project, but it’s often necessary. If you’re able to gently put the brakes on early, in a way that’s informed by the business reasons behind the project, you’ll make it possible for your managers to find a way around the problem.