Stop Saying “No”: How Technical Leaders Win Arguments With Transparency

Posted on June 2nd, 2020
Written by Andrew Lau | Best Practices

As technical leaders, we often field an abundance of requests from the Sales and Marketing teams. CEOs often chime in with suggestions, requests, and demands. Well intentioned as they may be, these feature requests, one-off fixes, and pet projects are frequently impractical to implement, or impossible to achieve given real constraints of the engineering team. The classic, even visceral response to these irrational requests is often to just say, “no,” and at best add the reasons why it’s a bad idea. More often than not, that leads to disagreements, blame, or the painting of Engineering leadership as overly religious, out of touch, obstinate, and holding the business back. But it doesn’t need to be so.

Often the issue is that others don’t know the tradeoffs they are implying. By adopting a transparent and business-oriented approach to internal product communications and roadmap discussions, we can avoid these standoffs, garner far more support, and help the company make better decisions.

You’ve Already Done the Math

When we say, “no,” to a request, I’d venture to guess that you are not simply disregarding the idea as inane or unworthy of her attention. Just the opposite. In most cases, it’s not the first time you’ve heard the request, and you’ve already done the math in your head, measuring the tradeoffs and costs that such a project will consume, thus making an informed decision that it is too expensive, too timely, or too resource intensive, and thus irrational.

The reality is while we consider them innately obvious, the sales director or product marketing manager probably has not even thought of the tradeoffs and costs. The reason they don’t know is our own doing! We did this to ourselves. Remember they haven’t been steeped in these issues; they don’t wake up with others talking about the difficulty day in day out.

Put another way, instead of saying, “no,” and expecting others to understand it, illuminate for them the math. It’s your job to educate them so they come to your same conclusion. Highlight what your team will be doing instead and get buy-in that those things are more important to be focused on. You won’t be viewed as a roadblock, you’ll give them context for the next time and even better be viewed as an ally.

Frame Product Discussions in Business Terms

Another way to think about this; Sales and Marketing leaders and C-suite executives make decisions based on what the return on that investment (ROI) will yield. The calculus is fairly simple: if the ROI of a thing is positive (that is, the expected benefits outweigh the costs), we invest that thing, if the ROI is negative, we don’t. Using that calculus, since building some new integration will allow sales teams to close new business, we must build it. The disconnect here is that they don’t have a full understanding of the investment or cost that will be required.

That’s where they need engineering leaders to fill that knowledge gap. In this sense there are several costs we can highlight for them:

  1. The cost to build: “In order to build this thing, we’re going to need 2 engineers working on it, and we don’t have any engineers to spare, so we’ll need to hire 2 new people, and they’ll take 60 to 90 days to onboard.” This part of the equation is well understood, and probably won’t surprise anyone.
  2. The cost to support: “If we add this integration, it will actually make every new update more complicated and will slow down new releases moving forward.” This may be something that the business had not considered, now shifting the ROI in a less positive direction.
  3. The opportunity cost: “So we could do all of that, or but we’d have to pause resources and work on X, Y, Z, and R, which is what I thought you wanted to be done by Q3 – did I misunderstand previously?” This is usually the point that gets raised eyebrows and tips the balance in your favor.

Illuminate all the factors that have gone into your decision making. If you’re confident enough to say “no,” then you know all the factors that have gone into that decision. Show your math. Show how you came to it, use real numbers and timelines, and win the praise as a champion of the business’s interests.

Don’t wait for it to become a problem

Chances are, this isn’t the first time you’ve run into this situation, and it won’t be the last. Don’t repeat this process of argument and explanation over and over again. Instead of writing a report and outlining your analysis after someone asks for it, consider bringing them along. This is about being transparent – communicating your roadmap early and often, not just in product terms, but also in the terms of effort, costs, and ROI, underscoring the tradeoffs that you’ve already been thinking about. Keep them all up to speed on a regular basis.

Modern businesses thrive on transparency, and that goes at every level of the organization. For a growing number of companies, Engineering Management Platforms are providing visibility and business context for engineering teams, empowering engineering leaders to drive strategic alignment and make the right product decisions. The old school stonewalling approach no longer works and will only hinder the growth of your business and the success of your engineering teams. Embrace transparency and improve your alignment with the business. In other words, don’t just say “no.”