Ask HN: Coping when your client is an asshole?

> extremely aggressive and borderline abusive behaviour

Such as?

> In the beginning we we all agreed not to take anything personally and to let it just roll off the back.

Could you have done something differently here?

> We agreed to tighten up our processes and try to avoid confrontations by being super proactive with all our work

What does proactive mean in this sense? That it met client's expectations, or that it tried to pre-empt them, or something else?

> Ordinarily, we would have dropped the client by now and refused to put up with the end-justifies-the-means tactics

Tactics such as...?

> we're coming close to the launch date, and it's getting worse as more pressure mounts.

Where is this pressure coming from? Is it coming from you and your direct managers too?

> This is a very high profile project that stands to disrupt its market.

Is this what you tell your team? If so, that might answer the last question!

> It's exciting for them and us.

That sounds really positive. Does that mean there's a way to share that excitement?

I don't mean to be accusatory, I think this is important to explore if you want a decent answer without the confirmation bias.

I have fired 3 major clients of mine in the past 20 years. All of them started out fine, but turned so rotten and horrible I nearly quit each time.

But it's not just bad clients. Even some of my ok clients can be a pain at times, mainly due to schedules and stress.

Here's a few things I have found that help both with bad clients and "ok" clients having a bad time.

1. Patience and understanding: Seems obvious, but it's possible these people that are assholes today may really be on the edge of losing their jobs/business too. Not an easy thing to do, but takes a tiny bit of the bite out of their accusations.

2. Support tickets: Require (in some way) all/some requests go through a support ticket system. I have found this can help both parties with communication, so it's an easy sell without having to lie to them. Also, the more nasty they are, the more specific fields they have to fill out.

This turns a "it's broken and you broke it!" into -> "The form shows an error when submitting from an iphone."

3. At the extreme level, I have stated I will only do email communication and not talk on the phone. May work or not.

4. Don't answer the phone or reply to emails. Take a break for a while. I have to do this even with my ok clients. (my good clients I pick up on the first ring, and they treat me better than I treat them, or that is how it feels)

5. Set expectations CLEARLY. I found the biggest problems were when someone thought something was going to happen and it didn't. After many years of software dev, I tell people up front all the things that I know in the past have caused problems.

For example, I say "1/3 of the budget is due up front before we start work". If they come back and say "why haven't you started yet?" I can say "I have not yet recieved the up-front money". And refer to the documentation. (if they haven't read it, that's on them and it take a little bite out of their bark)

Another example is changes. I state clearly in advance, any changes from the specs (depending on the project how detailed they are) _will_ change the timeline and the costs. But even with this, I offer a number of minor changes within the budget. But also, I offer free bug fixes for _fixed_ period of time. All stated plainly up front.

The hardest part about this? When I forget to mention something, and I have to bring it up in the middle of a problem. It doesn't change the formula though.

It's like this: Client asks for 10th change. I say that is a "change order" and will cost extra. Client is mad because he's "expecting" it to be free. I apologize (the key here to take responsibility for my failure to communicated) for not making it clear that there are only 3 free changes, and in fact I have given 10 (demonstrate they have already gotten a deal). But I will give you one more (smooth it over some more even)

6. Accountability system: I had clients complain about "mystery changes" in their templates. I'd get viciously blamed for breaking a site. So, instead of explaining that my software couldn't possibly create broken html tags with a random copy paste. (because I know my code) I instead installed GIT on the dang server and every save from the client stored the account info, date stamp and even IP address.

That ended _every_ _single_ _complaint_ about template errors. (because _none_ of them were mine, they were all the clients fault.) Imagine having to tell your client it's their fault every time they call you? It sucks for both of you. I cannot emphasize enough what this meant to my sanity. Imagine going from a few complaints a week for months, to zero.

The first few times I had my client click the "history" button on a template and showed that it was either them personally, or one of their unskilled laborers that broke it, the accusations stopped. For ever. (I feel that relief again just writing this)

Since I don't know the exact nature of your project, GIT maybe won't help directly. But the idea might.

A universal CYA method would be include all client requests as part of the documentation to changes. (if this is part of the problem)

7. Take responsibility for your errors. I found that as soon as I made a mistake, and I owned up to it, it was easier to point out when something wasn't my mistake.

8. Ask them to be polite. One client (who I eventually fired) had two partners. At the end of the relationship, one of them just sent nonsensical email rants. I asked him to talk more politely, and he out right refused. So I asked his partner to step in, but he was a big wimp and did nothing about it. Now, knowing what I know, I would simply ignore the other guys emails, and just communicate with the decent guy.

Sometimes playing dumb works too with these things. When you are sick of something, just ignore their replies and just keep working and doing the best you can.

9. The owner/s need to step up. It hits a point where if the environment gets so bad that you start losing talent, then it's going to hurt the owner. It would be a good show of respect to get the owner involved in the problem before it's too late.

10. Build extra tooling. One project with a client (from #8 above) and sub-par developers that couldn't follow directions or solve any problems. I built an API and all sorts of stuff, documented it clearly, yet I got blamed when their stuff didn't work with mine.

My solution? I built _their_ stuff too. Or at least a very simple skeletal version of their system. Combined with multiple screen recordings of working with the API and the data. That _totally ended_ the complaints that my stuff didn't work, because it was really, really obvious that it did. (their programmers just didn't seem to know anything)

Final thought: I have found when I am teetering on the edge of falling over a cliff (despair/rage/annoyance/quitting/etc...) even the slightest bit of positive change can help me make the right decision. And making the right decision is always better in the long term. So get even small successes from any changes you can make may be all you need to get things on track.

This hits home for me, I've had such horrendous experiences with this stuff that I could write lots more. Hope you recover and everything works out. (sorry this got so long)

Think of the situation where the client is not an asshole but just incompetent, and the project does not pass simple logic tests, let alone business health checks.

And the only reason your project exists is because the client has to make himself busy and spend his budget.

And it pays you well, e.g 150% of market average. And you have extra perks, like the luxury to cycle to work through the forest.

And imagine living this life for years.

With family to support ahd kids on your back.

Um...

My suspicion is that business schedules and contract structures may have something to do with this.

I'm guessing pressure is mounting because a lot of money has already been paid out before they received a final working product. It seems that people like to create large lump sum project fees and collect them immediately. This leads to crunch time and pressure to collect working software without extending the contract for additional money.

If possible I think it's best to have contract structures that are actually billed for the time of the developers and also have relatively short releases. So the idea would be that there is some working software with some features, then every few weeks you add a feature or two. This results in less pressure than if there are very few software deliveries.

But it sounds like there is some fundamental contempt the other party has for your group. It is risky but in order to understand and possibly combat that you could try changing the mode of communication. Perhaps no emails and only phone or Skype or face to face. Maybe you can have a discussion about where the contempt is coming from.

Also if you haven't delivered software for awhile you may not want to wait until the delivery date. Although that could make things worse also depending on the situation.