From understanding to action.

Getting to know each other in an intake conversation is always an important starting point for us. We take the time to get to know you and your organisation, and to understand properly what is going on, and where. We listen, ask follow-up questions and note what strikes us.

How do we do that? We sit down with the client and the people facing the challenge, at your offices or online. We want to hear what you want to achieve and what is getting in the way, and we keep asking until we understand.

Afterwards we share a report: what we discussed, what struck us and a proposal for a first step.

Where the issue calls for it, an organisational diagnosis or a development study follows. Then we look wider and deeper: with interviews and observations, with our own scans, and with the organisational model as a lens on the goals, the structure, the culture, the technology and the leadership.

We want the whole organisation at the table. Talk to three managers and you hear one perspective. The real insight lies in everyone’s view of what works and what doesn’t.

We talk to people in different parts of the organisation, watch the work and the meetings first-hand, and analyse what we see in interactive sessions with the people themselves. Our own tools quickly gather different perspectives, reveal connections and show where things rub.

In practiceFor a telecoms and infrastructure company we mapped the main IT processes, including waiting times, waste and current lead times. Combined with a map of the technology landscape, this made clear which additional technology we could use when redesigning the processes.

We draw the process together with the people who do the work, step by step, as it really runs today. For each step we note how much time the work takes, how long it then sits waiting and what goes wrong.

We often start with what the systems already know. We export the existing processes from, say, an HR system and analyse them, with the help of AI: how much is manual work and where could you automate, how often does something go wrong, and how much rework does the process involve?

Then we mark the waste: double entry, waiting, rework and handovers. And we count: how often does this happen each year, and what does it cost?

Which systems are there, who uses them for what, and where do they overlap or leave gaps? A clear overview as the basis for technology choices.

We start with the people who work with the systems: employees, managers and the teams that manage the systems. For each system we record what it is for, who has access to it, who owns it and what data it exchanges with other systems.

We bring this together in one picture of the whole landscape, with a short explanation per domain and an overview of who manages and owns what. That shows where data is entered twice, where a link is missing and where work is still done by hand.

For HR we mapped more than twenty systems this way, from rosters and absence to budgets and dashboards.

The reasons vary. Teams are being merged. People have to work together in a chain with a supplier, customers or other external parties. Or departments and parts of the organisation work together in an internal chain, and the shared picture of that collaboration has yet to be designed.

We start with interviews and an analysis of what has already been written down about governance. In practice our Governance app is the starting point: it speeds up the research and makes the picture a shared one.

Together we choose the topics that matter. For each topic everyone answers seven questions: who owns it until it is completed, who advises, who has the mandate to decide, who must be consulted beforehand, who records it, who communicates the decision and to whom, and when do you escalate? Colleagues and managers cannot see each other’s answers.

Once the survey closes, you see for each topic where views agree and where they differ, in numbers per team. "Don’t know" counts too: if nobody knows who is responsible for something, that is a finding in itself.

The digital scan is in development.

Employees and managers fill in a short questionnaire on the four domains of the model: shared vision, systems thinking, team learning and collaboration, and craftsmanship. For each domain we look at how structure, culture and technology help or get in the way.

The result shows for each team where things are strong and where they rub, and where management and teams see things differently. We discuss those differences in a feedback session with the client and, where it makes sense, with the teams themselves.

That is what we base our advice on: where to start, and what is better left for now.

Besides Leapshift we use the Governance app and ESCI 360. You can read more about them on our tools page.

Obeya is Japanese for big room. Toyota used such a room to make everything that mattered visible in one place. We start with the question of what you want to steer on: which goals have been set for this year, which projects should contribute to them, and which figures show you whether it is working? That determines how the walls are laid out.

Then we set up the room, usually in four parts: the direction and the goals, the progress of projects and improvement actions, the figures that matter every week, and a board with bottlenecks and actions. For each wall we agree who keeps it up to date.

Then the rhythm. Every week at the same time, a short stand-up meeting at the wall. You walk past the walls, discuss only what is red and agree who picks up each bottleneck. Anyone working remotely joins on screen.

In the first weeks we take part and fine-tune. What nobody uses comes off; what is missing goes up. After that the team runs the Obeya itself.

We discuss the results with the people involved, in a session we facilitate. Where views differ, we agree roles, mandates and responsibilities, and write them down.

We write down roles and mandates in plain language, so that a new colleague understands them too.

After three or six months we send out the same questions again. That way we check whether the agreements still work as written, and adjust them where needed.

Once the process is mapped and the waste is visible, we design together with the people who do the work how it can be done better and more simply.

This also produces the business case for improvement: what the waste costs now, and what the new process saves.

Below you can see what that looks like in a value stream map: the process as it runs now, with the minutes of actual work per step and how long the work then sits waiting, and the process as it could be. Switch between the two to see the difference.

We start with the meetings as they are now, within a department or in a chain between teams, departments and organisations. Which meetings are there at strategic, tactical and operational level, and how often do they meet? What is the purpose of each meeting: informing, deciding, solving problems or something else? And who attends, who chairs, is there an agenda and is it followed?

That gives a picture of where information gets stuck, where meetings duplicate each other and where decisions are never made.

