Most organizations get it wrong when it comes to improving the flow of value through an organization. They observe something that correlates with high-performing organizations and then try to copy it — assuming it is the cause of success.

This confusion between correlation and causation is not unique to business. It appears everywhere around us.

It’s easy to find this phenomenon wherever you look. Commercial ads often make bold promises – as if buying a motorized toothbrush from company X would somehow help you win the Olympic games in curling (even without long fingers!).

We all know this; you won’t break any records by buying the same shoes as the world’s no. 1 sprinter. Still, our brains tend to jump to conclusions in search for more energy-efficient ways to succeed. It infers causation when there might be correlation at most.

Our brains are wired this way. In Thinking, Fast and Slow, Daniel Kahneman describes the mind as

“A machine for jumping to conclusions”

Why is that something evolution has rewarded?

If your life depends on making fast fight, flight or freeze decisions, then it makes sense. Jumping to a conclusion about the intent of a big tiger eyeing you on its breakfast menu can literally save your life. In many life-death situations doing something is better than doing nothing, even if causation evidence is lacking.

In product development we see a similar pattern. It is well known that smaller initiatives tend to move faster and contain less uncertainty.

But speed itself is not the real objective.

Product development is fundamentally a learning process. The goal is not to deliver what we already know the customer wants. The goal is to discover which problems are worth solving and which solutions actually address those.

Therefore, the real benefit of faster development is relevance. When you have an idea of a solution to a customer problem, the best way to validate the idea is to test with real users in their actual environment.

If it takes years to produce a testable version, the world has already changed:

• the customer needs have changed
• new technology has become available
• competitors have introduced better alternatives

You end up testing an old solution to an old problem. Then, what have you learned?

Enterprise feeling of Slowness

In my work with large product organizations across telecom, automotive, finance and others, there is a constant feeling of slowness. Ideas take years to materialize, initiatives are huge, there are many dependencies between them, and there are dozens upon dozens of them running in parallel.

At the same time, the governance model assumes that

• decisions are taken per initiative, as if it was the only one in motion
• initiatives are assumed to be largely independent in terms of technology, solution, people, test and validation resources
• execution is governed in separate forums, focusing on one initiative or a set of them

At some point someone inevitably suggests the obvious solution:

“We should make initiatives smaller.”

And this is where the correlation–causation trap appears.

Large initiatives are not the root cause.
They are a symptom of the system which causes initiatives to become large.

Instead, look for these causes leading to large initiatives:

• Resource-based funding
• Annual planning
• Dependency-rich architecture
• Fragmented ownership
• Functional-oriented organizational structures

Large initiatives are often a consequence of how organizations fund work, structure teams, and make decisions. To make initiatives smaller, you have to change the conditions leading to them being large.

Enabling relevance by changing roadblocks to speed

If large initiatives are a symptom of the system, the real question becomes:
Which conditions need to change to improve flow and relevance?

In my experience, some of the most important ones are:

Capacity funding

Funding capacity enables the organization to change priority with more ease. When funding is allocated on a per-project basis, capacity becomes locked into a specific solution. If priorities change — which they inevitably do — organizations must first wind down one project before starting another. This introduces waste in the form of unnecessary delays and administrative overhead.

At the same time, the real assets of a product organization are not the budget numbers attached to projects. They are the people, processes, tools, and partnerships that enable value creation.

Instead, funding should be decoupled from specific initiatives. Fund a product development organization and enable continuous prioritization of available resources based on clear objectives and measurable outcomes. Utilize a long-term perspective when judging what capabilities are needed in the future.

Shorter feedback loops

Faster feedback loops allow teams to validate assumptions earlier and significantly reduce uncertainty.

Start by understanding what the main bottlenecks to faster feedback are — and then invest in removing them.

Earlier in my career I was responsible for Integration & Verification of a mobile network solution. At the time we ran about 600 tests every six months.

The process was highly manual and many of the test cases failed on the initial run. Finding and fixing faults was a massive undertaking because thousands of changes had accumulated in the solution between each test cycle. In fact, we rarely managed to pass all test cases before it was time to start all over again with the next increment.

A couple of years later, the same testing was done every week instead of every six months.

