While taking client works, it’s not uncommon to have to deal with bad clients. There are of course many kinds of such: the ones that don’t pay, the ones that don’t care what you do, or the ones that never satisfied with your work…
However, even the good ones (pay in time, committed, respect your work, rational …) are problematic in their own sense. In this post I’ll share my experience about whom I call half-baked or semi-technical clients.
Who are they?
There is the kind of clients who doesn’t know anything about technology, very typical energetic business guy who have an idea and just want to get it done. This is good.
And then there’s the kind who is as enthusiastic, and think that they know what it takes to talk technical. I found this to be the most time-consuming kind of clients to serve.
It’s not easy to spot them, they often appear to be nice, understanding and excited about whatever you proposed … in the beginning. They might also keep what they know to themselves and you can easily mistaken them as the non tech-savvy client.
Until… the project started.
Clear requirement, messy execution
Again, things are ok with scope and requirement. Since most of the work is on high level, it isn’t exactly technical and their thoughts are aligned with yours and they agree with your architecture model, how modules are structured and how the APIs to be designed, etc.. At this point most likely you already received your first upfront pay-check. The project’s prospect is rosy and full of rainbow.
Here’s the turn of the story, it becomes real messy when they are involved in the execution! First they think that they are giving suggestions to save your time by sending you links to StackOverflow issues. Then they also do the research for you by giving you bunch of websites to look at and say “I want this here combine with that there”. What’s the real problem here is that those SO questions are usually irrelevant or outdated. The sites that they gave are the options that you already taken into consideration before proposing the final solution. Hence you find yourself spending too much time shooting email back and forth explaining to them your choices and why the others were not chosen.
It doesn’t end there yet. When they are not convinced of your approach, they try to twist their words differently to how they understand the technologies and then “confront” you with the new version. After a few times if you are good then their version will be actually the same as yours except it is phrased differently, more lengthy, more complicated… and they are happy because they think they “improved” your design.
So far, you have not actually done much work except writing emails and stretching your brain to try to justify the underlying technical choices. Naturally, you are behind your schedule.
Destined for failure
The moment you give in and accept their way of doings, you unknowingly gave them the power and credit to continue over-shadowing your decisions. From here, you can see how it goes badly: they would question your moves, debate “technically” with you the best way to solve a quirk, even give you “minor tweaks” to the architecture that would give your heart a little break; or if requirements changed inevitably, they want to help you to “smoothen” the transition by suggesting how you should code it (urghhh!!!).
Oops, you allowed the devil in your bed.
The point is …
In the last week, I have sadly classified two of my clients into this category, one of them is actually a long-time client. There were times I kept asking myself why it was so energy-draining to speak to them and couldn’t really get out of it. Now that I kind of “get it”, I’m hoping by leaving my general observation and share my rant here, it would do good to others who are in the same line of business.
Sounds familiar to anyone you know or a specific incident you have? Leave it in the comments.