5.3 Modeling: What are Possible Solutions?

Once the problem has been identified, we can start doing something about it.
As a first step, we usually need to share our analysis with the client — for example, the team lead or senior management — and make sure they agree with our findings :)

This is often the very first time I show them the teamdecoder. Before this point, it usually just causes confusion. But now I can say:
“Take a look — this is what your team looks like today, and here, here, and here are where we’re seeing the impact of your problem!”

At this stage, you can either already present some potential solutions or first focus on establishing a shared understanding of the problem, and then discuss solutions in the next meeting.
There’s no fixed rule for this — do whatever you feel works best for the client.

Modeling Solutions within the td Framework

If we want to help the team solve its current problems using teamdecoder — and more importantly, enable it to better address future issues independently by learning how to integrate improvement and change into daily work — then we need to structure our solutions in a way that they can be implemented within teamdecoder.

What does that mean?

It means we use the teamdecoder framework for role-based collaboration to address the identified problems. In other words, we propose solutions in the form of:

• People

• Skills

• Roles

• Domains

• Links

• Circles

• Projects

Which lists you use, and how you name them, is entirely up to you. But your solution must be operationalizable within the framework you’ve built for the team.

After all, this is where the team’s entire work structure, collaboration, goals, etc., are defined.

Here’s what that might look like:

• Problem X is solved by introducing a new role.

• To support your new strategy, you need different skills — I recommend Skills A and B.

• To improve collaboration, we create Circle Y, where Roles 1, 2, and 3 work together on X, Y, and Z.

• To keep the CEO better “in the loop,” we establish a new Link.

• etc.

Thinking Bigger

The ideas mentioned so far may sound more like quick “band-aids” for smaller “issues” — but that doesn’t make them any less important. Often, the devil is in the details. And when 99 small things aren’t running smoothly, the entire operation inevitably suffers.

However, depending on how deep the identified issue runs, a more comprehensive solution may be needed — a new strategy, a new structure, a complete reorganization of tasks, etc.

In such scenarios, I recommend developing the solution outside of teamdecoder, for example in Miro, and only translating it into teamdecoder once a fundamental agreement has been reached with all stakeholders.

The draft should clearly illustrate:

• the basic structure that is proposed, and

• how the individual building blocks are connected.

In my process, this often results in visual sketches like the one below (very simplified!):

Here are a few more examples.

Once you’ve aligned on a concept, you can start building the structure in teamdecoder. It’s up to you to decide:

• what should be modeled as Circles,

• what counts as a Project,

• how Skills and Roles are used and assigned,

• and what everything should be named.

In the example above, for instance, you could model the “Strategy Teams” as Circles and the “Skill Teams” as Projects—
or, if you want to reserve the Projects list for actual initiatives, you could create both types in the Circles list and use tagsto differentiate.