Asserting your domain expertise and learning to say “no” to your clients

When talking with colleagues about work, one of my biggest gripes is finding out they couldn’t say “no” to a client and are now stuck doing shit work. Having worked as a programmer and consultant for almost 10 years, I’ve certainly swallowed enough “no”s just to get a paycheck. But as the years went on, I realized that I was really just whoring myself out for pennies on the dollar when it was all said and done. The amount of time I ended up spending trying to implement a fix for that one CEO that refused to upgrade away from IE 6 was just never worth my time, and I get no satisfaction from having to hack up my own code in a less than beautiful way to make it happen.

More recently I’ve grown perversely attracted to the idea that I can say “no” to projects and still make a living. There is an axiom in the financial markets that the deal of a lifetime comes along every day, every week, every month, etc. Saying “no” to a mediocre project leaves you open to take on the great project that comes along right behind it. But even at a smaller scale, such as an enhancement request, it feels really good to not only say “no” to a client, but also back up that response with statistics that make great business sense. It wasn’t always a comfortable thing for me though, and I think it’s a privilege gained only through experience.

A couple of days ago I came across a decent article about the difference between a programmer and a consultant, which sums up the differences nicely. When we first start programming we are inevitably only a programmer. We just haven’t learned enough about the aspects of the business to know any better. We assume that our clients know exactly what they need and how to ask for it, and we program from the rudimentary specification that the client wrote on a napkin as if it were a punch card and we were a robot. Eventually, we learn to ask questions because we know the last time we tried to do something we hit a snag and that snag led to more work which led to late nights trying to meet a deadline.

Eventually you hit enough snags that you can start anticipating problems at the very early stages of projects. You know that the time it will take to integrating with a legacy system will depend heavily on the API that is available, or if no API is available then it will depend on the format that the system can export data in. You know that your client will probably want at least a few reports built in even if they didn’t ask for it. You know that even though the client didn’t mention any product options in the RFP, they will probably want at least 20 by the time the project is finished. This is the start of your transformation into a consultant. Armed with these questions, you start asking for answers up front. Instead of blindly following the client, you are now leading them into thinking about things they hadn’t considered before. Knowing what lies ahead is soothing to everyone involved. The more snags you anticipate, the clearer your path becomes and the more accurate your estimates become.

Do that enough times and you become what I call a “master of your domain”. You know the shit out of your job. You can anticipate problems. You know what works. You know current trends. You know passing fads. You know what questions a client should be asking even when they don’t. Spec to the platform? Hell no! You spec out the implementation and then tell the client what platform they need. You are no longer a mere programmer. You are a master of your domain. You are the conceded IT a-hole that Think Geek prints t-shirts about.

Well, except when you’re not. Because let’s face it: most of you are still saying “yes” to every request that comes across your desk, whether it’s making the site work in IE 6, or adding a Flash intro to a site, or implementing a feature that adds no real value to the project, or even spec’ing out a new project for a client that still gives you shit about invoices.

WHY? i ask you! You know that IE 6 is a piece of crap that even Microsoft themselves doesn’t support, and that no one except your stubborn client still uses. You know that it would probably be better for the landscaping company that hired you to not have a website at all rather than to add a Flash intro to it. (It will have pretty much the same net result.) You know that that new feature doesn’t add any real business value after you run it through the “why” stack gauntlet. And you know, know, know, know, know that your POS client is going to nickel-and-dime you over the quote that you already under-estimated because the true cost seemed like something they would immediately say “no” to.

You see, clients have no problem saying “no” to you. They know that they can find someone else who will say “yes”. For just as desperate as you are for work, there is someone else out there that is even more desperate for work who hasn’t figured out that they are a master of their domain yet. But you, you master-of-your-domain, you have leverage! You already tweet about why IE6 is terrible and should be ignored at all costs. You already have intimate lunch conversations with your colleagues about “Flashturbation” and why Flash intros are a terrible idea. You readily admit to anyone that will listen that fixed-bid projects are a sham and that you will just end up doubling or tripling the quote to cover your bases.

So, what exactly is keeping you from telling the client all this? You’ve got the ammunition. You just need to be able to tell it to the client in a way that makes good business sense. Dramatically expound on all of the security holes that IE6 creates, while spewing statistics about it’s decline in popularity and the terrible ROI rates that will result in spending more than 5 minutes making that jQuery slide show work in IE. Sagely report on the results of user studies that showed that most people skip over Flash intros or just click the back button and find another business to use. Judiciously walk the client through the “5 Whys” process so they see what little value the feature will offer. Confidently present your unaltered, non-fixed-bid quote that boasts of your use of agile methodologies, knowing that the client will ultimately get what they pay for, and that there are plenty of developers in India that will gladly program the next Facebook for $100. Fearlessly decline those silly RFPs that have illogical requirements, for there are plenty more well deserving projects out there waiting for you to nurture them to life.

In short, your experience in your field has made you a master of your domain. If your clients aren’t interested in listening to the advice of an expert, are you really interested in helping them grow their business?