In organizations today, there's a constant, misguided cry to prioritize. Middle management often claims, "When we focused on just one or two projects, we delivered." While this may (or may not) be true, the rationale for prioritization is fundamentally flawed. The causal explanation embedded in this argument is that prioritization leads to delivery and, therefore, to success. Executives are not naive; they understand that focusing on just a couple of projects will not sustain the organization in the long run. If competitors are delivering newer and more innovative features at a much faster rate, and we are failing even to copy and deliver those features to our existing paying customers who demand them, prioritizing a few projects—even if they get delivered—will lead to the company's demise.
Real Challenge
The real challenge lies in systemic inefficiencies—the "corporate traffic jam." Executives are torn between delivering a few projects successfully and risking the company's future, or attempting multiple projects and potentially failing. They struggle to understand why, despite having abundant resources, they can only deliver a few projects. The reason is simple: they feel the outcome of systemic congestion but cannot see the underlying structure that truly causes it. Analogy never develops knowledge of systems, and because we are using analogy, it's important that we highlight the key differences between the two analogous systems before you start using that knowledge to drive change in your work management systems.
Difference between Traffic vs Work Congestion
We will list two of many key differences between traffic jams in transportation systems and corporate work management systems. In transportation, success is when individual cars reach their destination, so the throughput and cycle time of cars that move independently are the focus. In corporations, success isn't about individual project pieces (cars) getting delivered, but rather all pieces being delivered as a cohort. Think of the requirement that certain cars, starting from different locations on the highway, must take a given exit together as a cohort. Now imagine that every car is part of some cohort and they must stay together before taking an exit. What a fiasco it would be! Now assume that some cars have to take multiple exits with multiple cohorts. Whoa! The fiasco is way worse. This is the problem of corporate work traffic systems, and it's even worse than that. In traffic systems, each car knows where it's going; in the complex world of modern product and software development systems, new information emerges during the process, which may require us to even change the planned exit.
Traffic Jam: A Poor Analogy for Work Congestion
So this analogy of vehicle transportation systems for work management in corporations is terrible because it oversimplifies the complexity of work management—a complexity that is massive. On top of it, work management queues are all invisible, so we underestimate the problem we face. Executives receive reports about traffic jams but can't actually see them. Many executives don't even get a "traffic report," which program managers are supposed to collect from the ground. All they see are certain cohorts of cars (projects) labeled Red, Yellow, and Green in terms of PowerPoint decks or dashboards. Just because you know that projects are shifting from green to yellow to red doesn't mean you have an explanation for why projects are failing. Data never produces an explanation. I repeat: data never produces explanations. Thinking produces explanations, and unless we have a solid understanding of why things are happening the way they are, there's little chance of fixing it.
Fixable Problems with a Different Thinking Paradigm
It's important to note that these are not unfixable problems, but fixing them requires Systems Thinking and expertise in subjects like queuing theory, cadence, synchronization, batching, centralization vs. decentralization, human behavior, economics, and complex adaptive systems.
Note: We will discuss each of those over time, stay tuned.
Corporations forget that in modern business dynamics, developing systemic capabilities is the primary core competency; without it, there's no way to exploit the business opportunities presented to us. But instead of acquiring knowledge of Systems, a now well-developed field, most people wrongly believe they are already Systems Thinkers and apply common-sense explanations. As Jay Forrester, the founder of Systems Dynamics, not so famously said, "The enemy of complex systems is common sense." When common sense fails, all leaders can do is blame people for not doing their jobs right. I've attended executive meetings where there's little talk of systems and all the talk is about people (who are embedded in the system) not doing their jobs the right way. This reminds me of a quote from Edward Deming: "The supposition is prevalent the world over that there would be no problems in production or service if only our production workers would do their jobs in the way that they were taught. Pleasant dreams. The workers are handicapped by the system, and the system belongs to the management."
Most people in companies lack the ability to see the corporate traffic jam and fail to realize the much higher throughput and better cycle times their system could achieve if designed and managed by applying Knowledge of Systems. So, how do you acquire Knowledge of Systems? Many academies teach it, and we also teach it, but our course is a rigorous five-day program. Ours is a hard course—it burns your brain for five days as we prove how our understanding of systems is systemically wrong. Only when we are proven wrong does it open us up to think about how to be right. It makes you epistemically humble. Ours may be the only Systems Thinking course that spends a full day on epistemology, which is the question of how you know what you believe is knowledge. We may be the only organization that doesn't provide solutions unless you attend our course, because without it, our solutions would make no sense to your current common sense. Ours may be the only course that intentionally refrains from offering solutions that fit people's current understanding, because we aren't in the business of giving new solutions that fit existing understanding but rather of giving new understanding so you can find your own solutions. Even five days feels insufficient for that kind of learning.
Who Has 5 Days for a Course on Thinking?
Now, there are executives who reach out to us saying, "I've heard about your course and seen the testimonials, but we don't have five days." The general comment is, "Who has five days for a workshop?" Can you make it a quick one-day course because I've heard about your workshop? I ask them why they don't have five days to learn something that can enable systemic change. The answer I get is: "I have too much work." What work, I ask? The same work—prioritization, operationalizing, the job of removing traffic jams—because if they aren't there, projects will delay and fail. Essentially, they're saying they're the traffic cop; if they don't show up, there will be a traffic jam. That has become the job of the so-called leader: a traffic cop. And more importantly, their focus is on getting ambulances (high-priority projects) out of traffic. Then they think of themselves as leaders.
Leadership is Primarily Designing Systems, Secondarily Operating Systems
Consider this absurd thought: if the head of a transportation system told their boss, "With all the highways, roads, and bridges, I will only focus on getting ambulances to their destination, not thousands of cars," it would be preposterous. So why isn't it equally preposterous when program managers ask you to prioritize just two or three projects? When systems are invisible, the absurd becomes sensible. People fail to understand that the job of a leader is to fix systemic issues—it means designing or redesigning systems so they can deliver high throughput with low cycle time. But that's hard, and that's why leadership is hard. Leadership is no longer about motivating, pushing, driving, or leading people, because none of these approaches is sustainable. I can promise you, if that's all you do, within a few months you'll be blaming the same people you were trying to motivate and lead.
Leadership is about leading systems of which people are a part. The role of leadership can't simply be to ensure the delivery of a few high-priority projects by motivating people and working hard. Instead, it should be to design a system where many projects can progress efficiently and effectively. This requires shifting focus from making one or two individual projects succeed within the same system to creating a seamless system where multiple projects can be delivered concurrently.
Complexity is Not the Cause, We Are the Cause
Remember, companies don't die because of increasing complexity and a changing business environment. Companies die because people—especially positional leaders with power—lack the knowledge to handle that complexity and changing business environment. Blaming increasing complexity as a reason for failure may provide solace, suggesting that you weren't responsible for what's happening or happened, and it may sound like a good explanation to those who don't think in systems. But to us, who always close the loop and think in systems, we conclude that while rising complexity is a fact, it's not the reason for the demise. The real reason for the demise is our lack of knowledge of systems to handle that complexity.
I know you're all too busy to attend our five-day workshop on systems thinking, but we predict you'll remain busy forever unless you attend our five-day workshop. Both statements are true, but one is wrong, and the other is right. Now it's your turn to decide which is wrong and which is right.
We conduct our course when we have enough interested participants. If interested, please join the waitlist:
