Structural Redesign · Product Organizations
Your product organization is designed to produce the dysfunction you keep trying to fix.
Capability transfer, not a report. I work with you, not for you — building the capability, not renting it out.
Scaling problems that survive every reorg. Frameworks that get installed and absorbed. Your best people leaving because the system punishes what they're good at.
The problems you keep fixing aren't execution failures. They're structural outputs — a structure you can diagnose, then redesign.
We study the live system together: where coordination breaks, which structural conditions keep producing the same problems, and what your organization is actually optimized to do. The test: when I leave, your team reads the structure better than when I arrived.
Four symptoms of the same structure.
None of it is an execution failure. Each is a structural output the system was built to produce — and a structure you can diagnose, you can redesign.
The Diagnostic Sprint
A diagnostic sprint tests whether these patterns operate in your organization. We study how work actually flows: where coordination breaks, which structural conditions keep reproducing the same problems, and what the system is optimized to produce regardless of what the strategy says.
You get a written diagnosis, concrete next moves, and the beginning of a shared language your team can use to see the structure without me.
For practitioners building structural thinking skills: 1:1 mentoring and team workshops. Ask about mentoring →
Why me
BeforeR&D organized by specialty. Every feature crossed five team boundaries. Product managers spent more time negotiating between teams than understanding customers.
AfterCoordination layers dissolved because the conditions that required them no longer existed. Teams now own their own hiring, promotions, and escalation.
Case study on less.works ↗BeforeFive million lines — the most business-critical system in the bank — owned component by component, in places by single individuals, each responsible for a fragment of the code. Integration was tested by hand; every release meant coordinating dozens of them.
AfterA team of teams now develops the platform as one product, whole and end to end — with continuous integration as a way of working, not just a pipeline. The bank later adopted the approach company-wide as its Product Design Engineering model, which I co-designed.
Inside product organizations that hit the same structural walls — and the diagnostic practice that came from refusing to treat them as execution problems. Selected for workshops at LeadCraft and the Engineering Leadership Conference.
Each article names a specific mechanism most organizations can feel but haven't named.
Two questions worth thinking about before we talk.
No funnel. The answers tell me whether a sprint is the right first move.