The Parts vs. System Paradox

“Changing parts will have little impact on the system. But changing interactions or purpose can create a massive impact.” — Steven Schuster

Systems thinkers have long understood this. So why do many organizations still obsess over optimizing individual teams — driving up local efficiency while system-wide performance stagnates or declines?

Here’s what happens:

• A team gets faster
• But what they produce isn’t aligned with what the customer actually needs
• Or worse, it clashes with what another team is doing
• You get work that’s faster, cheaper… and irrelevant

To improve real outcomes, stop focusing on parts. Start improving how the parts work together. Make collaboration worth it for individuals — not an extra burden, but a source of progress and shared wins.

What is your “Product” Operating Model?

Analogy: Your Restaurant Experience

By way of analogy, imagine you come to a restaurant and willing to spend a lot of money on a bowl of an expensive and exotic soup. You sit at a table and wait for your dish to be delivered. When a waiter comes, you see that on his tray, there are raw ingredients that are used to prepare a soup, but there is no actual soup. You are puzzled. This is not what you are prepared to pay for. Each ingredient, although the required constituent of a final product, is not a product in itself. Even if a waiter, head chef and restaurant owner tried to explain to you that ingredients also cost money, and are [raw] products on their own, you still have a strong reason to be unhappy, as you were willing to pay your money for something that you could consume immediately upon delivery: a delicious, exotic soup. As a customer, if you do not receive what you paid for, you would be unhappy an, probably, ask for your money back, and not come to this restaurant ever again.

AI, of course, can be used to improve the performance of individual single-skilled specialists, and this is what we see as of 2025, but there is a large landscape. Let me share.

AI-Supported Org Design (“AI OD” for short) will be becoming a hugely impactful topic affecting all of us and all the organizations in which we work.

AI OD is the strategic practice of applying AI (agents and other upcoming innovations) to continuously inform, accelerate, and personalize how an organization is structured, how it evolves, and how its people learn.

It’s not about replacing managers or employees (!) —it’s about empowering us to design adaptable, resilient orgs with fewer structural overhauls and more intelligence baked into the day-to-day.

☝️ The core organizing principle: AI Makes Versatile Teams Viable.

☝️ The core operating principle: With Multi-Learning as the Engine.

In the last months, I’ve had many conversations in the LeSS community as well as in the product I work for, about Requirement Areas. From those discussions, I’ve discovered new ways of explaining them. Here, I’d like to share some of these.

What are Requirement Areas?

Requirement Areas is a grouping of items on the product roadmap used to create a view on the Product Backlog. This view helps us structure the teams accordingly.

Then what is the product roadmap? A product roadmap is a high-level view of the Product Backlog. In the LeSS books, Craig and I talk about items in the backlog that can have ancestors. Nowadays, I refer to items that have ancestors as “roadmap items”. Together they form a high-level view of the Product Backlog, which is usually referred to as the Product Roadmap. Requirement Areas is a grouping or categorizing items on the product roadmap that we use for structuring the work.

In this episode, we have the privilege of having Mauro Sacchi, an esteemed leader in digital R&D at Wärtsilä, whose innovative approach and vast experience in transforming traditional industries into agile powerhouses.

I’m excited to share our transformation story at Wärtsilä, where we’ve embraced Large-Scale Scrum (LeSS) principles to break down organizational silos and unlock our teams’ full potential. This journey wasn’t just about implementing a framework – it was about fundamentally changing how we approach product development and team collaboration.

The Challenge: Fragmented Firepower

When I took over leadership of our digital R&D organization three years ago, I encountered two critical challenges:

1. Inability to direct our firepower to the most valuable work - Our organization was fragmented into silos, with over 10 teams each maintaining their own separate backlogs.
2. Human potential diminished by hierarchical structures - Brilliant people with advanced degrees in physics and mathematics were being treated as mere code producers rather than valuable contributors to product decisions.

Let me illustrate this with a real scenario: One team was working on something extremely valuable for a customer who had complained about our development not meeting promises. Meanwhile, other teams couldn’t help because they were bound to their own backlogs and priorities – even though those priorities were objectively less valuable.