The Art of Saying “No”

Programming for one’s self can be fun and fulfilling. You get to dream up challenging tasks to impress friends and peers. You get to show flashy boxes on the screen to prove to yourself how good you are at programming. Scratching your own itch will feel good, but it can be no more than an exercise in satisfying one’s own ego.

In this article, I’d like to explore programming for others. When others get involved in the creative process, your skills take on a radically new dimension. Working with clients is challenging because they don’t care how you solve their problem. What you call a “solution” can be considered “buggy.” What you consider “useful” can be received as “hard to use” or “too convoluted.”

Programming for others demands removing one’s self from the equation. Dealing with nonsense from clients while delivering a sound solution is challenging. But, it can be incredibly fulfilling if you know when and why to say no. I would like to explore how to effectively work with clients in the art of saying “no”.

The client is not always right

Clients come in all shapes and sizes, from versed in tech to software illiterate. But, regardless of the people you work for, they chose to come to you with a problem.

This means it’s your job to solve the problem, not theirs.

I once had a client tell me they used to write web sites in HTML. It felt like the mindset of that once proverbial twelve year old who wrote web sites in MySpace.

My client had always felt confident in their programming skills, and had become used to giving my team implementation-specific details. This caused the legacy system to have many disastrous usability issues: Terrible color palettes, unintelligible navigations, and frustrated customers.

To try and address this issue, I asked if the client could provide mockups in HTML. It wasn’t long before they realized that coming up with mockups is hard. As a result, I earned more freedom in delivering the best solution I could come up with.

It’s good to have clients with strong opinions — as long as you’re not getting micro-managed. But it’s more important to give yourself a broad canvas on which to imagine the best possible solution.

When a project fails to deliver, you’ll be the person cleaning up the mess. Your clients are relying on you for a reason and it’s your job to do what’s best for them.

Why they don’t care

When you plop someone in front of a computer, they don’t care about flashy or sophisticated software. For the most part, people are only interested in what it can do for them. Does it make my life easy? Does it solve major issues from a legacy system? Is it fast? Is it intuitive? And is it pretty?

The difficulty is clients don’t even know what to ask for until they experience it. Your job is to engage and figure out sleek ways to deliver on that experience.

I once managed a support inbox where my clients were either angry or irritated. I dreaded getting any feedback. They even copied my boss into the chain of nasty emails! After implementing a major overhaul, I noticed their mood changed. It was a long-drawn-out battle but worth the fight. At the end, folks were happier and a lot more helpful.

Great software should emotionally engage users, but anger is not the kind of emotion you are aiming for.

This helped me see I wasn’t just writing software for the computer, but a person. Your job is to get clients to engage at an emotional level. Making the computer happy is not enough.

Even when you let clients drive the solution for you, a client will not waste any time solving their own problem. A fascinating aspect of the human condition is clients would much rather wallow in misery than ask for help. This is why they hired you and are relying on you. When you face major set backs, it is often because they have other more engaging priorities.

It’s not about you

Writing great software demands concern for the other—putting yourself in their shoes, experiencing what they experience, and suffering when they suffer.

When I was managing an inbox of angry customers, at first I thought, “I am a web developer!” and I almost quit. But this attitude effectively put my clients beneath me. I didn’t exactly know this at the time, but somehow I felt I couldn’t just abandon them. Selfless sacrifice was necessary to take my skills to the next level.

To fulfill someone’s needs, it’s first important to let them know you care. At some point, you take on their experiences and sympathize on a personal level. In every way possible, take the time to work through their issues and figure out new ways to solve them.

Your client may not care about a well-crafted solution and beautiful code, but your job is to show that you do. Once folks experience the fruits of your labor, they’ll get hooked.

Keeping promises

What you say you are going to do is exactly what clients expect. In this industry, when you over-promise and under-deliver, you lose trust.

I once sat with a client to reach an agreement before I could complete a major overhaul project. They said there wasn’t enough time for proper testing and the project would get put on hold. I said I could do what they asked in one hour. I got scoffed at.

When we finally sat down to test the system, I pulled out jQuery. I read the basic rules back to them and got testing and debugging done within the hour. My client left feeling confident in the solution. They knew they would get exactly what they expected, and that was everything they hoped for.

Working through the issues and delivering on promises earned their trust. Getting folks to trust you is the best way to build a strong relationship with clients.

Conclusion

Saying no to customer nonsense is hard. Writing software is a social art that reaches far beyond the developer. Through this medium, you get to communicate emotion and confidence to another human being. You get to build relationships that will take your skills to the next level.

What I find is not so much about the no but the underpinning yes. The art of saying “no”, is about keeping folks happy, showing that you care, and earning their trust.

Have you ever had to push back on unreasonable client expectations? How did you manage it?