People pleasing can run deep in the consulting space. We’re here to help, after all. However, sometimes the idea of helping can get misconstrued into always being a “yes man” (or woman) to our clients. Saying “yes” is not always right though. Let’s chat about when it’s okay, and even recommended, to say “no” to a client.
When to Say “No”
When the Request is Outside Your Expertise
Now and then, a request might come in that is not 100% within our wheelhouse. Or, perhaps it’s something we absolutely can do, but we don’t feel entirely responsible for charging the hourly rate of custom software development for the request.
A good example of this is branding. Our designers almost all have backgrounds in more “traditional” design practices, including creating logos and building out robust brands. However, that’s not where they spend their time anymore. Quite frankly, our rate for software design and development is likely more expensive than going to a solid branding and identity firm or designer to craft a beautiful logo.
We want our clients to utilize their budgets effectively, which might occasionally mean saying “no” to a request and recommending someone else for the job.
When the Request is Not Feasible
When I think about infeasible requests, I categorize them into a few buckets.
1. The client’s budget does not support the request.
If a customer is asking for the champagne of custom software but only has a Miller Lite budget, I will be honest about that upfront. We can work together to prioritize the most important pieces, and I’m positive that the customer and their users will be happy with the result. It just might not be what the original grand vision was for the first iteration.
2. There are technical constraints that make the request infeasible.
If a request is simply not possible, there is no point in beating around the bush. I will always be direct when a technical constraint prevents us from delivering on the original request. If there are creative ways around the technical constraint, we’ll bring that to the table.
3. The business does not support the request.
Sometimes, a fantastic idea is simply not feasible because of the changes required within the business to support the idea. Perhaps the software is tied to other systems. For instance, there could be a point-of-sale that we are unable to change but that would need to change to support the request. In these situations, concessions will simply need to be made.
4. The timeline is too aggressive for the request to be feasible.
Unfortunately, we are unable to alter time. We are also unwilling to expect folks to work unsustainable hours. Occasionally, a timeline is just too aggressive. In these situations, I am always honest. After the initial disappointment passes, we can then work with our customer to determine what can be delivered in their original timeline or how we might push the timeline back.
When the Request is Not Ethical
At Atomic, we vet our clients pretty darn well. We prefer to work on projects that put some sort of good into the world. It is quite rare that I find myself in an ethical dilemma. However, if I do, it is a scenario where I will absolutely say “no” to my customer.
Occasionally, I also must shut down inappropriate behavior. Again, this is quite rare, as 99.9% of the folks I’ve had the opportunity to work with have been a delight. However, now and then, there is a client who toes the line (or barrels past it) of what is and isn’t appropriate. I will not hesitate to say “no” and put an end to behavior that jeopardizes my teammates’ ability to feel safe and valued at work.
Saying “No” Without Actually Saying “No”
The above examples are all fairly cut-and-dried scenarios in which it’s completely appropriate to use the word “no.” More often than not, though, we find ourselves in more gray areas. As good consultants, it’s our job to guide our customers and help them traverse a more feasible and fruitful path. Sometimes that means saying “no” to something within our area of expertise that is feasible and ethical — but perhaps just not a great idea.
A frequent scenario I run into is one where the customer loves their own idea. It might be a really interesting one, too! However, our user research might indicate that, although that idea is fun and novel, it’s the opposite of what users desire most. This is an example where I would look to guide my customer. There’s no need to completely shut down their idea, but let’s discuss why it might not be what users want. Then work collaboratively to settle on a solution that everyone will be pleased with.
Somewhere Between a Yes Man and a Negative Nancy
Like most things in life, it’s all about balance. At the end of the day, we are consultants because we want to help our customers and their users achieve their goals. Sometimes we might need to be a bit more direct in our guidance. Sometimes we need to be more tactful and strategic. Part of being a good consultant is knowing when to take which approach. Also like most things in life, honing in on that just comes with practice and time.