Thinking More Organisationally About Process

Around the time I was writing my first book, Kanban from the Inside (2014), much of my day job involved Kanban training – mostly private training, and from time to time, training other trainers. Leaning on my past career in management (previous roles included Executive Director and CTO), I would encourage those taking my class to “think organisationally”. I would get a lot of blank looks; I had a strong gut feeling about something important, but somehow lacked the words (or as it would turn out, the models) to explain it.

Now that my fifth book, Wholehearted: Engaging with Complexity in the Deliberately Adaptive Organisation (2025) is out, I can say with confidence what “thinking organisationally” really means. In a nutshell, it’s about engaging with the relationships between different aspects of the organisation and caring about how well they are working. That’s a big topic – the number of relationships you might engage with there can be huge – but in this post, I will explain how you can apply some of that thinking to things familiar to most readers of this blog, your kanban board and the process that it represents.

Those vertical lines

The trick (if I can call it that) is to think differently about each of your board’s vertical lines. Most of the time, you likely think of them as representing transitions between activities or changes of status for the work items that cross them. Instead, try thinking of each line as a relationship – a mutual relationship between everything that happens to its left (all the way upstream to the beginning of the process), and everything that happens to its right (all the way downstream to the work’s customer or end user).

You might ask if that relationship is working as well as it should, to the maximum benefit of both sides. Is it in a healthy and productive balance? Where it isn’t, what stops that? What gets in the way? That works well as a general approach, but we can be more specific here. What are we doing on one side of this relationship that might better be done on the other, or in collaboration, or deferred until needed?

Again, for emphasis:

What are we doing on one side of this relationship that might be better done on the other, or in collaboration, or deferred until needed?

That one question covers a lot of potential problems:

• Process steps done too early, too late, or by the wrong people
• Work done to an inappropriate level of detail – over-specifying or under-specifying work, for example
• Work done in isolation that would better be done collaboratively – over-investing in documentation when a conversation might suffice, for example, or vice versa
• Work done not “just in time” but “just in case”, or conversely, issues allowed to fester that ought to be dealt with sooner

Try it for yourself! Pick a vertical line at random, pick one that feels somehow problematic, or pick one immediately to the left of a problematic column. Try it with your team! If you can identify and address just one problem a week or per sprint this way, you might be surprised at how much progress you can make over time.

Coordinate, cooperate, collaborate

There’s a second question you can ask about those vertical lines. Across them, and by default, do we:

1. Coordinate, letting the board, our regular meetings, and other mechanisms of routine coordination keep our work in sync,
2. Cooperate, for each piece of work, agreeing how it breaks down, who does what, how, and when to synchronise and integrate, and so on, or
3. Collaborate – work together in a closer, more creative relationship that is open to possibilities not necessarily considered at the beginning of the process?

Taken together with my first question, the goal is to optimise the team’s limited capacity for collaboration. That means letting the team’s coordination systems manage what they can for little cost and effort, focusing on collaboration where it has the most impact, and cooperating in less intensive ways for the rest.

That’s great until someone recognises that the team missed an issue that would have been picked up in a more collaborative or cooperative relationship, or (conversely) that all that extra collaborative or cooperative effort was for little benefit. Now what?

It’s important to recognise that in a process dealing with a wide variety of work, defaults such as these (or any policy) won’t cover every eventuality. Some work will need more collaboration, some less. Most work should proceed as your coordination systems expect, but some won’t. 

Now the challenge is to tell which is which on a case-by-case basis. If in doubt, ask! Each time the team considers a new piece of work, think also of those vertical lines. For this piece of work, for each key relationship, and with each party represented appropriately in the conversation, does this work call for coordination, cooperation, or collaboration?

The beauty of this question (credit for which I give to my friend Philippe Guenet) is that the process of answering it helps to build some shared sense of what’s involved. It is a great example of a sense-making conversation.

You can also ask it retrospectively. After the work is done, did we coordinate, cooperate, or collaborate appropriately? Were our defaults the right ones? How good were we at recognising when to depart from those? And when we had those conversations, who was in the room? Did we have the context we needed? If we didn’t, what did we do about that? On all of these issues, what do we still need to do?

Preempting failures for better decision making

To finish, that takes me to how a simple idea from Kanban from the Inside has developed over the years into something more organizational. There, I suggested that many “failures of flow” (i.e., where work failed to flow as smoothly as it might have done) might be understood to be “failures of collaboration” – one person’s work suffering for want of sufficient and timely attention from another. In Wholehearted, these have expanded to include “failures of context” – bad decisions made for want of context available from other people, inside or outside the team. Operational decisions made contrary to strategic direction, strategic decisions made in ignorance of operational realities, work failing to delight the customer for lack of customer context, and so on.

For you, the challenge may be to avoid failures such as these persisting for long enough that they begin to look like failures of leadership, however unfair that may seem. An important first step is to recognise that some of them can be addressed only outside the formal process. The next step is to identify the conversations, collaborations, or relationships inside or outside the team that might help to preempt the kinds of failures of context that you have been experiencing. 

You can’t always have everyone in the room you would wish for; neither is the solution to front-load all the work, specifying prematurely what ought to be allowed to emerge in its own good time. Much better to work on the quality of decision-making, making it more repeatable where that is possible, and where it is not, still ensuring that the right people have the right conversations at the right time. The more that this concern for context is shared, the more automatic this will become, and the stronger your organization will be for it.

Wholehearted: Engaging with Complexity in the Deliberately Adaptive Organisation hit Amazon in April. You can find both print and Kindle editions on amazon.co.uk, amazon.com, amazon.de and other Amazon sites worldwide. The e-book is also available on LeanPub, Kobo, Apple Books, and Google Play Books.