Designing Workshops: Iteration

In an earlier article, I argued the case for parallel work. That is, we don’t need to work sequentially through a problem.

If you felt that article only told half the story – you were right! Parallel work doesn’t (and probably shouldn’t) stand alone. It’s tightly coupled with another idea – iteration.

Iteration defines the rhythm of a workshop. The basic rhythm being:


The entire workshop might look like:


Let's explore what's happening here.

The system evolves

🤓 I’m going to nerd out for a moment and talk about the idea of ‘systems’.

A system is:

A set of things working together as parts of a mechanism or an interconnecting network.


A set of principles or procedures according to which something is done.

I mention this because the topic of any workshop can be considered a ‘system’. A Team Charter is a system that aims to make explicit and govern how a group of people work together. A Strategy is a system that describes how an organisation will engage with its environment and attempt to create a competitive advantage.

Systems are made up of components (which are also systems). These components are the basis of the conversations groups have during workshops. A workshop focused on an organisation’s strategy might have discussions about the organisation’s ‘mission’ and ’values’. A workshop to develop a team charter may include some discussion of the ‘purpose’ of the team or a ‘social contract’.

The components of a system interact and influence both each other and things outside of the system. When the system is integrated, those interactions lead to predictable and desirable outcomes. Our strategy gets our organisation where it needs to go. Our team charter improves how we work together.

Desirable outcomes are often about balance. The type of system that warrants a group coming together to design it is (usually) complicated. In these systems, there are often multiple outcomes that might be achieved.

Achieving one outcome may mean not achieving some other outcome. For example, if we tune our strategy ‘system’ to maximise customer experience we may reduce our ability to provide a return to our shareholders.

By iteratively working on a system in parallel, a group will initially surface these trade-offs. Over successive iterations, the group will work through these trade-offs to find the 'optimal' balance.

Iteration creates empathy

A pattern within some organisational hierarchies is the categorising people into two groups – thinkers and doers.

‘Thinkers’ sit at, or near, the top of the organisational hierarchy. Going back to the model of change I discussed in the previous article the job of the ‘thinker’ is to articulate the why and the what.

Thus, the job of the ‘doer’ is to implement according to the direction set by their organisational superiors. A ‘doer’ is allowed to think about the how.

The challenge of this pattern is the underlying assumption that working on the how is a lower value activity than working on the what, or the why.

Reflecting on what I said above about integration and systems, you might realise that statements and descriptions of how a change could happen will influence what the change is and maybe why we would do it.

This is all a long-winded way of saying that assuming the ‘thinking’ is more valuable than ‘doing’ is folly. All aspects contribute to an integrated, holistic system.

Back in our workshop we now have a group of people. Some of these people are ‘thinkers’, and some are ‘doers’. We might conclude that it’s best to ‘play to our strengths’ and have people work on components closest to their day-to-day roles.

If we do that, we miss an opportunity. We awaken empathy by having people who typically work on the why or the what do some work on how. Those people will have a greater understanding of what it ‘really’ takes to implement their decisions. Similarly, if we ask the people who normally implement those decisions work on the why and the what, they will get a deeper appreciation of the trade-offs required to make those decisions.

Is generating empathy useful though? Within the confines of the workshop, it certainly is. As the group builds empathy for each other over the iterations, an interesting shift happens.

At the start of the workshop, each participant often feels that to solve this problem some other set of participants need to change their ways. As the iterations progress and empathy builds, the entire group notices that the solution to the problem lies in resolving the inherent integration issues and finding balance in the system.

Put simply, the dynamic shifts from ‘participant vs participant’ to ‘group vs problem’. This is a far stronger position for the group to achieve what it needs to.

What about after the workshop? This is where the investment in iterations and building empathy pays off. Leaving a session, you now have a group of people who all believe in the solution, and all understand the entire solution, not just ‘their’ part of it.

As time marches on, and the group tries to implement the decisions they made during the workshop problems will inevitably appear. Solving those problems is far easier when individuals have empathy for each other.

Considerations for iteration

At this point, two questions naturally arise:

  • How long should an iteration be?
  • How many iterations should I have?

How long is an iteration?

Parkinson’s Law states:

Work expands so as to fill the time available for its completion

This law holds for an iteration. If you ask a group to produce a Vision statement in the next 45 minutes, they will probably take 45 minutes for that task.

That said, it still takes some consideration to ‘size’ an iteration. Two forces are pulling you toward longer or shorter durations.

You need to give people enough time to ‘get into’ the topic. They need to push past the surface of a component and discover its hidden depths. This encourages longer iterations.

On the other hand, the longer a group is working on a topic, the more likely their focus will start to wander. They might get tired, distracted, or both. This encourages shorter iterations.

As a simple starting point, try 45 minutes and see how that works with the rest of the design, and how it feels to you. You might look at the work in relation to other conversations and decide it feels too long or short.

Regardless of the duration you choose, when the session is in progress, you will need to pay attention to how the work is going. Observe the teams as they’re working. Are they still debating the topic? Are they talking about their weekends or the latest sports results? Do they look stuck? Does it feel like they’re done? Even though you have a plan for the day, be prepared to modify that when the work requires it.

How many iterations are enough?

This is, in some ways, another example of Parkinson’s Law. The number of iterations will, to a significant extent, be determined by the overall duration of the workshop.


I like to do at least two iterations for a topic. Even if it’s as simple as:


You’ll get a lot further than just doing one. It will help encourage feedback on the work (which is an excellent pattern to set and reinforce).

Of course, you don’t have to stick to the same set of topics for iterations. It can be useful to include an additional iteration that approaches the problem from a different perspective.

For example, you might have a team defining a strategy. Between two iterations of the strategy, you could include an iteration of the Functional implications from the first iteration. Like this:


With this kind of approach, the middle iteration functions as both a test of the work and a method to develop further insight into how you will make all these components fit together.

Closing thoughts

Iteration and parallel work are two of my go-to tools when designing a workshop. In addition to creating better outcomes, they also produce better energy for a group and generate better engagement from a group.

Even in a situation where a sequence is required (i.e. a group needs to have conversation x before having other conversations) I will treat the first conversation as an iteration and work in parallel.

It looks like this:


In the first round of work, each team works on the same topic (and in this example, we produce three answers to the same question). In the second round, one team progresses that topic into its next iteration. One tip for that structure is to make sure that in the second round the team working on the first round topic has representation from each team in the previous round.


As I noted in the previous article, these are tools and designing a workshop is a craft. There are many ways you can design a workshop to accomplish the same thing. By experimenting with these tools, you will hone your craft and design better workshops.

Designing Workshops: Sharing Work

Designing Workshops: Working in parallel