In this article we will look at ways to use the mindsets or lack of one of them to the team's advantage or how to build a balanced team from the start.How to use the mindsets?

Balancing mindsets in the team is very important. Each mindset has its ups and downs and lack of each one of them can lead to teams underperforming. But do not worry, there are ways to balance the team. First try to identify which mindset team is lacking and which mindset is dominating. This will already give you a perspective on which areas of development or service production to focus the team's attention.

And another thing to keep in mind - people rarely trained to change mindsets. That is why usually it is hard for developers to test their own work, it is difficult to change mindset from solution finding to critical thinking. It is hard to think of your work in terms of “Why it might not work?” So you can train people to be able to change mindsets or, and that is a most usual case, you can have two people with different mindsets in the team to balance each other.

We will look at two cases. First will focus on building the team from the beginning and the other one will focus on “what to do” if the teams are already put in place and there is no budget or will to make changes to the teams setup.

When you are trying to build a team from scratch it is easy to balance mindsets. When you do the interviews for potential team members, try to give them some example tasks to see how they approach the situation, ask them to be vocal with their thoughts and tell you about the process that goes in their heads when they are trying to find the solution to the problem that you put before them. Try carefully to find out if they can change their mindset. Easiest way to do that is to simulate a situation that a certain mindset is best at. Ask potential team members what will they do if they receive next type of tasks:

• For “Ranger”, try to simulate a situation where the best way is to make a decision to actually not to do the thing that is asked for in requirements. So a feature that is in its core is proven to be a bad idea, and potential team members should try and find out if this is absolutely needed before committing on finding the solution. Tasks should be tricky, to check if the user will actually question the motivation for the task and ask why the user asks for this or this solution.
• For “Wizzard” the task should contain a not-perfect solution that a good wizard can easily fix by providing better ideas. Try to find examples where future employees should not solve the problem literally, but put ideas to the test and propose other and sometimes unexpected ways to solve the problem.
• For “Knight” it should be a straight solution finding task. There are plenty of tasks out there that require straight problem solving skills. As for many years this was the one mindset that was valued by employers. For environments that look for leaders or product owners it is always good to check if a person can actually switch from the Knights mindset, even if you are looking for a person that is driven by it.
• And finally for the “Rogue” find tasks with critical risk buried within. The task should aim to see if potential team members can spot the danger and bring this up before committing to find the solution.

To make a perfect balanced team, you want each mindset to be present. And if you build the team and it turns out to be heavy on one of the mindsets, you can predict potential weak spots for the team and help the team to build its processes to overcome them.

But often when building the team - you will have other priorities, like proficiency level, certain technology, experience, soft skills and many others. So most likely when you already have built your team or when you are trying to solve existing team problems, you can introduce techniques to overcome the lack of certain mindset.

There are plenty out there. We will list just a couple of examples here so you can understand the idea and choose instruments that will work best for your teams or even give them an opportunity to choose one if you are agile enough.

6 thinking hats is a great instrument that allows teams to go through each mindset and look at the problem and its solution from various angles. Requires good facilitation though. There are a lot of materials on this instrument on the web.
6 hats are:

Blue: “Big picture hat”

White: “Facts and information”

Red: “Feelings and emotions”

Black: “Critical judgement”

Yellow: “Positive”

Green: “New ideas”

For each problem you might use various combinations of the hats. Here is the link for 6 thinking hats wiki page.

The simplification of this instrument would be the 4 hats for each of the mindset. During kickoff meeting, planning or brainstorming sessions, ask the team to get into one of the mindsets (roles) and answer only questions that are specific for that mindset. We have talked about these questions in our previous article on this subject. Then look at the result and see if another round is needed.

Introducing design thinking can solve many inequalities in the mindsets if used properly. Just take it from the description:

Design thinking is a process by which designers approach problem solving. It incorporates analytical, synthetic, divergent and convergent thinking to create a wide number of potential solutions and then narrow these down to a “best fit” solution.

Again, plenty of information on the web, just search it up. It requires training and getting used to, but does not require heavy facilitation. Also, when properly used can bring a lot of joy to the teams.

The only downside of this method is that it will usually require a lot of change in mentality if introduced from scratch and for teams without experience can at first be not productive and as a result teams can resist to apply it.

While started as a theory of consumer action, this framework is actually very good for any problem solving. It makes the teams apply each of the mindsets across the whole problem, starting from initial need, to preparation, solving the actual problem and making sure that client receives exactly what he wanted.

Basically every problem is divided to steps:

• Define - describing the moment when the need is born
• Locate - describing process of how client finds the solution
• Prepare - describing what client needs to have before solving the need
• Confirm - describing how client is making sure that he can actually start solving the need
• Execute - actual execution
• Monitor - describing how user checks the progress and knows what to do next
• Modify - describing how user can modify the result to make it closer to what he ideally wants
• Conclude - describe how user finishes or how he can start another need solving process

When breaking the problem into these 8 steps, teams have to apply all mindsets to answer difficult questions that usually are left out. When the client actually starts thinking about the problem? What if the client does not have everything to solve the problem? How does the client actually know when the job is done and he is about to receive what he needs?

Here is a good example of Jobs-to-be-done framework description from the web.

These are good exercises for any problem solving process. Both “5 whys” and “12 elses” are widely described on the web and they help teams to dive deep into the problem and think outside of the box, applying various mindsets as they go deeper and deeper with each “why” or “else”. Pick a description best suited for your teams and ask them to try it out.

It does not matter if your company or business does not use organization type based on autonomy and self-organization. Even if you are not fond of those things you can still use parts of these frameworks to make your teams more flexible and organized. In particular meetings structures. Both frameworks introduce debate-free meeting structures that allow them to make decisions and come to agreements within a limited amount of time. By introducing these structures into teams problem solving or planning meetings you will make them use specific mindsets at each stage of the meeting, as debates are forbidden and people have only certain steps when they can ask questions, introduce improvements, raise concerns etc. These meeting structures are balancing mindsets on their own. The only downside is that they require everyone to comply with the rules and requires good facilitators to help teams lead meetings within the format.

Invite missing mindsets from other teams to participate in the meetings. Give them the round to express their mindset questions and concerns and let the team find a solution. Idea is not new. Cross checking the documentation is a widespread way of getting documentation done across analytics, and the code review process does the same for programmers. You just need to apply the same principles to other stages of building a product or a service.

We hope this article gave you some perspective and food for thought. Mindsets are not a completely new idea, there are a lot of articles and looks out there talking about team performance and how to put a team together that will constantly produce value. In our case we tried to simplify it, cover with new, fresh and easy to understand cover. Questions we have tried to answer are:

• Why is a very good team on the surface not producing the value that is expected?
• Why are resources put into new people not returning back in value?
• How to get a good performing team from the start?
• How to fix performance issues in existing teams?

And the main purpose of this article is to give you ideas on what to try. Because these problems are not the ones that appear on the surface, it is hard to pick the reason for it among many and many criteria that you have for your teams and employees.

Another goal of this article is to give you something new, valuable and entertaining to read. And if you are reading this sentence, then either we reached our goal or you are one of those people who read the ending of the book first. If you are the second case - then go up and read it from the beginning, it will be worth it:).

Thank you for your attention and may the force be with you all.