With much smaller batches of change, faults were significantly easier to identify and fix. Problems were discovered earlier, the scope of each investigation was smaller, and actual progress became much more certain. Getting to that point required a significant investment in test automation and way of working, but in the end it was worth it.

The key difference wasn’t working harder — it was enabling shorter feedback loops, which made it possible to detect and fix problems before they have grown too large.

Fewer parallel initiatives

In many large organizations, a significant amount of effort goes into starting new initiatives — far less is spent making sure ongoing initiatives are completed.

As a result, new work is continuously added on top of work already in progress. Over time, this creates a growing imbalance that often surfaces as last-minute crisis management toward the end of development.

Too many parallel initiatives create a state of permanent overload.

Work starts to queue, priorities become unclear, and teams are forced to split their focus across multiple initiatives. This leads to corner-cutting, delayed learning, and an increased probability of crises close to intended release.

I often argue that an organization could increase delivery speed by 20% simply by reducing the number of significant initiatives by 10%.

This is not just an intuition — it is grounded in systems thinking. In queuing theory, Kingman’s formula describes how lead time increases rapidly as system utilization approaches its limits, especially in the presence of variability. High variability systems such as product development experience this effect at lower levels of utilization than you might think.

In practical terms, this means that when organizations operate close to full capacity while handling many parallel initiatives, even small increases in load can cause disproportionate increases in lead time.

Reducing the number of parallel initiatives is often the fastest way to improve flow — not by working harder, not by removing variability, but by reducing the amount of work in process.

A critical side effect of reduction in workload is that it enables smaller initiatives.

In overloaded systems, smaller initiatives are often down-prioritized in favor of larger ones perceived as more “important”. Over time, this drives a behavior where independent work is bundled together into larger initiatives — further increasing complexity, dependencies, and lead time.

Reducing the number of parallel initiatives helps break this pattern. It creates space necessary to prioritize smaller, more focused initiatives — which in turn improve flow, feedback, and outcomes.

Dependency reduction

In large-scale product development multiple types of dependencies exist simultaneously — including technical dependencies between different parts of the solution, organizational dependencies between functions, and dependencies on shared resources such as specialized test equipment.

While each of these seems manageable in isolation, their combined effect on making initiatives large is significant.

In the previous section I introduced Kingman’s formula. Dependencies increase variability in the system. As dependencies increase variability, lead times grow rapidly even at lower levels of utilization compared to a system with fewer dependencies.

Every dependency introduces hand-offs, coordination, and waiting time — all of which add overhead. To compensate for this overhead, organizations tend to bundle work into larger initiatives, further increasing complexity and lead time.

In large-scale product development, dependencies cannot be eliminated entirely. But they can — and should — be actively reduced.

One of the most effective ways to reduce dependencies is to organize around cross-functional, empowered teams — which is the next topic.

High-performing organizations don’t manage dependencies better — they design systems with fewer of them.

Cross-functional empowered teams

One of the most undervalued changes to make initiatives smaller is to increase the degree of cross-functionality within teams.

Many organizations are optimized for resource utilization and therefore structured into narrow functional units. However, product development requires cross-functional collaboration — spanning multiple domains, skills, and parts of the organization.

Projects are often used as a way to temporarily organize this collaboration. But projects are, by design, temporary and focused on delivering a specific solution. Once the project is completed, the structure is dissolved.

As a result, learning is fragmented, ownership is unclear, and improvement of the overall system is not part of the goal.

Each new initiative requires coordination to be re-established across functions — increasing dependencies, overhead, and lead time. I have even experienced organizational “solutions” to this problem such as extending a project by adding subsequent releases to its scope.

Cross-functional teams break this pattern.

By bringing the necessary skills and ownership into stable teams, many dependencies can be removed entirely rather than managed. This reduces coordination overhead, shortens feedback loops, and creates the conditions needed for smaller, more independent initiatives.

Cross-functional teams can take greater responsibility for understanding which problems to solve — and how to solve them. Empowered teams take initiative, simplify their way of working and want to stay engaged with their customers.

They are able to work with smaller initiatives without heavy governance and coordination overhead — focusing on faster learning and better outcomes, rather than implementing predefined solutions. Smaller initiatives are not the result of better decomposition — they are the result of teams designed to operate independently.

Improving flow rarely starts with making initiatives smaller — it starts with understanding the system that makes them large.

