Human-to-human communication

I started my tech career on the help desk serving an all-of-government web hosting solution. I often think of this as a bit of a trial by fire, as a fresh-faced graduate I was suddenly in contact with hundreds of working professionals all having issues with a system that I was getting familiar with at the same time as them. I was in this role for a number of years and must have completed thousands of support requests in that time.

When I left that role I thought that my help desk days were behind me, but a funny thing happens in tech, the higher up the chain you go, the closer to your customers you become. These days I am often in and out of meetings with customers, hopping in to manage help desk tickets and chatting away in slack with our customers.

In this age of AI chatbots it’s important to remember how important it is for humans to talk to each other to solve issues. Here’s a few principles I’ve used over the years that have been helpful for me.

Blameless language

You’ve probably heard this term used before in a bunch of contexts, especially if you’ve been involved in a modern tech incident and the following incident review. Focussing on speaking in a way which doesn’t place blame (or make someone feel like they are being blamed) is really useful. As soon as people feel like they are having a finger pointed at them or their actions they can shut down or become combative towards you - this isn’t helpful for anyone.

A very concrete example of blameless language is to avoid using “you” and “your” in both verbal and written communication. This may sound a bit silly or unnatural on the surface, but consider the following sentences:

• You didn’t implement the integration, so [thing] doesn’t work.

• The integration hasn’t been implemented, it’s needed to make [thing] work.

The first is an example of blameful language. It may be the truth - “the integration” hasn’t been implemented, so of course the thing doesn’t work - but this kind of language points the blame squarely on the person you are speaking with, whether you meant to or not. That person may not be in charge of the integration, they may have never heard of the integration and have no idea what you are talking about and now they feel squarely responsible for a failure with it.

The second example is using blameless language. This is also stating the truth, but without assigning the responsibility for that truth entirely on the person you are speaking with. This is much more likely to elicit a neutral or positive (and therefore useful in solving the issue) response from the person you are speaking to.

You and me vs the problem

This one is a natural side-effect of speaking blamelessly. It’s useful, especially when dealing with bugs or incidents, to avoid becoming defensive yourself (which can be especially hard when it’s your code or platform with the issue!). If you can avoid being defensive, and avoid using language that makes the person you are talking with defensive, then you can both put your energy towards identifying the root of the problem.

Two heads are always better than one. When you’ve got your customer on your side while you both look to fix an issue things will become a lot simpler. Even if you’re a super-brained 10x developer that “never” writes a bug, the beauty (and most terrifying part) of putting your code out in to the wild is the diverse groups of people that it will encounter and use it in ways you could never have imagined. When you are trying to solve a particularly tricky issue it is important that the person experiencing this issue wants to tell you about it; how did they first see it, what happens before and after it occurs, is there anything they do differently to their colleagues? all of this information can be the final piece of the puzzle that helps the two of you to fix an issue. If you don’t have a good relationship with the person on the other side of the issue you may not get all of the information that could have been useful.

Nothing is impossible

And I don’t mean that in the inspiring sense, I mean that in the “you could have introduced any number of bugs to your code that you don’t know about” sense. A good modern engineer writes tests, just the right amount of tests too - not too few, and not too many. And even with all of these tests, QA processes, manual poking about - things will break, it’s unavoidable.

So when someone comes to you and tells you “hey, every time I click this button the website crashes” you may be tempted to scoff and think “that’s impossible, not MY code, I wrote a test just for that!”. It’s important not to rule out the “impossibilities” until you have a good understanding of the issue. It may look like the website crashes but really something else happens that you didn’t account for. Diverse view points often means something someone says makes sense to them but not to you (we aren’t all 10x developers like you! it looked like a crash to me).

Of course this should be balanced with a good sense of scepticism to whittle down the potential issues. When we hear hoofs we should think horses, not zebras. But if there’s no horses in sight it might be time to start looking for stripes!