Case Study · MindSonar in Action

How MindSonar Can Turn Awareness into Observable Change in a Team of Technical Leaders

What happens when communication problems in a team have been around for so long that people start to see them simply as “the way we work”?

That was the starting point for a development programme we designed for a group of leaders working in a technical environment.

The organisation works with an interesting leadership model. Projects are run in pairs. One person manages the project from the office, while their partner works mainly on the client’s site, responsible for the technical delivery of the project and for leading the team on location. On paper, the two roles complement each other perfectly. In practice, the organisation kept running into communication difficulties, both within these leadership pairs and across the team as a whole. Information did not always flow the way it was expected to. Different interpretations of the same situations led to tension. Collaboration sometimes became less effective precisely when projects became more demanding.

These communication problems were the reason the organisation first approached us. Instead of starting with communication skills, however, we decided to carry out a diagnosis (interviews with team members) and go one level deeper. We asked ourselves:

That question became the starting point for a development programme built around MindSonar.

Looking at thinking in a specific context

One feature of MindSonar that mattered particularly in this project is its contextual approach. The aim is not to describe what kind of person someone is. Instead, we look at the thinking styles and values that become active in a specific context. That distinction makes an enormous difference. The same person may use completely different thinking strategies when running a routine meeting, talking to a client, developing a new idea or responding to a crisis in a project.

That is why we chose a very specific context for this programme:

This was exactly the moment when collaboration and communication mattered most, and the moment when existing patterns of behaviour were most likely to become visible. Each participant completed an individual MindSonar profile and then had a one-to-one session to interpret the results. We did not analyse thinking styles as scores isolated from one another. We looked at how different thinking styles can reinforce or balance each other and how, combined with Graves drives, they can translate into observable behaviour.

For example, a strong Internally referenced thinking style can support independent judgement. Combined with strong Order and Security drives, however, the same pattern can, under pressure, make it harder to take in perspectives that challenge one’s own assessment of the situation.

Similarly, a strong Away from orientation can be a huge asset in a technical environment, because it helps to identify risks early. Without enough access to Towards, however, attention can become dominated by what might go wrong rather than by where the team actually wants to go. Towards is about setting priorities and focusing on what we want to achieve, and it can lead people to overlook obstacles. Away from, in turn, helps people notice risks and anticipate difficulties, and it can make it harder to hold on to a clear goal and priorities. Neither way of thinking is better by nature.

The question to ask is:

Next, we combined the individual results into a group profile. This brought another level of insight. An individual preference does not automatically become a team problem. When similar tendencies show up in several team members, though, they can start to reinforce one another.

What one person sees as “normal” can gradually become the team’s collective way of operating. This is where the project became particularly interesting. The group profile pointed to several areas that could potentially limit the team’s effectiveness. When we discussed these observations with the participants, the reactions varied.

Some recognised them immediately:

“Yes. That’s exactly what happens.”

Others were less convinced.

They understood the profile intellectually, but they did not necessarily recognise the behaviour in practice. For some of them, these patterns had become so normal that they were simply part of everyday reality.

That was when we faced a choice. We could explain the results in more detail. We could show more slides. We could give more examples. Or we could stop trying to convince them. We chose the last option.

Don’t explain the pattern. Let people experience it

During the first group workshop, after introducing participants to the MindSonar model, we used a training game designed to create conditions in which the patterns identified in the group profile could come to the surface.

The purpose of the exercise was not to prove that the profile was “right”. It was to create an environment in which participants could observe themselves and others in action. And that is exactly what happened. As the exercise unfolded, behaviours that had until then existed mainly as scores, descriptions and hypotheses started to become visible in the room. Participants could see how they exchanged information.

They could notice what happened in moments of ambiguity. They could watch who started acting, who waited, who asked questions, who looked for structure, who focused on what wasn’t working, and what effect these different reactions had on the whole group. During the game, these were no longer theoretical descriptions. The behaviour was happening right in front of them. And that changed the conversation that followed. Some of the people who had initially questioned whether the identified weak spots really existed began to say, in essence:

“Now I can see it. We really do this.”

This was an important turning point in the whole programme.

Knowing is not the same as experiencing

The experience reminded us of something that is easy to overlook when working with diagnostic tools. A profile can create awareness. Awareness on its own, however, does not necessarily lead to change. People can understand the interpretation of their profile cognitively and still keep it at arm’s length:

“Interesting.”

“I can see why the profile shows it that way.”

“Maybe I do that sometimes.”

Experience works differently. When people see their own patterns emerging in real time, and at the same time observe the effect those patterns have on others and on getting the task done, it becomes much harder to treat that information as something external. This shift from abstract understanding to observable experience became one of the strongest elements of the programme.

From the group to the leadership pairs

We did not want the programme to end with a shared insight, though. Each participant also received three individual development areas drawn from their MindSonar profile and the specific context of the assessment. The next phase therefore moved the work from the level of the whole group to the level of the leadership pairs. These sessions combined mentoring and development. Their aim was not to discuss a participant’s “weaknesses”, but to explore how a potentially useful thinking style can become less effective in certain circumstances.

That distinction is essential. A strong Procedure preference, for example, can provide reliability, continuity and the ability to see a task through systematically. In a situation that calls for improvisation, however, the same preference can become a limitation. Procedural thinking supports step-by-step delivery, and it can become a problem when procedures fail or circumstances demand improvisation. Development, then, does not mean trying to replace one thinking style with another. It means increasing cognitive and behavioural flexibility. The question becomes:

In the pair sessions, participants explore exactly this question and work out practical mechanisms that can help them when their “automatic” response stops serving the situation. This matters all the more as pressure rises. In other words, the development challenge is not necessarily knowing what to do when everything is going well. It is about being able to reach for a different response precisely when our automatic pattern is at its strongest.

A scorecard written by the team

The final stage of the programme brings the whole group back together. And here we deliberately move away from abstract development goals:

“Let’s communicate better.”

“Let’s take more responsibility.”

“Let’s work together more effectively.”

These statements sound positive, but they are hard to observe, and therefore hard to manage. Instead, the team created its own scorecard: a behavioural scorecard built around concrete opposites. At one end of the scale are the behaviours the team wants to see more of. At the other are the behaviours that work against effective collaboration. The point is not for someone from outside to tell the team what “good collaboration” looks like. The team has to create its own shared language for the behaviours that will mean good collaboration to them.

Once the behaviours are defined, the team decides where it currently stands on a scale from 1 to 10, and then draws up a list of specific behaviours that will help it move even one point in the desired direction. This way, development becomes concrete and measurable.

One line of the team scorecard

← Behaviours that work against collaboration

Behaviours the team wants to see more of →

1

2

3

4

5

6

7

8

9

10

▲
today

▲
+1

Both ends are named by the team, in its own words. The team marks where it stands today and agrees on concrete behaviours that will move it one point in the desired direction.

What we take from this project

For us, one of the most important lessons from this project is that an assessment does not have to deliver a final answer. It can offer something more useful: a hypothesis worth testing. MindSonar allowed us to identify patterns that may affect collaboration. The individual profiles made them visible at the level of each person. The group profile brought out the tendencies of the team as a whole. The training game completed the process and allowed participants to experience these patterns together.

Soft skills, or effectiveness?

We were working with a group of engineers for whom development meant, above all, one thing: more technical knowledge. Communication, self-awareness, flexible thinking? That already sounded suspiciously like “something from HR”. MindSonar allowed us to stop trying to win them over to “soft skills” and start talking about effectiveness instead.

Two people can have equally strong technical competence and yet, under pressure, analyse a situation, make decisions and respond to a problem in completely different ways. One acts immediately, the other analyses first; one sees mainly the risk, the other focuses on the goal. Suddenly it turned out that what they had previously called “soft” had very concrete consequences for the quality of decisions, for communication and for the outcome of the project.

MindSonar let them look at their own thinking almost as a system:

Input

The situation, e.g. something goes wrong in the project

→

Way of processing

Thinking styles and Graves drives active in this context

What MindSonar makes visible

→

Response

Act at once or analyse first; focus on the risk or on the goal

→

Result

Quality of decisions, communication and the outcome of the project

And if you can see the mechanism, you can also check where it is worth optimising. Development stopped meaning “working on yourself” and started to mean increasing your own effectiveness and flexibility.

Because when a project starts to fall apart, an engineer’s most important tool is not always their knowledge. Sometimes it is the way they use their own mind.

And perhaps this is where development really begins.

When people recognise their own patterns in action, see their consequences and discover that what used to seem simply “the way we work” is something they can consciously influence.

MindSonar · Because you are so much more…