“No” is an easy default response to big technical asks. It manages the risk and expense of large projects with unknown complexity and (let’s be honest) will often take less of your time than a “Yes”. Some times it’s also the correct answer. No, we can’t make a square with three sides.

“No” usually doesn’t help the business though. There’s a reason the PHB is asking for a square with three sides. It might also be tied to some fundamental misunderstanding, but underneath the request is a problem they’re trying to solve (maybe they just need a triangle). Your job as a skilled devops professional is to understand and help solve that problem.

As a matter of soft skills, you should generally address their question in some way before telling them it sounds like the wrong question. “Squares definitionally have four sides, but we do have the ability to make three-sided polygons. They’re called triangles, and they can only have one right angle unlike a square.”

By the time a technical request makes it from the business side over to the tech organization, “yes” is really the only answer they’ll accept. You might be tempted to say “no” and leave it at that, but instead you should just tell them what “yes” looks like.

Switching analogies, let’s say the PHB wants to build a racquetball court as an addition to the office building. Instead of saying “that’s way out of budget and we can’t even get a building permit for that addition” try explaining what it would take to make it work if you had unlimited resources. Explain the cost of labor and materials for the building, the legal process of getting the permits, the unsolved problem of where to fit such a building on the premises.

At the end if you can give a ballpark of the time and total cost and what other projects will be deprioritized to accomplish it, your “yes, and” will have a much stronger case than a “no”. If you frame your answer as “yes” and then let them discover that such a project isn’t feasible, now you can work together to figure out another solution.

If you had just flatly said “no” in the first place you’re making the interaction adversarial. With a “yes, and” it’s collaborative. Alright, that won’t work but let’s explore other solutions.

And now comes the best question you can ever ask a business person: “What problem are we trying to solve?”

Contrary to popular belief, business people are pretty terrible at communication so they generally don’t think to start with the problem at hand. But once you have that you can use your special engineer brain to find a solution. If the PHB wants a racquetball court because they want to be able to play racquetball, you can suggest they get a YMCA membership instead. Now you’ve solved their problem and saved them a big pile of money. If you do this a few times you will be every PHB’s favorite engineer.