In your life, you are going to meet stressed out people who want to propagate their stress to you. While it can happen in a lot of domains, I am going to take an IT posture here: how should IT professionals respond to stressed out people?

Let’s start with the easiest part: why are they sending you all theses texts at 3AM?

People get stressed out because they get bad feelings⌗

Feelings? What’s that? You mean that I need to talk and understand people while my specialty is dealing with computers?

Your task when dealing with a noisy partner is to find out why they are.

They might tell you that X is the issue, but in reality, Y is the veritable one. Thus, your job is to ask “Why are you stressed out?”.

By finding out the root cause of their stress, you can work on the problem that matters

Acknowledge the situation⌗

Noisy clients are going to repeat the same information dozens of time until they are 100% sure that you understood them.

Here’s a basic checklist of producing acknowledgment:

  1. Understand the situation
  2. Summarize the situation
  3. Asks for corrections to the summary
  4. Pin it in the discussion
  5. Say that you are going to provide daily update
  6. Send the updates, say what changed and what didn’t.

The goal of the acknolwedgment phase is to bring notifications down to a reasonable level. Paradoxally, the best move in this situation is to cut notifications off on the discussion to avoid getting cluttered with too much information.

Remember: the time you take to talk about information you already have is time lost fixing your software.

Don’t let the stress propagate⌗

I personnally don’t have much stress in my life. I avoid it like the plague, but sometimes, I succomb to the noisy customers.

Their stress propagates to me and I forget what matters: I need to fix this bug; I won’t go to sleep unless I fix this bug!!!

Spoiler alert: this isn’t going to help. You are unlikely to find a short-term fix that will work, and you will nuke your productivity for the following days.

Once you find yourself in a stressful situation, ask yourself: Is stress going to help me there?

Good solutions are rarely found when under flight-or-fight mode, thus take a good rest; work on parts of your app that you like; take a bath; write a blog articles if that’s your thing - what matters is getting out of the high stress zone as soon as possible.

Once that’s out of the way, you can start working on solutions.

Design flaws are your enemy⌗

There might be a deep technical issue that is affecting your customer, but there might be a high-level one that can be fixed.

While I advise taking responsibility for issues, customers sometimes have their role to play in fixing their own problem.

I’ve had this generic issue come up multiple times over the course of my small career:

  1. The client asks for X
  2. You provide X
  3. The clients switches all their workload to X
  4. There are bugs and performances are bad in edge cases
  5. The client is unhappy

Here, the issue is an obvious design flaw: the client should not propagate 100% of their workload to your software on day one.

Software always has bugs. Even senior developers will make stupid mistakes, and uncanny edge cases can blow out the simplest software in the world.

Before you start working on your software’s problem, you might suggest to the customer to do a smoother transition. It’s even better if you can do it and warn them beforehand: as you may know, software development in our industry is full of edge cases and bugs. Please don’t nuke our production database.

Finding long-term solutions⌗

The stress of your client may reside in a technical issue deeply rooted in your software or business architecture.

If you find that it is the case, you can start designing solutions.

There is one rule that matters, and one alone:

Do the fucking laziest change that you can and see if it works.

Remember, there is a mother design issue that you can put leverage on to lessen the impact of your deep issue. Thus, you should be able to take as much time as you want to fix the deep issue. It might even turn out that the deep issue doesn’t matter.

The key is to do incremental technical changes instead of dramatic ones. Hop into your code and do a change, and tell your client about it. They will feel better (they are taking care of me!).

I’ve included a copy of my long-term-solution-finding process below with reasoning for it in a later section of this post.

Preventing measures compounds to free time⌗

Behind technical issues almost always lies a human issue.

To fix it, you can use the Five Whys, a technique proposed by Eric Ries and popularized by his book The Lean Startup.

I’m going to shamelessly copy Ries’ example:

  1. A new release broke a key feature for customers. Why? Because a particular server failed.
  2. Why did the server fail? Because an obscure subsystem was used in the wrong way.
  3. Why was it used in the wrong way? The engineer who used it didn’t know how to use it properly.
  4. Why didn’t he know? Because he was never trained.
  5. Why wasn’t he trained? Because his manager doesn’t believe in training new engineers, because they are “too busy.”

Once you have found your “five whys”, you have to make proportionnai investments for every one of them.

I’ll quote Eric Ries on the necessity of this technique, even in a startup environment:

Yes, start-ups are all about speed. And startups that act without discipline can go faster, just like a driver can go faster with eyes closed and a maxed-out accelerator. Being in motion is not intrinsically worthwhile.

Eric Ries

Take it slowly, and implement preventive measures. Over time, they’ll compound to more free time to build awesome features.

This may be stupid advice⌗

I’m a regular person getting tensed up by their customer complaining about a legitimate issue. The problem is that I have not yet created a good framework for solving these systematic problems. This blog post tries to address it.

My “angry customer” checklist⌗

Overview⌗

  1. Find out the “deep why” of the bad feelings of the customer
  2. Cut out the stress to be able to think smarter
  3. Search for and share business design flaws, e.g. abrupt transition.
  4. Go through the steps of the long-term-solution-finding process

Long-term-solution-finding checklist⌗

  1. Do a lazy fix (think: 10 lines of code or less)
  2. If not working, build a graph to track the issue (e.g. Grafana charts - this will tighten the feedback loop, meaning that you will understand what works and what doesn’t faster)
  3. Do a whole suite of lazy fix, benchmark them with your charts
  4. If performances stay unsatisfying, redesign your system (and benchmark it against your older one!)
  5. (you should have found a solution by now - if not, ask yourself: do I need to support this customer? Is their use-case going to come up later in my business?)
  6. Invest in proportional preventive measures

My next steps for the issue I’m currently facing (disregard this!)⌗

  1. Lazy fix that will nuke my database but might help
  2. Tracking of aforementioned issue on Grafana
  3. If lazy fix kills database, cache things inside Redis
  4. Redesign everything?

References⌗