Change the system, and smaller initiatives will follow.

If you want to understand what is really slowing your organization down — and where to start — feel free to reach out.

The post The Correlation Trap: Why Small Initiatives Won’t Fix Your Delivery Problem first appeared on Business Caddy.

Some years back I wrote an article on LinkedIn arguing that you should not promise big changes, but rather take small steps instead. The focus of it was how easy it is to make bold promises of change and how hard they are to actually are to keep…both personally and within organisations.

I’m not going to restate the article (instead, I highly recommend you take a moment to read it yourself!) but what I proposed was essentially the idea of making consistent, incremental changes over time. It’s not a new idea at all, but it requires deliberate practice.

There’s a Japanese concept that perfectly encapsulates this approach, and it has become a cornerstone in Lean methodology. Known as Kaizen, this philosophy has become synonymous with the practice of Continuous Improvement, which is a fundamental principle of Lean thinking and organizational growth.

While small incremental changes are preferred and most organizations would benefit from more of it, sometimes a radical change is needed. Sometimes a radical change or shift is warranted.

There’s a Japanese term for this too; in Lean it’s called Kaikaku. The word roughly translates into “radical change”. Kaikaku describes fundamental change of an organization. It is completely overturning the existing modus operandi and should happen during a limited time period because otherwise it might cause more harm that good for the organization.

Much of what is called Transformation by name, becomes Translation by action

When we talk about Transformation, this is usually what it means; a complete change into something which is unlike what has been before – Kaikaku. The purpose often being to accomplish a step change which enables continuous improvement, Kaizen, in a new direction. However, much of what is called Transformation by name, becomes Translation by action. What I mean by that is that instead of fueling radical change, most efforts become focused on preserving the status quo by using new events, roles and tools but leaving underlying mindset, reward systems, governance structures and behavior largely unchallenged.

How come? It doesn’t take much time browsing your favorite online bookstore (try searching change – I found more than 100.000 books on the subject) to realize that many are searching for a way to make sustainable change happen, both in their personal life and in organizations. And sadly, even though many of the books make bold promises about easy ways to accomplish this, there are no “cut and paste” solutions which work for anyone and anywhere.

In business as well as personal life we often underestimate the long-term effects of small, consistent changes and overestimate the short-term gains from large, disruptive change. Change takes time so why not commit to consistently making small deliberate changes, observe what effects they have and then adjust based on that?

Drop a message if you want to discuss how your organization can improve your change habits.

The post Disruptive or continuous change – you need both! first appeared on Business Caddy.

I recently held an inspirational talk for a group of people responsible for one of the IT portfolios at a large bank in Sweden. They found it interesting and useful so below is an article based on it.

Improving agility at scale is one of the hardest things an organization can take on. Many companies set out to “become agile”, but few manage to change the very structures, governance, and financial steering models that hold them back.

Over the past decade, I’ve had the privilege of guiding several large enterprises through their transformations — across different industries, cultures, and continents. A clear pattern has emerged: if we want to accomplish real improvement of business agility, the most impactful transformation has to happen at the top. There has to be significant change in how we fund, govern and organize the portfolio.

Why Portfolio Management Matters

When I ask why a company chooses to organize initiatives into a portfolio, I’m often met with complete silence. There’s a lot of do’s and don’t, but very few Why’s.

One thing I’ve learned is that the likelihood of be successful with managing your portfolio is more related to clarity of the purpose than how you manage it. If a clear goal is missing then the best you can do is to hope for a couple of lucky breaks to come your way.

The simplest answer I can come up with on the purpose of a Portfolio is this:

To utilize common governance over everything within the portfolio, believing that doing so will create better results than not doing so.

In other words: portfolio management isn’t about control — it’s about enabling competitive advantage through combining different options within the portfolio into a coherent value proposition which outperforms your competitors’ propositions.

The Flow Fundamentals

A portfolio should really be viewed as more than a set of initiatives or projects. It’s a system — a dynamic network of people, processes, and tools working together to create value for customers.

Work flows into and out of this system, and how that flow is managed determines how quickly, sustainably, and happily we deliver outcomes than provide real value for our customers.

By viewing a portfolio as a system where work enters and leaves in a controlled way, it has the characteristics of a queuing system.

