Randy Winch

Apr 26, 2016 • 5 minute read

“I’m Sorry Dave, I’m Afraid I Can’t Do That.”
A Developer’s Take On How To Say No, In A Human Way.

A few months ago, I read “Getting Real” by 37Signals (the company now known as Basecamp.) Essentially, the book is like their company manifesto: a collection of statements on how to build “smaller, faster, better” software. In one of the chapters, there was a section called “Start with No” that really stood out to me.

"Start with No" caught my eye because I could easily identify with the situation it was describing. One of my co-workers had this running joke that the easiest way to impersonate me was to say “no” to every development question she asked. I even changed my fantasy football team name to "The Dream Crushers" to accurately reflect the path of destruction left by my barrage of "no's" on any given day. All kidding aside, the truth is that people don’t like the word “no.” And when it comes to our roles as tech leads and developers, avoiding that word and other Debby Downer-ish reactions is vital to keeping customers content.

But What If Saying “No” Is Vital To A Project’s Success?

What “Start with No” points out is that saying “no” is actually key to successful development. Every feature you add increases complexity and maintenance. 37Signals likens each “yes” to you–and the client–adopting a child: “You have to take your baby through a whole chain of events (e.g. design, implementation, testing, etc.)" Once that feature is out there, you're both stuck with it, they say: “Just try to take a released feature away from customers and see how pissed off they get.”

So what is the developer to do?

You Can Try Saying “No” Or, “No, Not Right Now…”

37Signals solution is to just say “no” flat-out: “Every new feature request that comes to us — or from us — meets a no. We listen but don't act.” If a request for a feature keeps coming back, “then, and only then” do they consider the feature for real.

Okay...but what if your agency culture is about fostering good client relationships? What then?

Be Attentive and Open to Suggestions.

One of the most important lessons I’ve learned since my days as the office naysayer is to be genuinely attentive to client suggestions. In most instances you don’t have to say “yes” or “no” to an idea on the spot. If you remain open, you’ll find yourself being more focused on the request and on how it can fit into the project goals.

When a client makes a suggestion, I often agree to do my due diligence and provide a recommendation after the meeting where the topic was raised. This gives me a chance to see how the request will affect the project from multiple angles. It also gives me time to discover different solutions before coming back to the client.

And remember, it’s also valid to hear a client out even if you have a “no” in your head. Role-playing an idea with them through to the end will often result in them talking themselves out of it. They just need to see how complicated building and maintaining that feature will be before they come to that conclusion themselves.

Turn a “No” Into a “Yes”...With Caveats.

There were many times I got so caught up in finding an immediate answer that my hurried reply contained a “no” that created an adversarial environment and, ultimately, decreased trust. Instead of issuing a knee-jerk “no”, I learned you can come back to your client with several solutions that contain caveats.

I was involved in a client conversation a while back, for example, where their request was going to be almost impossible to add in time for launch. I became so caught up in the implementation concerns I completely disregarded my own expert opinion of what was doable.

When I talked to my boss, he simply said, “Give me the three best solutions along with the pros and cons of each. We can let the client choose how they want to proceed.” I provided details of the three options along with an honest assessment of scope or timeline consequences.

And as my boss accurately predicted, the client chose an option that maintained the integrity of the project and resulted in a successful launch.

That wasn’t a flat out “no”, or a “no” disguised as a “yes.” It was a solution everyone could get behind.