Ways of Working Design
Ways of working design gives you a future-state value stream design: a clear picture of how work will flow from request to delivery, with the queues removed, the handoffs redrawn, the decisions assigned and the cadence set - backed by a map of how the work flows today and a plan to get from one to the other. We design it with the people who run the work, so the result is genuinely theirs.
Our ways of working design gives you a future-state value stream design your teams can run on, and we design six parts: the value streams mapped from how work flows today to how it will flow, the queues and wait time engineered out, the handoffs redrawn with clear interfaces, the decision rights set on the calls that matter, the operating cadence that keeps work moving, and the flow metrics that tell you it is working. You walk away with a design that fits how your work really travels and is ready to put into practice.
A way of working holds when the people who run it helped design it. So we design with your people, drawing on the knowledge already inside the teams and combining it with our outside frameworks and pattern-recognition. The design comes out both accurate and owned, and your people come away able to redesign the next process themselves.
Decision effectiveness correlates with company financial performance at a 95%+ confidence level across every country, industry and company size studied, and top-quintile decision-makers deliver total shareholder returns about 6 percentage points higher than the rest. Setting clear decision rights into the flow is one of the levers that moves this (Marcia Blenko, Michael Mankins & Paul Rogers, 'Decide & Deliver', Harvard Business Review Press, 2010).
When ways of working design helps
Ways of working design is the step you take once you know the flow of work needs to change - often straight after a diagnostic has shown where it stalls. These are the situations we are most often asked into. If one sounds like yours, this is a good place to start.
The situation | How it helps |
|---|---|
Work takes far longer to get out than the actual effort in it | Maps where work sits waiting between steps and designs those queues out, so lead time drops without asking anyone to work faster |
Things get dropped or duplicated in the gaps between teams | Redraws each handoff with a clear interface, so work passes cleanly and every team owns a workable slice |
Work keeps stalling while it waits for someone to approve it | Sets decision rights on the real decisions and a clear route for escalation, so approvals stop being the bottleneck |
Everyone is busy but the work still moves slowly | Finds the invisible wait time between steps rather than the busy steps, and designs the flow so the work moves, not the people harder |
A diagnostic has shown where the friction is and you need the redesign | Turns a clear read of the current state into a worked-out future-state flow, so you move from knowing the problem to running the answer |
You want a way of working your teams will actually keep | Builds it with the people who run the work, so it lands as theirs and holds after we leave |
What we design
We design six parts of how the work flows, and make each one concrete enough to run on:
- Value streams, mapped current-state to future-state - We map how a piece of work travels from request to delivery today, mark where it stalls, waits or loops, then draw the future-state flow you will actually run.
- Queues and wait time - We find where work sits waiting between steps - the invisible queues that eat most of the elapsed time - and design them out, so lead time drops without asking anyone to work faster.
- Handoffs and team interfaces - The joins between teams where work gets dropped, duplicated or queued, redrawn with a clear interface so it passes cleanly and each team owns a workable slice.
- Decision rights and escalation - Who recommends, who decides and who is simply informed at each step, so work stops waiting on approvals that add no value and stalled calls have a clear route up.
- Operating cadence - The rhythm of planning, prioritisation and review that keeps work moving instead of piling up, set to the real pace of incoming demand.
- Flow metrics and WIP - The measures that tell you it is working - lead time, cycle time, work-in-progress and flow efficiency - and the WIP limits that stop the system overloading itself.
Why these six
These six are the parts that have to line up for a way of working to flow as one whole. A cleaner map with the same hidden queues still stalls where it did before; queues removed but decisions left ambiguous simply move the waiting to the approval step. The parts that get skipped most - the wait time between steps, the decision rights on the real calls, and the flow metrics that show the new flow is holding - are the ones that decide whether the redesign runs in practice or stays a diagram. So we design them together, as a set.
The six follow the established flow frameworks - value stream mapping, queue theory, team interfaces and decision rights - so the design covers what a real way of working needs: how work moves, where it waits, who decides, and how you can tell it is working. We use them to keep the design complete and honest, not as a model to run at you.
How it works
The method produces one thing: a future-state value stream design your teams can run on. It works by designing the flow with your people rather than presenting one to them. Your teams already hold most of the knowledge about how work really travels and why the workarounds exist, so our job is to draw that out, combine it with the outside frameworks and pattern-recognition you bring us in for, and shape the two into a design that is both expert and genuinely owned. It works in four modes.
- We start by seeing and measuring the current state - Before we design the future flow, we map how the work travels today and make the wait time visible, and we capture a baseline of the flow metrics - lead time, cycle time, flow efficiency. Seeing where the work actually waits is what turns the redesign from opinion into evidence, and gives you a before to measure the after against.
- We design with the people who run the work - The people doing the work know where the flow bends and breaks, and why every workaround exists, in ways no process map shows. We build with them, turning that knowledge into design choices - so the future-state flow fits how the work really goes, and is owned by the people who will run it.
- We bring the outside frameworks and the discipline to challenge - An inside view alone tends to design around today's habits and sacred-cow steps, so we bring the outside pattern library - value stream mapping, flow metrics, decision-rights and team-interface frameworks - and the discipline to question steps everyone assumes are fixed, then check the design holds before you commit.
- We leave the capability behind - Throughout, we work so your people learn to redesign flow, not just watch us do it. By the end you have a future-state design and a sharper sense of how the choices were made, so the next process is one you can redraw yourselves.
The thinking behind the method
We design with your people rather than deliver to them because of a hard fact about redesigns: the flow that gets adopted beats the flow that looks best on paper. A way of working is a set of new habits that hundreds of daily choices follow, and people follow a flow they helped design - they understand why it is shaped the way it is, and they trust that it fits how the work really moves.
So co-design gives you a flow that is both right and real. The knowledge inside the teams makes it accurate; designing it together makes it owned; and the outside frameworks keep the two from simply reinforcing the workarounds that were already there. Get all three and the flow holds in practice. Miss one and you get an expert design that gets ignored, an owned design that never questions itself, or a clever design that no one runs.
What you get
By the end, you have four things:
- The future-state value stream design itself - a future-state map of how work will flow from request to delivery, with queues removed, handoffs redrawn, decision rights set and cadence fixed, backed by the current-state map, the wait-time analysis and a baseline of flow metrics.
- An implementation plan - the sequenced set of changes from how work flows today to the flow you have designed, with the phasing and dependencies set out, plus WIP limits and a small metrics set so you can tell the new flow is holding.
- A design that is genuinely yours - built with your people, grounded in how the work actually travels, so it is owned and run rather than filed.
- The capability left behind - your people come out more able to redesign flow, so the next process is one you can redraw yourselves.
The best way of working is both expert and owned, and those pull against each other: expertise wants to hand you the answer, ownership wants you to reach it yourselves. Holding both at once is the craft of the work.
How we hand it over - and what happens next
The point of the work is a future-state flow your teams can run on, so we take care with how it lands. Because your people helped design it, the handover confirms something they already understand rather than revealing it cold. We walk through the finished future-state design and the implementation plan - why it is shaped the way it is, what it settles, what it deliberately leaves open, and what the first moves are.
From there, some teams take the design and put it into practice themselves, now more able to. Others bring us alongside for the harder parts of making the new flow real, which is where implementation picks up. The design has done its job when you can see the new flow clearly, believe in it because you built it, and know the first steps to get there.
Where this sits
Ways of working design is the second step in how we approach operational effectiveness. It follows the Operational Effectiveness Assessment, which reads how work flows today and where it stalls, and leads into implementation, which turns the future-state design into how the work runs day to day. It also stands on its own - if you already know where the flow breaks and want the future-state design worked out properly and owned, this is where to start.
Common questions
Is this just a set of workshops?
No - what you get is a designed future-state value stream, with an implementation plan to reach it. We work with your people in the room, because that is how the design becomes both accurate and owned, and the sessions are the means to that. You walk away with the worked-out flow itself: current-state map, future-state map, wait-time analysis, decision-rights grid, cadence and a flow-metric baseline, shaped by the people who will run it.
What exactly is a future-state value stream design?
It is a picture of how work will flow from request to delivery in future, with the queues removed, the handoffs redrawn with clear interfaces, the decision rights set and the cadence fixed. It comes backed by a map of how the work flows today, the wait time made visible, a baseline of flow metrics, and an implementation plan to get from one to the other. Designing the flow, the decisions and the cadence together, rather than one at a time, is what keeps them from pulling against each other.
How is this different from the Operational Effectiveness Assessment?
The assessment reads how work flows now - where it stalls, waits or loops, and why. Ways of working design is the next step: it produces the future-state flow to run instead. The assessment answers 'where the friction is'; this answers 'what to build'. Many clients do the assessment first, because designing on a clear read of the current state sets the redesign up well, but if you already have that clarity, you can start here.
Does this cover the systems and tooling the new flow needs?
At the level the flow needs. Where the redesign touches a workflow tool, a ticketing system or integration between teams' systems, we design the requirements and the interfaces - what the flow needs of your systems - and hand the build to your technology and delivery leads. We design how the work flows, not the software architecture, so where deep technical build is needed we specify what it must do and your specialists own how it is built.
Why build it with our people rather than design it for us?
Because a flow only works if it is run. The way of working that gets adopted beats the one that only looks best on paper, and people run what they helped design far more readily than what is handed to them. Your people also hold the knowledge of why every workaround exists that no outside team can fully see. Co-design combines that inside knowledge with our outside frameworks, so the flow is both right and real - and they leave able to redesign the next process without us.
What happens after the design is done?
You have a future-state design and an implementation plan, ready to put into practice, with WIP limits and a small metrics set so you can tell the new flow is holding. Some teams implement it themselves, now more able to. Others bring us alongside for the harder work of making the flow real, which is what implementation covers. And because we leave the capability behind, you can keep tuning the flow yourselves as demand changes.
Ready to design how your work flows?
Tell us where the work stalls and what you are trying to achieve, and we will talk through what a ways of working design would look like for you - and whether an assessment first would set it up well. If you already know where the flow breaks, we can go straight to designing the future state, built with your people so it is genuinely yours.