A technology architect’s guide to humans part four: they don’t know what you do all day (and you don’t know what they do)

Try this quick puzzle (without searching on the Internet or looking in the dictionary).

First, estimate how many words in the English language start with the letter ‘R’.

Second, estimate how many words in the English language have ‘R’ as their third letter.

The rough answer is that there are about 8,000 words that start with ‘R’ and about 25,000 that have ‘R’ in the third place. (English being the mutable thing that it is, estimates vary, but the proportions are about right).

Unless you have read the wonderful book by Daniels Kahneman, Thinking Fast and Slow, you probably got this the wrong way round. If you have read the book, you may recognise this as an example of the availability heuristic.

Kahneman’s book, and much of his research along with Amon Tversky, shows that we can think of the human brain as running two systems: system 1, which is fast and which helps us make quick decisions; and system 2, which is slow, and which enables us to reason about sophisticated problems. Kahneman argues that system 1 is dominated by heuristics: rules of thumb about the world which are broadly right a lot of the time, but which can easily go wrong.

The availability heuristic is an example of this: it is the rough rule that, if we can recall something easily, it is likely to occur more frequently in the world. This is useful if we are foraging for food (‘I remember seeing a lot of berries in that patch of forest; there are probably a lot of berries there’) but less useful in many other scenarios (‘It’s easier to think of words that begin with ‘R’ than words with ‘R’ in the last place, so there must be more of them’).

What does this have to do with technology architects and their interactions with other human beings?

Firstly, I think that all technology architects would do well to read Kahneman’s book, to recognise the heuristics in their own thinking, and to deploy tactics to engage system 2.

Secondly, and more importantly, I think that the availability heuristic can help us understand why technology architects and their fellow humans often get so frustrated with each other, and to figure out how we can avoid or reduce that frustration.

Because we do get frustrated with each other. Some degree of frustration is inevitable whenever humans come together to do complicated things: they will misunderstand each other; they will let each other down; they will underestimate how difficult things are.

But I see two types of frustration crop up particularly frequently: people who have a design job (technology architects and their equivalents) get frustrated with people who have a delivery job (project managers and their equivalents), because they feel that those people don’t understand what they do.

Technology architects feel that they are doing their best to find the answers to difficult problems: to put technology together in interesting ways to meet business needs. They have hard things to think about, and lots of people to talk to. They have investigations to do and references to read. They need to hunt down that pattern and understand why it didn’t work last time.

And the project manager just keeps going on about dates and delivery, asking when the design will be ready, and insisting that we should start cutting corners and cutting costs. They just don’t get it.

As ever, I have good news and bad news.

The good news is that, if you’re a technology architect and you find yourself in this situation, you are probably right. The project manager almost certainly doesn’t get it, in the sense that they don’t understand what you are doing or why you are taking so long. They are subject to the availability heuristic. If they have never trained or worked as a technology architect, they don’t have an available set of ideas about what you spend your time doing. Because they can’t think of many things that you could be doing, they will naturally assume that there can’t be many things that you aredoing.

The bad news is that, as ever, it’s your job to put this straight. There are two ways to break someone out from the spell of the availability heuristic. The first and best is to engage system 2: to take the time to explain to the project manager what it is that you do, and why it is important. If you really want to engage system 2 (and to work well with your fellow humans) it’s best to do this with respect and patience. The second is to make sure, that, if you can’t engage system 2, at least you can give your colleague some more examples for system 1 to work with: you can make the type of work you do more mentally available.

But there’s more bad news coming.

You use heuristics as much as anybody else. If you are a technology architect who thinks that your delivery counterparts just don’t get it, then you are probably applying system 1 and the availability heuristic:

• These PMs have no technical skills! (I haven’t seen them do technical work because they’re busy dealing with resource and organisational problems).

• That project manager is only capable of thinking in the short term! (I’ve never seen that person in a context where they’re not working to a tight deadline.)

• All they do is spend their time hassling me! (I only interact with them when they’re checking on my progress; I don’t see everything else they do.)

And the good news is that you already know how to address your own reliance on heuristics. Conscious engagement of system 2 - which might be a simple as asking your project manager how their day has been, what they are spending time on, and how you can help.

Those of us who are lucky enough to be technology professionals work in a complex field. However ‘full stack’ we try to be, there will always be specialisms, natural talents and different types of work to be done. Doing hard things will lead to us becoming frustrated. But if we consciously acknowledge our heuristics, try to understand what we each do for a living, we stand a chance of directing that frustration to problems, not people.

(This is the fourth of an occasional series of lessons learnt about how technology architects can deal with their fellow humans. Here are links to parts one, two and three.)