The problem is simple: do people think the same way? Of course we all think differently. So why is this not often taken into account in our definitions of diversity?

Our thinking style can be measured, understood and appreciated, leading to greater personal satisfaction in the work situation and in life.

The OECD Observatory of Public Sector Innovation published content on diversity and inclusion based on a traditional view of diversity – race, gender, disability, education, experience, etc. These diversities are useful, but they are what we see with our eyes or defined in obvious ways.

We cannot easily see into each other’s brains. The danger is that we judge someone’s ideas based on what we see, rather than on their thinking style, which is not easy to see. This difference is known as cognitive diversity. It is a useful diversity for collaboration. To be clear, this form of cognitive diversity has been part of innovation tools for decades.

Dr. M. Kirton was a psychologist and academic researcher who in the 1960s studied how executive teams made decisions for major change. He looked at the problem the teams faced and the decisions they made. Then he interviewed each executive about the problem and the solution. He noticed that some executives were very structured and detailed in their thinking and problem solving. He also noted that others were almost the opposite; executives were open to totally unique and more flexible and spontaneous solutions. This was published as a Management Initiative study in which he concluded that by studying problems and solutions, he found that solutions often did not effectively solve the problem. Predictable mistakes were made.

By studying problem solvers, he noticed different patterns or thinking styles in how people solved problems. This was the cognitive style.

He noticed that those who were more structured preferred solutions created from a more structured process; those who were less structured preferred solutions designed from a more open creative process.

He concluded that executives were unaware of their thinking style and how it affected the solutions they proposed. The lack of awareness of their personal thinking style led to a cognitive bias in the style of solutions to solve a problem.

When a unique solution was needed to solve the problem, executives accepted solutions that only modified or improved the situation. Conversely, some executives wanted to innovate new approaches when the problem only needed improvement or expansion.

STYLE VERSUS BEHAVIOR

An important aspect of style is that it is not the same as behavior. You can’t change your style, but you can change your behavior.

When you use your preferred style, it will feel easy, automatic and natural. Your preferred style will require little effort or concentration and give you “normal” results.

You are also able to use other styles, but these will feel uncomfortable, require more effort and (especially in the beginning) produce results that you think are not as good as what you are used to. We define problem-solving styles as follows:

Problem-solving styles are consistent individual differences in how people prefer to plan and execute generating and focusing activities to gain clarity, produce ideas and prepare for action. Preferences are natural tendencies that support productivity.

Let me describe two problem-solving styles. As you read, note the traits that most closely resemble you; ask yourself which one resembles you the most.

Problem solving style 1:

• Maybe you prefer to do things “better
• You like to think precisely and methodically.
• You prefer to solve problems with incremental improvements and change.
• You prefer solutions that are tried and tested and practical.
• You prefer group consensus when making decisions.

Problem solving style 2:

• You may prefer to do things “differently
• You often think through tangents to explore ideas.
• You preferentially test assumptions, which can lead to radical thinking.
• You prefer to produce many ideas; some may seem wild at first.
• You have less regard for group consensus when making decisions.

Which comes closest to your problem-solving style? The first is called a developing thinking style. The second is called an exploratory thinking style. Are you more developer or more explorer? The research tells us that our ‘ problem-solving style ‘ falls on a continuum somewhere between strong developer and strong explorer; and has a normally distributed Gauss curve. Your cognitive style is innate. There is no evidence that it changes as you get older, more experienced or more statusful…. If you look at these traits, you may see differences in children. Do you recognize them in your partner, a sister or brother, or those you work with?

To clarify, I use these features for a simple explanation. In practice, people can use an indicator called the VIEW. During the 1990s, professors Don Treffinger, Scott Isaksen and Ed Selby developed the indicator VIEW. In addition to Kirton’s insights, the insights of Dunn & Dunn, Kolb and McCarthy also helped.

Which style is better?

This question serves no purpose. One style is not better than another. Your style has made you successful. Both styles gain clarity, produce ideas, and plannan action. But they do so in different ways.

Explorers are great when several ideas are needed to solve a problem. Developers are great for bringing order and structure to a problem.