A meeting only works if the people who have to make the decisions there also have the mandate to do so. That is why we design the meeting structure on the basis of the agreements on roles and mandates.

Then we design together a meeting structure that suits your organisation: which meeting there is for which purpose, who attends, how often, and how information gets from one level to the next.

Sometimes the question is strategic. At a school board, the meeting with the head teachers only discussed the schools where things were going badly. We set it up differently: over the year every school is discussed, grouped into green, amber and red, and each time a school that is doing well is on the agenda too. That way the board gets a picture of the whole organisation, and the schools quietly struggling on alone come into view as well.

When many projects are running, it is often unclear how they relate to each other, who leads them and what they aim to achieve. Portfolio management helps to keep an overview across all projects, and sometimes to say goodbye to projects that do not contribute to the goals. It is also important to understand better which departments or people spend how much time on what. After all, you can only spend each hour once. A clear view of your capacity, and of what is asked of it, helps with that.

Often there is a long list of projects, wishes and changes, and decisions about the same people are made in several places. Whoever shouts loudest gets priority, and more is promised than delivered.

We start with an inventory per team in one Excel sheet: what is already known is in it, and the team adds what we don’t know, such as the status, the size and when it runs. Anything duplicated or lapsed comes off.

Then we sort: what is mandatory because of legislation or compliance, what the organisation asks for and which innovations are possible. You cannot choose to drop mandatory work, only schedule it. You decide on the rest together: what now, what later and what not at all.

Together with capacity management, we make visible what teams can handle. That produces a roadmap for the coming quarters or the coming year that fits the available capacity. Process first, then a tool: a good overview is often enough to start with.

A grip on the work you have to do, in service of where you want to go. You see per quarter whether the work you want to do fits the time your team has.

Capacity management is about getting a grip on the work: do you know what is coming the team’s way, and does it contribute to the goals and the direction? You only know what is being asked once portfolio management is in place. That is where all the work sits on one list, with the size of each initiative and the quarter or term in which it runs.

We also calculate what is available: per employee the time that is really left for that work, after operations, regular meetings and a realistic factor for leave and sickness.

Linking the two shows you per quarter, and where needed per week, whether the work fits. Often there is enough time in total, but not at the right moment. Then you make a deliberate choice: move a start date, bring in temporary help or drop something that contributes less to the direction.

We only start once the process has been redesigned and the waste has been removed. Otherwise you automate the detours as well.

Then we look at each step to see what the system can take over. A form that can only be sent once it is complete, a link so that nobody retypes anything any more, automation in the system that puts an approval in front of the right person. And where it fits, an AI agent that does the groundwork: reading a request, asking for missing data, preparing a proposal.

We prefer to build with what you already have, such as the automation in your own systems. A person always makes the decision, and we agree which data an AI agent may and may not use.

You don’t change a culture with a presentation. We work with management and teams on the behaviour that fits the goals, and start with how things really go here: which unwritten rules apply, and what do people only say after the meeting?

Then we translate the values into behaviour you can see, with agreements that teams make themselves. Managers have a role of their own in this: they set the example, and we support them in doing so.

At the same time we look at how meetings and decisions are organised. New behaviour doesn’t last in a structure that rewards the old.

Sharpening the direction together and turning it into goals that teams recognise in their own work.

We sharpen the direction with the people who have to make it happen. What do we want to achieve, and why? We work appreciatively and start with moments when the organisation was at its best.

Then we translate the direction into goals per team and into behaviour. What does this mean for how we meet and decide? Which behaviour do we want to see more often, and what do we no longer accept as normal?

The result is a direction that teams recognise in their own work, with agreements you can hold each other to.

We support the team in the work itself: in the meeting, on a team day or at a difficult moment. That way the team practises the conversation it would otherwise avoid, right where it is needed.

On a team day we handle the set-up and lead the conversation, and we slow things down where it gets tense. That way everyone can take part instead of organising, including the manager.

Between sessions the team comes back to the agreements it made. Our work is done when the team does that without us.

In a workshop we make visible which rules apply without anyone having written them down. Who takes the floor, what happens with a mistake, what is only said after the meeting? We first look at what is there, before we try to solve anything.

Then we set those rules against the vision and values of the organisation. Where they clash, the team agrees what it will do from now on. For one team that became: if something bothers you, you go to the other person and not to the manager.

The agreements get a fixed slot in the team meeting, so the team keeps them up to date itself.

We first map who is involved in the challenge and what they consider important, including the parties who have not been at the table so far.

In the workshop we put the different views side by side. Any dissatisfaction gets room first; only then do we turn to the content. We work appreciatively: we start with what already works and where those involved want to go together.

The result is a shared picture of the challenge, with agreements on who has a say in what and who decides.

A change succeeds when people come along with it. We involve the people it affects and work with colleagues who champion the change in their own team.

We first look at who the change affects and what it means for them. Then we look in the organisation for people who want to help: colleagues who explain the change, gather questions and show how it can work in their team.

With them and with management we organise moments when people can think along and voice their concerns. We take what comes up into account in how the change is introduced.

Sometimes a training course, a workshop or a development programme is exactly what is needed. We design it for your question, with your own situations as practice material, and run it ourselves.

A training course like this never stands alone. It builds on what we have investigated and agreed together beforehand, and afterwards we look at what it changes in the work.