Cashing In The Promises Of Diversity: A Hidden Challenge

When I joined ThoughtWorks, its software engineering practices took me by surprise. They confused me so much, that I could not even tell my colleagues what confused me. Or ask anyone for help. 

The Kanban board on the wall is a typical sign of “ThoughtWorks in the house”. And our way of managing the flow of our daily software development work.

I was in the middle of a professional switch of fields: From data science to data engineering. Before I made that switch, I assumed that it would be just a useful addition to my skill set. 

It turned out to be a lot more than that. I had to relearn the most basic elements of software development, even though I have been programming since I was 12. In effect, I learned a different way to look at all software development activities. It was literally eye-opening.

It opened my eyes to a very different way of seeing a familiar activity. And beyond that, it opened my eyes to how my colleagues not only talked about software development differently, or used different approaches. They actually perceived our software development challenges very differently. 

Practitioners in fields like data science or software engineering need to work with experts in many fields, such as business experts, designers, and operations engineers. The advice we often get is to communicate in the other experts’ language or find some kind of “pidgin“ that works for everyone.

From my experience, that advice is not enough. The differences begin already in how we perceive a situation, not just how we communicate our conclusions about it. 

Let’s have a look on how our perception works and what that implies for working in diverse teams. 

From stimulus to action: How does the world enter our minds?

Perception is the activity of our senses. The purpose of our perceptual system is not just to represent our environment, but to enable effective action in it. 

Schema of the neural processes underlying consciousness, from Christof Koch. Source: Wikimedia

Look around you. As you move your head, you will notice different things. Perhaps a table or a lamp. Maybe a window, a street or the sky. Those things emit or reflect light. Some of their light waves stimulate your eyes, arousing the receptors of your eyes. Your receptors' arousal triggers mechanical, chemical and electric state changes of the receptors, which then leads to electrochemical state changes in their connected nerve cells in the eyes and in the brain. 

Let's say you now realize that it is time to turn on the lamp on your table. Other nerve cells in your brain will be triggered by that decision and plan how you will turn on the lamp. These plans, represented again by electrochemical state changes in your nerve cells, will trigger the muscles of your arm and fingers to reach over and press the light button.

NEO: Is that ...

CYPHER: The Matrix?

Yeah. NEO: Do you always look at it encoded?

CYPHER: Well, you have to. The image translators work for the construct program. But there's way too much information to decode the Matrix. You get used to it ... I, I don't even see the code. All I see is ... blond, brunette, red-head ..."

— The Matrix, (1999)

When we perceive, we take in information based on stimuli. But that information is not identical with the physical properties of the stimuli. For example, when you read this blog post, you don't just perceive light waves of different intensity. 

You take in the meaning of the words. Someone who does not understand written English would perceive this text very differently, even though the physical properties of the text are the same. 

The information contained in a physical stimulus thus depends on the perceiver's cognitive abilities. Other examples include musicians trained to analyze music by ear, and the refined taste perceptions of chefs. Or, in technical domains, being able to read assembly code, understand the output of a Python debugger, and interpret a Sankey data visualization.

In all these cases, we combine the data from our senses with information not coming from our immediate environment. We do that even in cases of seemingly simple perceptions: I'm sure that the phone sitting next to my laptop will continue to exist, even when I'm not looking at it. When I look at it again, I see it as the same phone as two minutes ago — without actually checking whether a magician secretly replaced it. (Maybe with one with a better battery!). That certainty is based on knowledge, not just data I perceived. 

We all perceive the world from a different perspective

Since our ability to perceive depends on our knowledge, each of us will miss potential information in the world. We simply cannot decode its meaning. Reality has a surprising amount of detail.

And because our backgrounds, experience and expertise are different, we will perceive the world with a different perspective. Even when we are given the same situation, such as working together on a technical problem. The more different our backgrounds or expertise, the more different we will perceive the situation. 

We do not just use different words to describe a challenge or a solution. A direct translation of the terms of one area of expertise into another will not be enough. We will also not just think about a problem with different models. So explaining our concepts and approaches might not be enough either. 

An old engineering joke illustrates this: 

Sally, a retired engineer, is called into her former factory by her former manager, Tom. A crucial machine broke down and nobody knows how to fix it.

Sally grabs a hammer and whacks the machine. It starts right up and the production line recovers.

