Working together
Most enquiries do not start with a method. They start with a situation. Something takes too long, costs too much, or never reaches the customer. Usually it is clear that something is not working, but not why.
So the first step is not a recommendation. It is a diagnosis. Only once it is clear what actually limits effectiveness can anyone say what to work on.
This may be where you are
The strategy does not reach the daily work. Goals, initiatives and programs do not add up to a picture that decisions can be aligned to.
Silos and dependencies slow everything down. Coordination and handovers cost more than the work itself. Changes are slow or expensive.
Product development reaches real customer feedback too late. Months pass between an idea and a response.
Growth or contraction calls for new structures. Areas of responsibility no longer match what the company has become.
Leadership and career paths need rethinking. Professional growth should carry the same weight as a move into management.
AI is changing roles, skills and collaboration. Individuals work with it, the organization learns nothing from it.
Budget pressure calls for short-term relief , without damaging the ability to learn and deliver.
Dependence on outside consultants should decrease. Internal capability for change, leadership and coaching should grow.
What this is about
Strategy and direction
A strategy only becomes a strategy when it guides decisions I am not there to make. I work with Rumelt’s strategy kernel, but not only as an analytical tool. The guiding policy becomes an explicit decision criterion that people can apply wherever they sit. Principles belong in it, best practices do not. Company, product and transformation strategy need not be identical, but they do have to fit together.
In practice: at a software company I developed vision and strategy in two workshops eight months apart, from the company vision through diagnosis, guiding policy and coherent actions to product vision and roadmap. In other engagements I have applied the same structure at product level for individual divisions.
At the moment I am helping a company build and run its own strategy kernel. The aim is to make the organization independent of outside consulting in the long run. More immediately, it is about deciding together, faster and more coherently, without every question having to travel up and down the hierarchy.
This work is hardest when a company is under economic pressure, because at first it does not feed directly into value creation. Working iteratively changes that sooner than expected. Shared decisions get better before the strategy is finished.
Organization and leadership
Structures determine what information reaches people, who they work with, and how directly they experience the effect of their work. I cut organizations along customer value rather than along the technology, and I decouple structure from architecture so that both stay movable. That includes a deliberate separation of product responsibility and line leadership, with development paths of equal standing and equal career prospects. And the question of who actually decides what: context determines who decides, the range of knowledge involved determines who should contribute.
In practice: this separation convinced me before I ever designed it. At Nokia Siemens Networks I knew who my manager was, of course. But I did not know who else on my team had the same one, because the question had no bearing on the work. Professional leadership ran through the product owner, the work ran through the team. That was possible because the managers worked as a team themselves and spoke with one voice. As a result, what any one of them said carried the same weight.
Later I carried the separation myself. At Valtech I held line management responsibility for three to four people and professional responsibility for more than 25. Doing both at once was only possible because they were separate. In LeSS adoptions in retail, medical software and tax software I have designed it together with the people involved.
Where it most often fails is where the product owner holds professional leadership formally but not actually. Business units or line managers keep questioning priorities, hold on to milestones, or demand fixed budgets up front. The product owner loses effectiveness without being able to hand back the responsibility. I have watched people in that role burn out and resign more than once.
At the heart of it is a position that appears on no org chart: serving waterfall upwards while enabling agility downwards. Whoever sits there needs competence in both worlds. Most people bring only one, and that is not a personal shortcoming but a structural overload. My backlog visualization grew out of exactly that predicament. It translates between the two worlds by producing forecasts one side can plan with, without the other side having to abandon how it works.
Backlog visualizationProduct development and professional excellence
Discovery and delivery are one system, and the technical conditions determine whether it works. One focus of my work is cutting a small end-to-end case out of a complex domain problem, paired with concrete examples as acceptance criteria. For that to hold, you need continuous integration, automated tests and incremental design. I treat continuous integration as a working principle rather than a toolchain: you can work in technically excellent ways on isolated branches and still prevent the product from being integrated.
This includes feeding the product backlog back into the roadmap and on into the strategy, so that planning aligns with what is actually being delivered. For forecasts I use waterlines, statistical ranges and trends. Estimates are welcome, but at item level and at the point where the team understands the work. In very large organizations I usually work without them, because teams estimate differently. It makes little difference to the forecast, because flow and remaining backlog size are measured in the same unit.
In practice: in the Aftersales Service & Repair division at BMW, the task was to develop a generic aftersales part linking repair instructions to the parts required for a specific vehicle. Three products, twelve teams, a deadline brought forward by six months. Instead of optimizing the teams individually, development was aligned along the value stream.
87.9%
The division cut that way reached 87.90% flow efficiency. The domain average was 69.63%, and products with many dependencies came in at 63.93%. Flow efficiency measures how much time is spent working and how much waiting. 100% would mean no waiting at all. What makes the number remarkable is that by size and dependencies this division should have been at the lower end.
Together with Frank Preiß I presented the approach at the LeSS Conference 2023 in Berlin and in November 2024 at the Münchner Projektmanagement Tage.
Talk and slidesThe more important benefit of the visualization is not the forecast. Once people can see flow, they can see what creates it, and they cut requirements differently, more end to end. The forecast does not just get better. The organization changes and becomes more predictable.
This approach cannot really fail, because all it does is make things visible. The question is what an organization does with that visibility. Anyone who sees the flow and changes nothing has better reporting and nothing else. The benefit only appears when what is seen leads to different decisions.
AI in the organization and in product development
Artificial intelligence cuts across all the other areas, from strategy through collaboration to implementation. The most common mistake is not a technical one: when a single person judges an AI result, the collective intelligence of the organization goes unused. I work with AI agents across connected tasks, so I can say from my own practice what actually shifts in roles, quality assurance and responsibility.
That work has produced a collaboration guide with more than twenty concrete practices. I summarized the experience in a talk at a car manufacturer. I work on the organizational consequences of an AI transformation as a cross-cutting theme: which capabilities are needed, how roles and areas of responsibility change, and which feedback and quality systems hold up when far more is produced far faster.
In what role
- Strategic advisor and sparring partner for executive teams and management
- Advisor for organizational design and transformation
- Management and leadership coach
- Advisor for professional and line leadership models
- Product and large-scale development coach
- LeSS trainer and LeSS coach
- Coach for product ownership, roadmaps and product backlog
- Advisor for technical excellence, continuous integration and delivery capability
- Sparring partner for collaborative and agentic use of AI
- Facilitator for teams, management groups and large-group formats
- Coach and mentor for internal coaches and leaders
The scale ranges from single workshops through ongoing engagements to longer collaboration. When a task grows beyond what one person can carry, I work with partners.
My networkTraining and workshops
I currently run certified LeSS training and workshops on systems thinking, product ownership and strategic agility as in-house formats. Open dates are announced here.
To the training pagesThe first step
Write and tell me what is going on. A first conversation costs nothing and commits you to nothing.
Get in touch