Tim Martin's blog

Not so long ago I had a misunderstanding with a colleague, who I’ll call Bob. I received a routine request for technical support from Bob, to which I replied immediately with a clear but brief explanation of how to solve the problem. An hour later, I got a slightly testy email from Bob to say that his problem still wasn’t fixed, and it was really holding him up. I double-checked that the proposed solution worked, silently cursed Bob for being too simple to follow my instructions and pinged back an email with a longer and slightly more patronising set of instructions. Two hours later, a furious email from Bob, copied to the CEO. Didn’t I understand how important this issue was? A critical project was in the balance, and I hadn’t fixed his problem.

The punch line? Bob’s email hadn’t been working all morning, and nothing I sent had got through to him. Bob’s emails read to me as if he’d got my instructions and somehow failed to follow them correctly, so it looked to me like he was being inept. From Bob’s point of view, I was giving him stony silence that could only be explained by a lack of motivation.

I’m sure this kind of problem has been plaguing the interactions between technical and non-technical people for as long as there has been technology to bicker over. Users complain about bugs that don’t get fixed, while techies whinge that the users misdescribe their problems, foul things up further with misguided attempts to fix them and then fail to follow instructions when they get them. Why isn’t it going away as people get more tech-savvy?

Behaving correctly when you encounter a fault and reporting it in a productive way is a reasonably subtle task; Simon Tatham’s piece on how to report bugs effectively is a very approachable and effective guide, but it’ll probably only ever be read by the motivated. Even so, you might think that sheer trial and error would teach people that certain ways of reporting a bug get the solution they’re after more quickly than others.

Some people suggest that we techies are lacking in communication skills, and that we need to work harder at making ourselves understood in order to engage with the modern workplace. This isn’t entirely without merit, but I think it’s facile. I’ve been lucky enough to work with some very articulate developers, and none have been immune to this kind of misunderstanding.

I think there’s something deeper going on here, and I think it lies in psychology. The fundamental attribution error is the observed effect that people tend to attribute other people’s behaviour disproportionately to their character, neglecting the possibility of simple situational explanations. For example, I attributed Bob’s inability to solve his problem to his not taking the time to read my instructions properly, or being too poorly-skilled to put them into operation. All the time I was building up in my head a picture of Bob as an incompetent, over-confident bumbling oaf who shouldn’t be trusted to go near a keyboard—and all because his email wasn’t working.

But it goes the other way too. I’ve no doubt Bob had painted a picture to himself of me as an uncommunicative nerd who didn’t appreciate the importance of Bob’s project to the business. Neither of us even considered that there might be an alternative explanation.

The thinking that leads to the fundamental attribution error makes some sense, when you think about it. When you’re dealing with someone on a casual basis you can come to great harm by not making an assessment of their character, and assuming that any flaws you observe are likely to hurt you again in the future is a sound defensive position. This might lead to missed opportunities in casual acquaintances, but that could be a price worth paying.

This thinking is catastrophic, though, when it becomes an entrenched pattern that prevents the very nature of the problem from being properly understood. Blaming developers for being aloof, or users for being incompetent, only reinforces the stereotypes. Working on our communication skills only helps if the thoughts we communicate are based on the right model.