I've dealt with a few clients over the years who have wanted, understandably, to stick with the project at every turn. For the most part I haven't had any issues with that, but when I start hitting a bug, I often find it difficult to explain what's going on to them. I could go into detail and write out paragraph upon paragraph of everything I know as a developer and everything that's ever happened in my life that might apply here, but that's just a waste of my time and theirs. Generally I explain at a super top-level, knowing that if they don't really understand it but think they do, it'll all be resolved in a day or two and it won't have made any difference.

That works in most cases, but sometimes I find an email in my inbox from them saying something along the lines of:

So we know you've been having some trouble with this one problem so we spoke with a developer friend of ours and told him you've been facing this, and he suggested you try this.

Except the explanation I gave them was, while not untrue, a fairly dumbed-down form of what was actually a legitimate problem worthy of actual thought.

How much time should be spent explaining problems to clients, versus actually solving the problems?

  • And please, anyone who's more used to this site, let me know if this question is too subjective for here or anything. I'm a Stack Overflow guy mostly, so I'm used to everything being clear-cut, but I get the impression for some of these that a bit of subjectivity or looking for suggestions is okay. Jul 15, 2014 at 4:27
  • 1
    This question is currently in our self-eval review queue. It's a good question, but how can we make it easier for people to find from google? What search terms did you use before asking here, and would those terms make a better title? Thanks!
    – jmort253
    Sep 3, 2014 at 5:07
  • @jmort253 interesting, that makes sense. Hmm. I think the key question I'd use to paraphrase the question for brevity would ask something like "What's the best balance between explanation and debugging?" But I'm not sure that that's broad enough to be a good title for SEO, nor descriptive enough to attract attention. Sep 3, 2014 at 6:24
  • The bigger key I think is the SEO. Most visitors to our site are the silent majority of visitors who don't have accounts. Many land here from google searches where they're looking for answers to their problem. Whatever makes this more visible in search results helps those people. If any ideas come up, feel free to jump into Freelancing Chat or Freelancing Meta, or you can even give the post an edit yourself. We're always looking for ways to improve the content. It's what makes Stack Exchange so great.
    – jmort253
    Sep 3, 2014 at 6:31

3 Answers 3


Now, how much information is too much?! Ideally, clients should be aware of all good things happening in the project and be unaware of all bad things like bugs or bottlenecks.

You can achieve this with some clients, but you cannot with others. I go into the same situation as yourself, and the more I talk about the bugs and involve the client into bug details, the more they don't rate me as an expert. Let's say, I am rated 4 out of 5.

So, if you can, avoid details about bugs or other bad things. If you need more time, just tell them why, and use neutral words like "optimization" or "refactoring" or "speed up the things".

There are however, rare cases when the client is a developer as well. And in such cases, you can talk to him about the issues because that person will understand you, and that person may be able to help as well by googling and sending you good links. You do need help from a programmer when solving problems, but you do not need help from non-programmer.

  • 1
    I think this can backfire sometimes. If two programmer-types disagree on something, yet the other holds a great deal more power, like writing the checks, that can lead to problems. Unless you have a good rapport with the client developer, you could end up getting micromanaged.
    – jmort253
    Sep 3, 2014 at 5:10

Don't try to explain anymore than the customer is fully able to comprehend, otherwise the discussion will never end.

At the end of the day, what the customer should care about is impact:

  • how long will this delay the project
  • what are the trade-offs for the possible solutions
  • what are the alternative solutions if the issue can't be fixed

In your discussions with the customer, you should spend more time explaining the impacts and less about the specific details of the problem.


Don't engage non technical clients in technical subjects, unless you're being paid to train on technical subjects.

Invariably you will get the non-technical client with a little knowledge and a lot of ego. THIS client will wear you down trying to show how much he or she knows. This client is a technical wanna-be, but you can never say that because the client's helping to get your bills paid. He/she will talk, and talk, and talk in order to seek your acknowledgement (i.e. to feel smarter) --- and you'll waste a LOT of time.

It's okay to explain that such-and-such isn't working correctly. But leave out technical terms as much as possible so that the non-technical person doesn't latch on to jargon and end up suggesting that you allow the client's son/daughter, the "HTML expert because he took a class in high school", become an unwanted contributor to your work product.

  • +1 for the "HTML expert because he took a class in high school". It really sucks when it happens; somebody is trying to be smart while you know you are the expert. Happens in real life as well, office works, restaurants, you name it. The key here is, never, never, never! allow your client to contribute directly. Otherwise you'll never finish. If they insist after repeated requested to stop, it's not a bad idea to drop the client - they don't trust your professionalism and it's not worth spending so much time with them for little money.
    – kevin
    Sep 6, 2014 at 18:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.