Jamie's Blog

Ruby developer. CTO. Swimmer. Always trying to write more

No, but

If you’re a consultant, freelancer, CTO, product manager, then your default answer to all requests should be:

“No, but…”

That sounds negative and obstreperous doesn’t it? I’ll explain (though rest assured, phrasing also matters — see later). If you’re a consultant, then you clients will often come to you with solutions: “The buttons need to be bigger”: “We need to add X / we need to change Y” etc. The consulting client knows their business but they’ll often come to you about a problem in their domain and present a solution in your domain. They are not an expert in your domain. So, it’s a reasonable first reaction to assume that the solution they’re presenting is not necessarily the best solution for them.

No, but… tell me what you hope to achieve

No, but… why do you think we need that?

No, but… I’ll consider that in the future

Your aim should first be to understand their problem so you can find come up with solutions using your expertise. It might even be the same solution as their proposal, but now you’ll understand the “why”. After all, it’s your expertise that they’re paying for. The most valuable consultants are those that reject their client’s initial suggestions and, instead, search for the deeper problem and a wider range of solutions. If you just blindly implement your client’s suggestions, what real value are adding?

No, but… that makes me sound negative

Someone who says “no, but…”, “no, but…”, “no, but…” isn’t going to maintain good relationships with their client/boss/users. You don’t (and shouldn’t!) actually say “no, but…” — it’s just something to keep in your mind.

“Ok, and…”

“Yes, but what about…”

“That’s interesting. How will you use it?”

And so on. The main point is to ensure that the solution in your domain isn’t decided by someone with a limited knowledge of that domain. Strongly exercising your knowledge is a principle difference between a valuable consultant/employee and “just another” developer.