Just as gravity shapes our physical world, certain laws shape how work moves through a system — whether we recognize them or not. I call these the Flow Fundamentals:

• Little’s Law: There’s a relation between the number of ”things” in process, processing time for each “thing”, and the lead time of it through the system.
• Kingman’s Formula: Variability kills flow. Lead time in a high variability flow will be severely worsened already at low resource utilization level.
• Theory of Constraints: Improving the overall flow through a system can only be done by improving the current bottle neck.

When we start to understand these fundamentals, we stop fighting the system and instead use them to our advantage. Other ways of controlling the flow become possible.

Systems thinking and flow fundamentals are pillars of modern portfolio management, contact us to learn how you and your organization step up your game.

Creating Clarity

An effective portfolio needs three basic things to be clear for everyone working within it; scope, direction, and metrics. These provide answers to questions such as

• What’s in the portfolio and what’s out?
• Where are we heading? How is the portfolio intended to evolve? What should it not evolve?
• How do we know we’re moving in the right direction? What key metrics can be used to gauge progress or lack thereof?

Strategic themes help align teams and leaders around shared objectives, while metrics provide feedback loops that guide adaptation. The goal isn’t to measure everything, but to measure what matters — focusing on leading indicators of progress rather than lagging lack of results.

From Projects to Flow

Traditional, project-centric governance often clashes with modern product development. Projects assume predictability, but product development thrives on learning. Projects have a fixed end date, but successful products require change and adaption during their full product life cycle.

Most organizations focus mainly on project-centric governance, where projects are vehicles for major new products, change in how products or services are provided, or retirement of them. Much senior management attention is devoted to “getting it out the door”. There is lack of focus on continuous improvement and innovation.

Focus need to shift from managing projects to managing flow in the portfolio. In one large retail we started by visualizing all ongoing initiatives across domains, define clear prioritization principles, and introduce lean portfolio management practices.

Governance that Enables, Not Constrains

Good portfolio governance is about setting the minimum necessary constraints — guardrails that guide decision-making without limiting it. The same goes for portfolio operations: they should connect people, celebrate progress, and surface challenges early.

Establish minimum necessary portfolio governance, not maximum possible

Capacity management plays a key role here. Note, true portfolio capacity is not FTEs (Full Time Equivalents)! Product development is about collaboration and learning. Individuals are unique and have different skills. They too can learn and change. Interaction and teamwork have a great influence over both effort and result in work. These perspectives are not well represented by using the overly simplistic assumption that capacity can be represented by a number corresponding to 8-hour work units per day.

There is very little correlation between number of people working in the portfolio, and our ability to fulfill our business ambitions & customers’ needs. Furthermore, equating portfolio capacity with FTEs implies that the only way to increase capacity is to add people. This is simply not true.

Pull mechanisms and Queue management enable optimal flow within given system constraints. System constraints can be changed to improve flow over time, without adding people. This is where the flow fundamentals mentioned before come into play.

Capacity allocation, i.e. deciding which portion of capacity should be utilized for what, enables separation of concern & decentralized decision-making – it’s both-and, not either-or. Decentralized decision-making enables better solutions and empowers people.

Not every decision in a portfolio should be decentralized, but most development portfolios benefit from enabling aligned and parallel decision-making. An ever changing world requires better decisions and more decisions per time unit in order for the company o continue to thrive.

Prioritization with Purpose

Prioritization doesn’t need to be complicated, but it should be clear how it’s done. Start simple, evolve over time, and don’t replace thinking with formulas. Use methods like WSJF (Weighted Shortest Job First) as a guide, not a crutch. Enable re-prioritization when necessary.

In the end, business agility isn’t about being faster — it’s about learning faster what customers want, aligning better on how to provide solutions to those needs, and creating environments where people can thrive.

At Business Caddy, I help organizations find their rhythm — balancing structure and freedom to achieve meaningful results. If you’d like to explore how lean portfolio management can help your organization, let’s talk.

You can easily get in touch by using this form – we promise a fast response!

The post What I’ve learned about Leaner and more Adaptable Portfolio Management first appeared on Business Caddy.

My son: “Do you have a screwdriver I can borrow?”
Me: “Yes, but what do you intend to do with it?”
My son: “Well, I’d like to tilt the umbrella holder on my golf cart”
Me: “Okay, I see. You won’t need a screwdriver because it can’t be tilted”