She leaves an invoice for 5000€. Tom, outraged about the costs, demands an itemized bill. Sally complies:

• Whack with hammer: 5€

• Knowing where to hit: 4995€ 

How can we work together better in diverse and interdisciplinary teams?

Differing perceptions are a core strength and challenge of diverse and interdisciplinary teams. Diverse perceptions let us see a fuller picture in any situation. We are less likely to overlook crucial details and more likely to react appropriately.

The parable illustrated on a temple wall in Thailand.

Source: Wikimedia

If only we could stitch the different pieces together! 

It is like in the parable of the “Blind Men Appraising the Elephant”. Once upon a time in India, a group of blind men encountered an elephant for the first time. Each of them explores the elephant by touching a different part. One of them starts at the tail and claims: “This elephant is like a snake!” Another man starts at a leg and concludes: “The elephant is like a pillar!”. Yet another of the blind men touches the trunk and shouts: “I got it: Elephants are something like tubes!”

Just like them, we need to figure out which part of the elephant we are perceiving and how they fit together. (And of course, they will fit not every time. We might be looking at entirely different animals without even noticing!)

This is the age-old question of how to increase empathy. Some principles that have worked for me in such situations:

• Show, don't tell — Provide experiences rather than conclusions

• Agree to agree — On major decisions

• Agree to disagree — On minor decisions. 

Show, don't tell

Every writing teacher drills that sentence into the heads of their students. It is good advice — if we can help someone see a situation the way we see it, they will better understand where we are coming from. Or vice versa, if we want to understand someone's conclusions, it will help to drill down to how they perceive the situation. 

• Share what the important details of the situation are to each of you: Drawing and telling stories with sensory details help. Sometimes, shared vocabulary helps. There is a practical reason why medicine students memorize the parts of human anatomy in their first semester — it helps them both tell all those details apart and talk about them. As a tech professional, knowing the terms for the elements of your hardware, libraries, operating systems and other tooling will help you both identify and talk about them. Each field has its own core terminology that defines the basic elements that practitioners can tell apart. 

• Use the same tooling for enhanced perception: Many fields use tooling to enhance their perception. For a biologist, that might be a microscope. For a psychologist, an MRI scanner. A software engineer relies on debuggers, logging and monitoring software. A data scientist on many types of data visualizations. Most of this tooling requires training to be useful. Learn to understand the perception-enhancing tools your colleagues use. 

• Understand your colleagues’ methods to isolate different stimuli: To break complex phenomena into manageable observable chunks, many fields have developed specific observation methods. Often, these are variations of formal scientific experimentation protocols. Sometimes, these are more informal hypothesis testing methods such as the lean startup MVP framework or test-driven development. Those methods are often core to how a person approaches a situation.

• Give each other feedback and reflect together: Four eyes see more than two, as do four ears. Sharing and receiving feedback on what you perceive to be important in any given situation will help avoid blind spots and misconceptions. 

Agree to agree

Take important decisions together in the team. That requires all sides to provide enough context for anyone else in the team to contribute to the decisions, from defining the problem to be solved to deciding on a solution.

A data scientist should be comfortable to chime in on the monitoring solution for their machine learning service. A backend engineer should feel equally comfortable with a decision on whether to use Jupyter notebooks for model prototyping. 

Agree to disagree

Decisions that do not affect more than one role in the team are minor enough that they can be delegated to that role. Even if you don't like your colleagues debugging practice, you can leave it to them to pick whatever they are comfortable with. 

Looking back

Looking back at my experiences starting at ThoughtWorks with what I know now, I would approach things a little differently. 

ThoughtWorks already has a great culture of balancing shared and individual decision-making. But I definitely could have made use of the principles in “Show, don’t tell”. 

Some new things I learned are: The importance of test-driven development (a method to isolate stimuli for software engineers), monitoring (tooling for enhanced perception) and evolutionary software development (emphasizing different facets of software architecture). Had I known to look out for such things and recognize them earlier, I would have felt less confused in my first months.

What has worked for you in situations where you worked with colleagues of interdisciplinary and diverse backgrounds?

I would love to hear more principles that worked for you! Please reach out to me with your suggestions! :)

My contact details are on the top of this page. 

Thanks to Marielli and Kat (again, and again!) for your feedback!