Organisational development and team designDecisions get stuck between teams.

Your strategy is brilliant. Is your organisation, too?

We cut teams along the path the work takes and make clear who decides what.

Book an intro call

Free, 30 to 60 minutes: first ideas and an honest assessment of whether we can help.

From start-up to mid-sized company: an operating model that still works well there today (SaaS). Read the full case

How it works

From the first call until it runs

1
First call
free, 30 to 60 minutes
You tell us where things are stuck. You get first ideas you can try right away, and an honest assessment of whether we can help you. If we can't, we tell you.
2
Measure
We measure where the work gets stuck and lay the org chart, the process map and the system landscape on top of each other. That is where we look for the cause.
3
Change it together
We change what holds the work up, in the organisation, the workflow or IT. We only leave once it runs without us.

Our approach

Who gets to decide

Your org chart decides which software you can build. Every boundary you draw in the org chart later becomes a handover, a waiting time and an interface in the code. That makes organisational design the first architecture decision you take. Usually without noticing. Whether the bottleneck really sits in the organisation, we only decide once we have laid it next to the workflows and systems. And a new structure only holds if the systems built for the old one move along with it.

Your teams are cut along the path the work takes. Every crossing between two teams costs time and quality.
Everyone knows who decides and who is responsible for what. That way ownership survives the first handover.
Each team is responsible for only as much as it truly understands. This is called cognitive load.
Your decisions become measurable, with a few metrics that actually steer something.
Decisions are made where the knowledge sits.

References

Boundaries, not boxes

Ownership!

All references

A reorganisation that only relabels boxes changes nothing about the waiting time. What matters is where the boundaries run: how many teams does a user journey have to cross? Who is allowed to decide without asking?

From start-up to mid-sized company

SaaS

The bottleneck: first the organisation, then their own SaaS systems.

The cause: four companies with four structures and technology built twice, which did not come together after the merger. (organisation and IT)

Our solution: First we cut the organisation anew along the shared customer value stream, then merged the systems along those cuts.

Key result

An operating model that fits the client, their market and their people, and still works well there today.

Organisation Process IT

Read the full case

From grown systems to microservices

Broadcasting

The bottleneck: the path from the editorial team into IT development. Every new digital offering waited for changes to the grown system.

The cause: separate silos for editorial and IT development. The system landscape had grown the same way: one big block that everyone depended on. (organisation and IT)

Our solution: We brought the editorial team and IT into shared workflows and cut the system into microservices along those workflows.

Key result

A working prototype within a few days, followed by a handover to the team with extensive training.

Organisation Process IT

Read the full case

Architecture between many parties

Aviation

The bottleneck: architecture decisions. They got stuck between many parties with interests of their own.

The cause: a governance in which every interface had several owners. The systems were as tightly coupled as the coordination between the parties. (organisation and IT)

Our solution: We cut architecture and workflows anew together, so that systems and decisions depend less on each other.

Key result

Critical dependencies between the systems decoupled.

Organisation Process IT

Read the full case

Let's look together at where your work gets stuck.

Book an intro call

Result

Why it holds up

We align the structure with how value is created: clear responsibilities, few handovers, decisions where the knowledge sits. A structure is good when it shows where the bottleneck currently sits.

Tools

Our toolkit

These are the tools we use most in organisational development and team design. Which one we use is decided by the bottleneck.

Target operating model: Describes how the teams are cut and who decides what.
Role profiles and responsibilities: Clarify who is in charge, so that nothing gets stuck between two teams.
OKR: Aligns teams and management on shared goals that can be measured.
Flight Levels: Connects the teams’ work with the steering above it.
LeSS and SAFe: When many teams work on one product, we use the parts that fit.
Lateral leadership: For leading across team boundaries, without formal authority.

Industries

No industry focus

What a team can carry depends on your reality. Where every approval has to be documented, autonomy looks different than in a product team that ships weekly. That is why the cut comes before the method.

These are the industries we have worked in. Where there are references, a click takes you there.