It cannot be stressed enough that style is not capacity. Which way we approach problems is very different from how well we can solve them. There have been many studies over the years in different countries that support this contention.

VALIDITY AND RELIABILITY OF VIEW

Any safe assessment needs good psychometric properties of reliability and validity. In general, an instrument is reliable if it measures what it is supposed to measure and is valid if it accurately predicts performance.

VIEW measures the different problem-solving styles . These insights help with creative problem solving (CPS).

The gold standard for evaluating assessments is The Buros Center for Testing and their summary of VIEW is as follows:

The developers of VIEW took a complex and dynamic construct (creative problem solving, problem solving style) and tried to dismantle it into three component dimensions (Orientation to Change, Mode of Data Processing and Mode of Decision). They have done an admirable job of refining the instrument over time, validating their structural model and providing adequate validation support.

Buros concludes:

The VIEW appears to be what it purports to be, a measure of problem-solving style preference.

Applying this concept

If you are working alone on a project or problem, call it “Problem A. You can solve Problem A in any way that feels right for you.

Suppose you have a team to work with. This creates a second problem, “Problem B. This is the problem of effectively managing collaboration to solve your Problem A.

What is the bigger issue now? I suspect you can remember team efforts where conflicts got in the way of a good result. If you don’t solve Problem B as a priority, two things can happen You spend too much energy and time trying to reach agreement. The result is a weaker solution or the inability to solve Problem A effectively.

The study of people as problem solvers rarely looks at the differences in how people solve problems and what we can learn by expanding our understanding of diversity. For example, should we differentiate between people to match the problem that needs to be solved with people who have the best thinking style to solve it?

Implications

The lack of understanding of cognitive diversity can lead to weak collaboration because people fail to recognize that disagreements can be based on differences in thinking styles, not the ideas we prefer. You should discuss collaboration at the beginning of the problem-solving process to minimize the impact of problem B.

If you read the growing body of work on behavioral insights, you see hints such as “people prefer structure in their work.” If you believe in cognitive diversity, you can’t accept such generalizations. The same goes for design thinking. People use personas that exhibit common behaviors, but this approach lacks insight into how thinking style influences behavior. I believe design thinking would be more effective if design thinkers understood cognitive diversity.

For all these reasons, we need to revise our understanding of diversity. We know that people do not think alike. Imagine if we applied this understanding to our efforts to solve problems, collaborate and design products and services for the public. We might find that our results are more productive and seen as highly creative by the public. On a personal level, we could understand how people create ideas and could “stop killing ideas from people who don’t think like you. These are good goals for all employees and our organizations.

Take a step toward each other

If someone is struggling in a work situation, there are at least three things to consider. The person may not believe adaptive behavior is necessary, there is a lack of motivation, or they are facing a new problem and don’t know how best to solve it. Identifying why someone is not exhibiting adaptive behavior can help you guide them and improve collaboration.

Working together, mutual respect is key to help recognize where each team member can excel or has difficulties given the problem at hand. Humility is also important to recognize what may be difficult for yourself given your problem-solving style.

To lead those who are more explorer than you, you must help them see the importance of following a process and having group consensus. An individual who is more of an explorer can learn to think through the details of their ideas and work out the logistics. Sensitivity to people and past decisions are important. The person with a more exploratory style can learn to hold back any idea, recognizing that it may be irrelevant or inappropriate to the current conversation. Helping them see that efficiency, stability and continuity may be needed to move the team forward.

To lead those who have a more pronounced developer preference than you, recognize their need for more structure and clarity. Invite them to generate ideas outside the box. A person with a more pronounced developer preference can learn to recognize when too much focus on processes might slow the team down, given the problem at hand. Focusing on unnecessary details can distract from the end goal. People with more pronounced developer preferences can learn not to be too quick to judge what might be seen as an impractical idea. Help them see that questioning past assumptions may be necessary to move the team forward.

Show appreciation

Too often we see people criticized when they don’t do well enough. That stands out and doesn’t help. Instead, show appreciation for people who are up to the task and daring. It is stressful for them to do this and they are doing their best to support the team. The next time a challenging problem arises, you want them around.