Another Monday and another successful Reader Question Monday. Usually I go with kind of a FIFO model for reader questions, but I bumped one that I’d just logged because it seems interesting. It concerns how to politely say no and how to know when to say no with clients and prospects. I’ve excerpted some of the question here.
I have a problem I have run into and it has to do with when to say “no” to work.
I have the chance to work on a project where my gut says I should not, not only is the project at least two months, it is at a rate that is too low for 1099. There are also many issues with current infrastructure and architecture which the owner wants to bypass. I guess my point is how do I turn down the work gracefully. In the past I have taken on this type of project and worked 12 hour days for 9 months to get it done, obviously, I don’t want to do that again.
I guess my point is, it is really hard to say “no” but it would be easier if there was a way to vet possible work with others [who] are knowledgeable about architecture so perhaps a way to audit upcoming work to see if taking on the work makes sense. How do you weigh the pros and cons? How do you get second opinions that are good, not random?
Extracting Themes Around No
This is a common situation for an independent. But it could just easily apply to anyone reading in the midst of a job search. Or even in even less dramatic fashion — maybe your boss pitches you working with a different group for a time.
Some common, recognizable themes emerge.
- Saying no to things is hard, professionally. Our very wiring tells us to please, as illustrated by the phrase “the customer is always right.”
- Saying no to things has real downsides. For employees it can mean lost capital and for free agents, lost revenue and belt tightening.
- We see red flags, but have a predisposition to proceed anyway and hope for the best.
- It’d be nice if we could get some insider information to tell us whether to heed the red flags.
- In general, a framework for sizing up work would be good.
How to Politely Say No
I should note that I did dedicate a chapter entitled “The Art of No” to this subject in Developer Hegemony. That was more about how aspiring opportunists should steer themselves away from politically perilous situations, but some of the techniques certainly apply.
You never really want to just say a blunt “no” outright to a client prospect. Even if you think working with them makes for a terrible fit or they’ve rubbed you wrong during discovery, you’re running a business. You want a reputation for playing nice and being professional. Here are some general ways to demur on a prospective gig.
- Say no, but offer to help them find someone who will say yes. In a sense, this isn’t “no” at all. You could almost think of it as steering them toward a lower tier offering. “This isn’t a great fit for me, but let me put you in touch with Steve, who…”
- It’s not you, it’s me. “Given the budget you’ve allocated for this and your engagement model, I don’t think I’d be a fit. I usually direct projects like this and am used to incremental value delivery, and it appears you’re looking for an app dev staff augmentation.” I suggest doing what I did here — subtly phrase it in a way that positions what they want as a budget offering. This will prompt them to start making concessions if they really want you.
- Say that your calendar presents a conflict for the work.
- You can be direct and honest and just say that you don’t think the work is a fit for what you offer. Careful here, though. Direct and honest sounds like the best (and to some, only) option, but it puts a lot of clients and prospects in a defensive posture. It may leave them with a bad taste in their mouths.
- Or, finally, you can get them to say no instead. More on this later.