How often do you get direct asks for solutions with zero context attached to them? I find it to be quite common both within and outside of business context. It might seem very efficient to ask very specifically for what is deemed necessary here & now. No time wasted for anything else than a clear ask.

In cases where the task is simple and straightforward, maybe that’s true.

But, what if the job you want to get done, or the customer problem can be solved in better ways than you are aware of? What if someone else near you knows something you don’t? What about complex situations where there is no one clear and simple solution?

The only way to discover this is to share context such as what you, or a customer, tries to achieve, and your reasoning leading to a solution. Only then will it be possible for someone to offer another way to solve the need.

In the short dialogue with my son it turned out that I already knew something about limitations to what he wanted to do. Had I only given him what he asked for, then he probably would have discovered that the screwdriver did not do the trick but it would have taken more time and he might have damaged the umbrella holder trying to tilt it.

It often feels unnecessary and wasteful to share additional context, but when several people collaborate to solve something it is essential. Essential because only then is the collective experience & knowledge fully utilized. Only then is innovation possible. Not sharing context is wasteful. Going slower in the beginning is faster than rushing from start. Share more context!

The post Share context for better solutions! first appeared on Business Caddy.

Agile transformations often start with big ambitions: cross-functional teams, happier employees, faster feedback loops, and more value delivered. But years later after the initial energy fades, many organizations find themselves right back where they started — slow, siloed, and stuck in legacy way of working. Major investments made in time, effort and money but with little to no visible effect on the business.

Why?

Because governance didn’t change.

The Hidden Constraint

You can coach teams, adopt frameworks like SAFe, and run Lean training for months. But if your governance model — how decisions are made, how funding flows, how progress is reviewed — still reflects a traditional, project-based mindset, your transformation will always hit a ceiling.

This is especially true if your organization is tasked with building complex products that consist of both hardware and software. You can’t unlock agility on the ground if the top is still wired for control and predictability.

Symptoms of Governance Misalignment

Here’s what it looks like when governance is out of sync with development and delivery:

• Teams are forced to commit to detailed plans years in advance
• Progress is reported in terms of milestones, not outcomes or insight from solution integration
• Funding is tied to projects, not value streams — leading to stop-start-stop work
• Decisions pile up at steering groups instead of being made closer to teams
• Risk is managed by review gates, not through fast learning and iteration

These aren’t just growing pains. They’re signs that your system is protecting itself from real change.

What Needs to Change

Transforming governance doesn’t mean removing oversight. It means rethinking how oversight works.

Transforming governance doesn’t mean removing oversight. It means rethinking how oversight works. For that to happen, mindset needs to change. It needs to shift from focusing mainly on execution of a largely outdated plan to making sure the organizational capabilities are focused on achieving desirable outcomes.

Here are three key shifts I’ve seen succeed in large, legacy-heavy organizations:

1. Fund Value Streams, Not Projects

Move from temporary project budgets to long-lived funding for persistent teams. This enables flow, long-term ownership, and better alignment with customer value.

2. Empower Decentralized Decision-Making

Push decisions down to the level of greatest insight and accountability. People organized in long-lived cross-functional Value Streams is a huge enabler for this. Governance should enable clarity, not create bottlenecks.

3. Measure Progress in Outcomes, Not Milestones

Shift focus from “Did we do what we said?” to “Are we solving the right problem?”
Use OKRs, lean metrics, or customer impact to steer.

Start With One Conversation

You don’t need to overhaul everything at once. But someone — usually at the executive leadership level — needs to name the gap between an ambition to increase organizational responsiveness and traditional governance.

Start by asking:

• What are we funding — projects, or capabilities?
• How do we make the connection between our Strategy and ongoing initiatives?
• How fast can a team respond to validated insight?
• Where are decisions getting stuck, and why?

Changing governance is hard. But without it, even the best teams will be constrained by a system that wasn’t built for agility.

Final Thought

If you want to meaningfully improve agility at scale, you have to change funding and steering — not just roles and events, but governance itself.

I help leaders and organizations make this shift in a practical, grounded way.
Want to explore how? Get in touch — or start by sharing this with someone asking why agile isn’t working.

The post Why Most Agile Transformations Fail Without Governance Reform first appeared on Business Caddy.