"No" Should Never be Your Answer

It always surprises me how many people start off with “no” as an answer to a question from their peers, management, or customers. It’s shocking how many people believe “no” is a good answer, or even a preferred answer. 

There are very few places in business when answering “no” to request from a peer, partner, or manager helps move the business or your career forward[1]. In this context, “no” includes responses like “I can’t”, “I won’t”, etc. Answering “no” to an ask for help is a simple way of telling others you neither respect the ask nor respect the thinking that generated the ask. This is a sure way to irritate people.

The better approach is to accept the request at face value and outline the trade-offs that must be made in order for you to facilitate the request. This type of response starts a productive discussion on priorities and demonstrates your tactical, and potentially, strategic thinking. It shows others you are trying to achieve the goals that have been requested, but that you have legitimate concerns over the impact the request may have on other activities you have already committed to. This is a problem others can both understand and would likely try to find ways to help with.

When talking with customers and partners, “no” is almost always wrong as well. Telling a customer or partner “no”, puts them on the defensive and demeans the value of their idea. Again, surfacing the trade-offs and providing better options, while acknowledging the validity of the of the original request or idea, drives a productive conversation that allows all parties to win.

From an engineering team perspective, this is a critical skill all engineers and PMs must learn. Engineering teams are engines of a company, but the engine usually doesn’t set direction. As such, engineering teams need to be constructive partners in helping business and leadership teams understand the costs associated with new ask. Once leadership understands the cost of an ask, they can prioritize the ask appropriately. Many times, the plan of record remains intact after discussing a new ask because the cost of the change is too high. Or when looking through a different lens, the ask was lower priority than the items in the current plan.

Keep in mind, the cost of an ask may not be easy to quantify immediately. Many times the ask will require pulling team members off existing tasks just to get an idea of the potential cost. But the investigation is a cost and should be the starting point for discussion about cost.

You may be thinking, if I entertained every request from the sales team or an account owner, it would be impossible to get work done. This leads to the next piece of advice, never take asks from people who are not decision makers. For example, if a person on the sales team comes to the engineering team inquiring about a new feature, politely thank them for their idea and route them to the decision maker for new feature requests (e.g. the product owner). If a request is from a partner, make sure the request has flowed through the correct channels in the partner and has the support of the decision maker on the partner’s side. If a person can’t approve a change in the plan of record, the request needs to first go to the person or organization that can approve changes to the plan of record.

Finally, when requests do come in from internal or external partners (including proper approval from the partners decision makers), have a formal process for managing change requests. It’s important that teams understand how to document the request, and the request be costed in an appropriate way for the partner. This prevents later recriminations or misunderstandings since everything will be documented.  

Tips and Techniques

• Never answer a request with “no”, “I can’t”, “I won’t”, “etc”.

• Never take an ask from a person who cannot eventually approve the cost of the request. In these cases, politely refer inquiries back to the appropriate decision maker.

• Help the requester understand the cost of a request. The cost could be in money, time, resources, team moral, etc.

• Have a formal process for taking in and processing requests. If a change is eventually approved, it is important everyone involved understand the cost and impacts on the plan of record.  

[1] There are situations were "No" is the best answer, but these are generally limited to things like unprofessional, unethical, or illegal behaviors.