Title: Management 3.0: Leading Agile Developers, Developing Agile Leaders
Author: Jurgen Appelo
Year: 2010
Pages: 451

If you’ve ever felt like traditional management advice just doesn’t cut it anymore, Management 3.0 might be the reset button you’ve been looking for.

Written by Jurgen Appelo, Management 3.0 doesn’t give you another checklist of leadership dos and don’ts.

Instead, it pulls you into the messy, unpredictable, and often surprising world of managing complex systems—like software teams, growing companies, or any group of humans trying to work together.

It’s not about having the perfect plan. It’s about understanding what kind of environment helps people and teams actually thrive.

As a result, I gave this book a rating of 8.5/10.

For me, a book with a note 10 is one I consider reading again every year. Among the books I rank with 10, for example, is Dale Carnegie’s How to Win Friends and Influence People.

3 Reasons to Read Management 3.0

Book Overview

What if everything you thought you knew about management—hierarchies, control, job titles, performance reviews—wasn’t just outdated, but actively making things worse?

That’s the kind of uncomfortable, but necessary, question Jurgen Appelo raises in Management 3.0.

In Management 3.0, Jurgen Appelo outlines three distinct versions of management thinking: 1.0, 2.0, and 3.0.

They’re not software upgrades in the literal sense, but they work as a useful metaphor to show how management has evolved—and where it still needs to go. Here’s how he breaks it down:

Management 1.0: The Command-and-Control Era

This is the oldest and most traditional style of management, rooted in industrial-era thinking. In Management 1.0, the manager is the boss—the one who gives orders, controls everything, and expects people to follow without question. It’s based on the idea that workers are replaceable parts of a machine, and the manager’s job is to maintain order and efficiency. There’s a strong hierarchy, lots of bureaucracy, and very little trust or autonomy given to teams. This version often treats people as problems to be fixed, not as potential to be nurtured.

Management 2.0: The Appearance of Change

Management 2.0 looks more modern on the surface, but often hides the same old mindset underneath. It includes many of the popular “best practices” like agile, lean, performance bonuses, engagement surveys, and team-building workshops. The problem? These tools are often layered on top of Management 1.0 structures without changing the foundation. It’s like putting a fancy new dashboard in an old car—it might look better, but it still runs the same way. In Management 2.0, companies talk about empowerment and innovation, but decision-making remains top-down, and real autonomy is limited.

Management 3.0: Managing the System, Not the People

This is where Appelo offers a true mindset shift. Management 3.0 isn’t a framework or checklist—it’s a way of thinking about leadership as designing and nurturing the system in which people work. Instead of managing people directly, leaders manage the conditions that allow people to succeed. The focus is on energizing people, enabling self-organization, aligning teams with purpose, and building structures that evolve with the organization. It’s grounded in complexity thinking, which means accepting uncertainty, encouraging experimentation, and leading through influence rather than control.

In essence, Management 1.0 manages people as machines, Management 2.0 adds shiny tools without deep change, and Management 3.0 manages the system to support people.

He deliberately avoids pushing into “version inflation” and doesn’t try to forecast a Management 4.0—possibly because doing so would contradict one of his main messages: that complex systems don’t evolve in neat, predictable steps.

Instead of inventing the next big label, Appelo encourages leaders to focus on evolving with their teams and environments, continuously adapting rather than chasing the next big management trend.

Appelo argues that if we want real innovation, engagement, and agility, we need to stop just fixing individuals—and start fixing the environments around them.

But this isn’t just another business book preaching motivation tips or productivity hacks. It’s a deep dive into the messy, unpredictable, and beautifully complex systems that make up our organizations—and what it really takes to lead in the middle of all that chaos.

Appelo doesn’t hand you a blueprint. Instead, he offers a mindset—a way of seeing organizations not as machines to be optimized, but as living ecosystems that need care, flexibility, and the occasional shake-up.

He blends complexity science, systems thinking, and agile principles into a new perspective on leadership that’s both challenging and refreshingly human.

At the heart of Management 3.0 is a simple but radical shift: instead of trying to control people, we should create environments where people can thrive. That sounds obvious until you realize how many of our current systems—like rigid org charts, isolated silos, and standardized job roles—are built around the opposite idea.

One of the most compelling examples in Management 3.0 is the contrast between the spider and the starfish. A spider has a centralized brain; cut off a leg, and it’s just wounded. A starfish, though? You can cut it in half, and each part regrows.

That’s the kind of resilient, adaptive structure Appelo believes modern organizations should strive for.

Instead of presenting a grand theory, Appelo walks us through six interconnected views of management: energizing people, empowering teams, aligning constraints, developing competence, growing structure, and improving everything.

Each one explores a different facet of leadership, not in a linear way, but like lenses you can use depending on the situation. Some chapters dive into motivation, breaking down what really drives people beyond carrots and sticks.

Others tackle self-organization, making the case that giving teams autonomy doesn’t mean letting go of direction—it means shifting from controlling to guiding.

What’s refreshing is how much Appelo leans into the messiness of it all. He admits that every model is wrong—including his own. But some are useful. In fact, that’s one of the biggest lessons in Management 3.0: in a complex system, no single solution will work every time. What works today might fail tomorrow. So instead of rigid processes, we need continuous adaptation, fast feedback, and a culture that embraces learning—even when it’s uncomfortable.

The book doesn’t shy away from the hard truths. It shows how improvement isn’t always a steady climb—it’s often a chaotic mix of small tweaks and big leaps.

It explains why teams stagnate, why leaders cling to power, and why innovation gets buried under bureaucracy. But it also offers hope, grounded in real practices.

From retrospectives to feedback loops, from communities of practice to Kanban boards, the book is packed with practical ways to build a more adaptive organization—without pretending there’s a one-size-fits-all playbook.

Complexity Thinking: At the heart of the book is the idea that organizations are complex systems—not predictable machines. They’re constantly changing, made of interconnected parts (people, teams, culture, technology) that influence one another in unpredictable ways. Instead of trying to control everything, leaders should focus on guiding and adapting within this complexity. Success comes from embracing uncertainty and creating environments that evolve alongside it.

Energize People: Motivated people are the real engines of great work. But motivation doesn’t come from rules or pressure—it comes from autonomy, purpose, mastery, and relationships. The book explores how understanding what drives each person individually can unlock team energy. From using tools like moving motivators to building trust, energizing people is about caring deeply and creating space for them to thrive.

Empower Teams: Great teams don’t need to be told what to do—they need the freedom to figure it out. Empowering teams means allowing them to self-organize, make decisions, and own their outcomes. But this freedom isn’t just about stepping back—it’s about providing the right support and clarity so that teams feel confident and trusted to act.

Align Constraints: While freedom is important, so is direction. Constraints, when used wisely, don’t limit teams—they guide them. The book talks about setting clear goals, boundaries, and principles that align team efforts without stifling creativity. It’s like giving teams the map and letting them choose the best path to get there.

Develop Competence: Continuous learning is critical for individuals and teams to stay relevant and effective. Developing competence isn’t just about sending people to training—it’s about building a culture of feedback, coaching, and reflection. The best teams grow together, learn from mistakes, and stretch their capabilities over time.

Grow Structure: Organizational structures shouldn’t be rigid pyramids—they should grow and shift like living organisms. The book encourages leaders to rethink hierarchies and consider networks, circles, and flexible roles. Communities of practice, guilds, and informal groups often carry just as much power to shape outcomes as formal reporting lines.

Improve Everything: Change shouldn’t be a big event—it should be a way of working. The book promotes continuous improvement through regular reflection, experimentation, and learning. Whether through retrospectives or small tweaks, teams should always be looking for what can be better, without needing permission or a special project to do so.

Kaizen and Kaikaku: Improvement comes in two flavors: small, continuous tweaks (Kaizen) and big, radical shifts (Kaikaku). The book argues that both are necessary. Sometimes, gradual improvement gets you far. But when you’re stuck, a bold leap is what’s needed. Smart leaders know when to maintain and when to disrupt.

The Red Queen Effect: Borrowed from Alice in Wonderland, this concept describes how, in a fast-moving world, you need to keep improving just to stay in place. If your team or company stands still, others will pass you by. It’s not about racing harder—it’s about evolving faster and smarter through learning and adaptability.

Fitness Landscapes: This idea helps visualize how improvement works. Imagine you’re climbing a mountain, but there are many peaks. Your team might be on a small hill thinking it’s the top. To reach a better place, you sometimes have to go down first—to take risks, experiment, and move into unfamiliar terrain. That’s the only way to reach higher peaks of performance.

Performance vs. Environment: Instead of blaming teams for poor results, this book invites leaders to look at the system around them. Often, it’s the environment—processes, tools, leadership style—that’s holding people back. Changing the system can do more to unlock performance than pushing individuals harder.

Feedback and Learning Loops: Fast feedback leads to faster learning. Whether it’s through retrospectives, metrics, or real-time conversations, feedback should be a regular part of team life. It helps people course-correct, celebrate progress, and make smarter decisions. The goal isn’t perfection—it’s learning quickly and moving forward.

Motivation Is Personal: Not everyone is driven by the same things. The book introduces models to explore what motivates people—things like status, curiosity, freedom, or social connection. When leaders understand individual drivers, they can create roles, rewards, and environments that bring out the best in each person.

Self-Organization with Support: Letting teams self-organize doesn’t mean leaving them alone. They still need guidance, clarity, and coaching. The key is balancing autonomy with structure—so teams can move fast but stay aligned with the bigger picture.

Structure Follows Purpose: The way you structure your teams and org chart should follow your mission, not the other way around. If your goal is agility, then rigid structures won’t help. The book urges leaders to constantly revisit and reshape their structures to match what they’re trying to achieve.

Celebrate Failure: Mistakes aren’t just tolerated—they’re essential for learning. Small failures, when surfaced early, help avoid bigger ones later. The book encourages leaders to create environments where people feel safe experimenting, sharing setbacks, and learning in public.

Context Is Everything: There’s no one-size-fits-all solution. What works for one team or company might fail in another. Copy-pasting practices without understanding the context leads to frustration. The best leaders take inspiration from others but adapt everything to their unique situation.

Visual Management Tools: Throughout the book, Appelo shares practical tools to make abstract ideas tangible—like delegation boards, moving motivators, and happiness metrics. These aren’t magic, but they help bring clarity, start conversations, and nudge culture in the right direction.

Continuous Reflection: One of the most powerful habits of great teams is stepping back to reflect. The book emphasizes creating time and space to ask: How are we doing? What’s working? What’s not? And most importantly—what should we try next?

Reading Management 3.0 feels less like sitting through a management seminar and more like talking with a brutally honest friend who’s been through it all. The stories are real, the tone is candid, and the ideas come wrapped in metaphors you won’t forget. It’s a book that respects the reader’s intelligence while challenging the status quo.

In the end, what Appelo offers is not certainty, but clarity. He doesn’t pretend to have all the answers, but he teaches you to ask better questions—and to see complexity not as a threat, but as a sign that you’re dealing with something alive and worth leading. If you’re tired of management books that simplify too much and solve too little, this one will shake you up in the best possible way. Not because it tells you what to do, but because it helps you understand what kind of leader your teams—and the world—actually need.

Chapter by Chapter

Chapter 1 – Why Things Are Not That Simple

Jurgen Appelo opens the book with a personal story—how he was once, on paper, a millionaire. His startup looked promising, investors were enthusiastic, and the revenue projections were beautiful… on slides. But none of that translated into real success. Visitors didn’t increase, developers didn’t boost speed, partnerships didn’t bring in money, and soon the dot-com crash swept everything away.

This failure became a powerful teacher. Appelo learned that what looks logical on paper often doesn’t work in reality. His experience shaped the core message of this book: to truly manage Agile teams, you must understand complexity—not just in systems, but in people and organizations too.

Causality and Our Obsession with Predictability

The chapter explores how humans are naturally wired to see the world through cause and effect. We love predictability. If A leads to B, then B must always come from A, right? Science used this logic with great success—from predicting comets to understanding physical laws. In software development, causality allows us to predict how code will behave. But in real life, especially in management, it’s not that simple.

The issue is that not everything follows a predictable path. You can’t predict the weather with perfect accuracy. You can’t fully predict the success of a product. You can’t even predict how your team will perform next month. That’s where complexity comes in.

Enter Complexity

Appelo compares complexity to the unruly little sister of predictability. Complexity doesn’t need large numbers to appear—even three water molecules can behave in unpredictable ways. The world of software development is full of these unpredictable interactions, making it hard to rely solely on traditional planning or control.

Science has evolved to explain this through chaos theory, network theory, and complexity sciences. These offer insights into how systems behave when cause and effect are not clear-cut. And this is great news for managers—because managing organizations, like building software, is full of complexity.

Linear Thinking Is a Trap

Despite all this, our minds still crave simple explanations. We want to blame problems on one person or one cause. Bad managers, bad hires, bad tools. It’s our way of coping with the messy reality. But this kind of linear thinking can be dangerous. It leads to oversimplified solutions and makes it harder to adapt to real-world challenges.

Engineers are especially drawn to control. Scientific management and command-and-control practices come from this mindset. But these methods only work well in environments with repetitive, predictable tasks—not in creative work like software development.

Reductionism vs. Holism

Another trap is reductionism—the idea that if we break things down into parts, we can understand the whole. It works well in many areas, but not always. We still don’t fully understand consciousness, economics, or even how teams function. That’s because the whole often behaves in ways that the parts can’t explain.

Instead, Appelo suggests a more holistic view. Complex systems, like teams and organizations, need to be seen as a whole, not just a collection of parts. Complexity science bridges the gap between reductionism and holism, recognizing that both have value, but neither is complete on its own.

Leaky Abstractions and Hierarchies

Appelo introduces the idea of “leaky abstractions,” borrowed from software engineering. Sometimes, lower-level issues bubble up into higher levels unexpectedly—like a strange error message from deep in the system. Organizations are like that too. A CEO may not need to understand team dynamics deeply, but when things leak, they can cause big problems. That’s why every level in a hierarchy requires different knowledge and awareness.

What Agile Management Really Means

When traditional hierarchical management embraces complexity and nonlinearity, it evolves into what Appelo calls Agile management. It recognizes that upfront control and perfect planning don’t work in software development. Instead, Agile accepts failure as part of the process and focuses on adaptability.

Agile concepts like self-organization and emergence are rooted in complexity theory. They acknowledge that building software is not a predictable journey—it’s a living, changing process.

But here’s the kicker: despite Agile’s success, managers often get in the way. Surveys show that cultural resistance, lack of support, and management attitudes are top blockers to Agile adoption. In Appelo’s view, traditional management is usually the problem—not the solution.

Looking for a Theory of Everything? Not So Fast

Appelo once hoped to find a grand unifying theory of Agile management. A model that explained everything. But complexity theory reminded him that such models are impossible. Instead, we need multiple perspectives and a toolbox of practices. That’s what this book aims to offer.

The Management 3.0 Model

To guide the rest of the book, Appelo introduces his model—Martie—which has six views on organizations. Each view will be explained in the chapters ahead, offering both theory and practical applications.

The chapter ends on a reflective note: if a book like this had existed when Appelo launched his startup, maybe things would have been different. But then again, maybe not. Sometimes failure leads us exactly where we need to go.

Chapter 2 – Agile Software Development

Jurgen Appelo starts this chapter by saying it’s optional. If you’re already familiar with Agile, you may know most of what’s here. But for those newer to the topic—or for anyone wanting a fresh perspective—this chapter gives a personal and practical overview of Agile’s origins, values, and why it matters so much in the world of software development.

The Personal Story Behind Agile

Before diving into frameworks and methods, Appelo takes us back to his university days in the early 1990s. He shares the story of how he built a personal bookkeeping software from scratch—30,000 lines of code, no formal process, and no experience. Just motivation, curiosity, and discipline. It wasn’t planned with any grand methodology, but it worked—and still works today, 20 years later, with only three minor bugs.

This wasn’t magic. He built it with passion, constantly used and improved it, had no rigid plans, and created a process as he went. Interestingly, when he later learned about Agile, he realized that what he did back then was unintentionally Agile. No big upfront design, constant feedback (from himself), iterative development, and evolving the system step by step.

The Birth of Agile

The formal world of software development used to be all about heavy processes, documentation, and structure. But over time, it became clear that these methods often caused more problems than they solved. Projects were slow, expensive, and often delivered outdated results.

Agile came as a response to that. It wasn’t about chaos either—it was about finding a balance between order and flexibility. It grew from the success of small, motivated teams who delivered high-quality software with simple processes. In 2001, the movement got its name when a group of thought leaders met in Utah and created the Agile Manifesto.

Agile, with a capital A, became more than just a method. It turned into a mindset—a way of working that acknowledges that software development is complex, unpredictable, and always changing.

Seven Dimensions of Agile

Appelo explains Agile using his own framework—seven dimensions of software projects:

People: Agile starts with people. They’re not just resources—they’re unique, creative individuals. Agile teams are small, cross-functional, and self-organizing. No manager imposes a method; the team decides how to work best together.

Functionality: The best products come from close collaboration with the customer. Features are added based on real-time feedback and evolving priorities. Agile teams keep requirements light until the moment of development and focus on building what actually adds value.

Quality: Agile puts quality at the center. Practices like test-driven development, pair programming, code reviews, and refactoring ensure the product stays strong. Design isn’t fully planned upfront—it emerges over time as the team learns.

Tools: Agile doesn’t ignore tools, but it doesn’t obsess over them either. The right tools—like automated testing, continuous integration, and visible boards—support collaboration and reduce repetitive tasks. But motivation matters more than any tool.

Time: Time in Agile is flexible. Work is done in short sprints or timeboxes, and features are released incrementally. This lets businesses adjust plans based on current needs. At the same time, Agile promotes a sustainable pace to avoid burnout.

Value: Because the world changes constantly, yesterday’s valuable feature might be useless today. Agile deals with this by encouraging frequent releases and fast feedback, so teams can deliver what users need—when they need it.

Process: Agile doesn’t mean no process—it means lightweight, evolving processes. Daily stand-ups, working software as the measure of progress, and regular retrospectives help teams continuously improve without being trapped in bureaucracy.

Adding The Role of Conflict: Appelo adds one more dimension: conflict. Disagreements are natural and healthy. In Agile, respectful conflict drives creativity and improvement. Agilists aren’t afraid to challenge ideas—including each other’s.

Agile Isn’t Alone

Agile doesn’t exist in a vacuum. It has relatives—and rivals. One of the closest is Lean software development, based on ideas from Toyota and Deming. Lean shares many values with Agile, especially around eliminating waste and improving the whole system. The two movements often overlap, and many practitioners work in both worlds.

There’s also the Software Craftsmanship movement, which emphasizes skill and quality in coding. These developers see themselves more like artisans than engineers and often follow a mentorship model. It complements Agile by focusing on mastering the craft itself.

On the other side, there are heavyweight approaches like CMMI, PMBOK, PRINCE2, and RUP. These traditional frameworks aim to bring structure and process to development. While some try to adapt to Agile, many in the Agile community see them as too bureaucratic and top-heavy. They’re seen as better at producing documentation than working software.

The Real Obstacle to Agile

This part is striking. If Agile brings so many benefits, why isn’t everyone using it? Studies show that the biggest barriers are internal: resistance to change, fear of losing control, lack of engineering discipline, and outdated management attitudes.

Appelo doesn’t sugarcoat it: many of these obstacles come from management. Managers often don’t know their role in Agile environments. And if the only message they hear is “we don’t need you anymore,” no wonder they resist.

That’s where this book steps in—to show that Agile still needs managers. But not in the old command-and-control style. Instead, managers must evolve, support Agile teams, and find their place in this new world.

Clarifying Management Roles

One of the biggest sources of confusion is the difference between line managers and project managers. These roles often get mixed up. Agile books and blogs don’t always make it clear who’s responsible for what. This leads to frustration and uncertainty.

Appelo makes it clear: this book focuses on line management—those responsible for people, teams, and long-term organizational health. Project managers and others will find value here too, but the main goal is to help line managers find their footing in Agile organizations.

Chapter 3 – Complex Systems Theory

Jurgen Appelo kicks off this chapter by pointing out something curious about humans: we wonder. We wonder about life, about the universe, about ourselves. And that curiosity is exactly what drives the exploration of complex systems—because real life, especially when it comes to teams and organizations, is anything but simple.

What Makes a System Complex?

Appelo agrees with many Agile experts who say software development teams are complex adaptive systems. These teams consist of many interacting parts, they can learn, evolve, and respond to change. That’s why understanding complexity is so important—not just as a scientific theory, but as a lens for how we manage people and work.

But here’s the catch: there’s no single “complexity theory.” Instead, there’s a body of knowledge—an evolving blend of ideas from many fields over the last hundred years. Appelo invites us to take a tour through this history, helping us understand how these theories connect and why they matter in Agile leadership.

Cross-Functional Science

Science itself has long struggled with silos. Just like companies with disconnected departments, scientific disciplines—like biology, physics, and economics—often don’t talk to each other. But many of their problems overlap. Local equilibriums in economics? Physics knew them already. Biological ecosystems? Math can help explain them.

Appelo argues that the biggest scientific breakthroughs often happen when people bring ideas from one field into another. That’s exactly what complexity theory encourages—a cross-disciplinary way of thinking. And it’s exactly what Agile teams need.

The Roots of Complexity Thinking

To understand complexity theory, we first need to look at six major “body parts” of the broader systems theory:

General Systems Theory: Born in the 1940s, this theory focused on the relationships between parts in any system—whether biological, social, or mechanical. It taught us that what matters isn’t just the pieces, but how they connect. Concepts like self-construction, identity, and stability all come from here. It’s why we now recognize that how a team interacts is just as important as who is on it.

Cybernetics: Developed around the same time, cybernetics is about feedback loops in systems. It teaches that instead of controlling with brute force, systems regulate themselves using information. That’s a key insight for Agile teams: feedback is how they learn and adjust.

Dynamical Systems Theory: This mathematical approach explains why some systems stay stable while others spiral into chaos. It helps us understand why teams or organizations fall back into old habits. Change isn’t just about effort—it’s about shifting deeper system patterns.

Game Theory: Originally from economics and biology, game theory helps explain how systems behave when they compete. This is especially relevant for teams and organizations that are trying to balance collaboration and competition—internally and externally.

Evolutionary Theory: Darwin’s ideas apply far beyond biology. Projects, teams, and products evolve, too. They adapt to their environments, or they fade away. Agile development fits this view perfectly—it’s not about perfect planning, it’s about continuous adaptation.

Chaos Theory: This is where the famous “butterfly effect” comes in. Tiny changes can lead to big, unpredictable outcomes. For software projects, this means estimation and planning can never be perfect. It’s a reminder that unpredictability is baked into complex systems—and we should stop pretending we can fully control it.

Making Sense of the Whole

Appelo ties all of this together by describing complexity science as a living body of knowledge—one with legs, arms, brains, and even a heart. Each theory contributes a different perspective, and none of them are complete on their own. Together, though, they help us understand the real, messy world of teams and organizations.

But here’s where it gets tricky: many people confuse “complicated” with “complex.” They’re not the same.

Simplicity vs. Complicated vs. Complex

Appelo introduces a useful model to explain the difference. Structure and behavior are the two dimensions to consider. Something is:

• Simple if it’s easy to understand
• Complicated if it’s hard to understand
• Ordered if it behaves predictably
• Complex if it’s somewhat predictable (with surprises)
• Chaotic if it’s completely unpredictable

So your watch might be complicated but not complex—it’s hard to take apart but works in a predictable way. A team, on the other hand, might be simple in structure but complex in behavior—you never quite know what will happen next.

This model is a helpful way to see that managing complexity isn’t about reducing everything to simplicity. It’s about understanding how systems behave and adapting to them.

How This Applies to Software

Many developers talk about “reducing complexity” in software. But what they usually mean is making things easier to understand (simplifying structure), not making behavior more predictable (which would be linearizing). The two are often confused, and that confusion can lead to bad decisions.

The key insight here is that you can have simple software with complex behavior. And you can have messy, complicated software that still behaves predictably. Understanding this difference matters a lot when designing, managing, or improving systems.

Complex Adaptive Systems (CAS)

Appelo draws a clear line between nonadaptive and adaptive systems. A whirlpool in a bathtub is complex, but it doesn’t learn. It’s nonadaptive. A software team, however, can adapt. It learns from experience, responds to feedback, and changes its behavior. That’s what makes it a complex adaptive system.

Agile teams operate in that “chaordic” space—between order and chaos. They need just enough structure to avoid falling apart, but enough flexibility to adapt quickly. That’s why Agile works. And that’s why managing Agile teams requires complexity thinking.

Are We Abusing Science?

Appelo admits there’s a risk in borrowing terms like “self-organization” and “emergence” from science. Some scientists argue that businesspeople misuse these ideas without fully understanding them. He even jokes about it—but still makes a serious point: we need to be thoughtful and respectful when applying scientific ideas to organizations.

Still, he believes it’s fair to use these terms in Agile, as long as we do it with care and clarity. After all, teams really do self-organize. Designs really do emerge. But we should always be ready to question ourselves and avoid turning science into shallow metaphors.

From Systems Thinking to Complexity Thinking

Finally, Appelo contrasts traditional tools like system dynamics and systems thinking with true complexity thinking. While helpful, those older models often assume that managers can plan, control, and steer organizations like machines. But complex adaptive systems don’t work that way.

Instead, complexity thinking embraces emergence. It says you can’t design a perfect organization from the top down—you have to grow it from the bottom up. Managers become gardeners, not architects. Their job is to create the right conditions, not control the outcome.

This chapter lays the intellectual foundation for everything that follows. It makes the case that if we want to lead Agile teams effectively, we need to understand complexity—not just as a buzzword, but as a mindset. And once we start thinking this way, we’ll never see management the same again.

Chapter 4 – The Information-Innovation System

In this chapter, Jurgen Appelo tackles a big question: if software projects are complex adaptive systems, what makes them work? His answer is rooted in how people interact, organize, and most importantly—innovate.

People as the Heart of the System

Complex systems, like software projects, are made of agents constantly reorganizing themselves. In biology, these agents could be cells or neurons. In software development, they’re people—developers, testers, analysts, designers—interacting in dynamic, ever-changing ways. Tools, requirements, and technologies are part of the picture, but only people actively organize, create, and adapt. That’s why energizing people is the foundation of the Management 3.0 model.

Innovation Is Not Optional

Appelo doesn’t mince words here: in today’s world, innovation is survival. Whether you’re a startup or a giant corporation, your ability to adapt and create new value is what keeps you alive. And the funny thing is, complexity science backs this up. Systems are most innovative when they operate on the “edge of chaos”—not too structured, not too chaotic. Right in the middle is where creativity blooms.

Top-Down Innovation Doesn’t Work

Innovation isn’t something you can assign to a special team in a corner office. Real innovation happens bottom-up, when the entire system is rich with the right conditions. Trying to plan innovation like a traditional project often kills it. Instead, Appelo introduces The Five Cogs of Innovation, which together drive creativity and action.

1. Knowledge
Software teams turn information into innovation. That process starts with knowledge, which comes from learning, feedback, experience, and communication. But here’s what’s fascinating: it’s not just how much someone knows that matters—it’s how well they’re connected. Rob Cross and Andrew Parker showed that people’s performance often depends more on their networks than their raw expertise.

In software teams, knowledge is often tacit, which means it’s shared through everyday conversation and collaboration. That’s why working closely matters so much. And why environments that encourage open, casual communication often lead to better outcomes.

2. Creativity
Creativity is the next gear in the system. It’s about combining ideas in new ways, finding original and useful solutions, and yes—sometimes stealing old ideas and giving them a new twist. Appelo shares a classic five-step model of the creative process that fits software work perfectly: preparation, incubation, intimation, illumination, and verification. Whether you’re designing a new feature or fixing performance bugs, this process is constantly in motion.

And while many developers don’t think of themselves as “creative,” the truth is, their work is deeply creative. They solve new problems daily, often in ways that are both original and highly useful—two essential ingredients of true creativity.

3. Motivation
People might have knowledge and creativity, but none of it matters without the drive to act. Motivation is what turns potential into progress. Appelo reminds us that people—not tools, not documents—are the only ones capable of truly managing and controlling complex systems.

Managers, then, should act more like gardeners than bosses: nurturing, supporting, and removing obstacles. The goal isn’t to micromanage but to energize. That means creating an environment where people feel empowered, engaged, and excited to contribute.

He also criticizes traditional models like Maslow’s hierarchy of needs. Motivation isn’t linear or simple—it’s dynamic and different for everyone. That’s why understanding what drives people is a constant process, not a checkbox.

4. Diversity
This section is both personal and powerful. Appelo shares how his own team evolved from a homogenous group of “20-something, white, straight, single males” to a much more diverse environment—and how that diversity made the company better.

Diversity brings stability, flexibility, and resilience. Just like a beehive needs bees that react differently to temperature changes, teams need different perspectives to solve complex problems. Too much sameness leads to blind spots.

He warns about the natural bias toward hiring people similar to ourselves—a trap managers need to avoid. Creativity thrives when there’s a mix of backgrounds, skills, and viewpoints. But it’s not just about variety—it’s about inclusive diversity: ensuring different perspectives still connect to a shared purpose.

5. Personality
Agile and Lean both highlight values like trust, respect, and openness—but which ones really matter? Appelo argues that focusing on a narrow set of values (like Scrum’s five or XP’s version) oversimplifies the reality. In truth, there are dozens of virtues—like humor, honesty, responsibility, and self-discipline—that influence team dynamics and creativity.

No single set of values works everywhere. Managers need to intentionally shape their teams’ personality traits to support creativity. The goal isn’t perfection—it’s balance. Teams need a mix of strengths, not carbon copies of the same type of person.

Why Only People Can Manage Projects

Appelo closes the chapter by bringing it all together: tools are helpful, but people are essential. According to the Law of Requisite Variety, only a system as complex as the one being managed can control it. That means only people—never tools or processes—can truly manage a complex system like a software project.

Tools act like sensors and emitters. They support action, but they don’t decide what to do. That responsibility lies with people, because they’re the only ones capable of making sense of complex, changing environments.

Ideas Are Nothing Without Action

One last important note: innovation without implementation is useless. Creative ideas only become valuable when they’re acted upon. That’s why managers must do more than host brainstorming sessions—they must make sure ideas turn into real, working solutions. In Appelo’s own words: software development is all about transforming information into innovation through knowledge, creativity, motivation, diversity, and personality.

Chapter 5 – How to Energize People

Creativity isn’t just for artists or kids—it’s vital for teams building software. This chapter opens with a bold message: if we want innovation, we need energized people. And energizing people means understanding what drives them.

The author frames creativity, motivation, diversity, and personality as the key ingredients. Knowledge is important too, but it’s parked for now. This chapter is all about the other four.

The Three Phases of Creativity

Creativity, surprisingly, has phases—like child development. The first is preconventional, where kids are wildly imaginative because they don’t know the “rules” yet. The second is conventional, where they begin to learn constraints and start playing by the book. Finally, there’s postconventional, the adult phase, where people break rules knowingly to create something truly new. This postconventional phase is where innovation really thrives—and it’s a manager’s job to help teams get there. The idea of a “beginner’s mind,” borrowed from Zen philosophy, captures this well: be curious, playful, and open, even with deep knowledge.

Creating the Right Environment

People can’t be creative if they’re afraid. So managers must foster psychological safety and playfulness. Let people fail without fear. Shake up routines. Add some visible creativity in the workspace. Even do something slightly uncomfortable—something at the “edge”—to stretch the team’s thinking. These aren’t just gimmicks; they’re ways to signal, “It’s okay to be different here.”

Creative Techniques

There are tons of tools for creativity—brainstorming, visual thinking, redefining problems, and more. The author sorts them into four categories: processes (step-by-step methods), problem definition, idea generation, and idea selection. Managers don’t need to master them all but should know when and how to introduce them to spark new thinking.

Motivation: Extrinsic vs. Intrinsic

Here’s where the chapter really gets critical. Extrinsic motivation—bonuses, praise, gifts—can backfire in complex systems like organizations. It can cause people to game the system or care less about the work itself. And worst of all, it can kill creativity.

Douglas McGregor’s “Theory X” assumes people hate work and need to be pushed. But “Theory Y” sees people as naturally motivated—if given the right environment. That’s where intrinsic motivation shines. Intrinsic motivation isn’t about the reward; it’s about the joy of the task itself. It’s self-driven. And it’s where creativity lives.

The 10 Desires of Team Members

Instead of assuming what people want, the author lays out ten human desires based on psychological theories like Self-Determination Theory and Steven Reiss’ 16 Basic Desires.

These include the desire for competence, autonomy, social connection, purpose, influence, and recognition.

They’re not complicated. But they require attention. And revisiting them regularly helps managers stay tuned in to what actually motivates their team.

But What If They Ask for Rewards?

Sometimes, people want bonuses or perks. The trick is to make them responsible for spotting the risks of those rewards. Ask them, “How could this system be abused?” This invites reflection instead of mindless incentives.

Also, there’s one deceptively simple question managers can ask that hits all the right notes: “What can I do to help you do your best work?” It’s powerful because it’s supportive, reflective, and invites real collaboration.

Balancing Motivation

Everyone’s balance of motivators and demotivators is different. The author humorously shares his dislike for collective code ownership and being forced to share his space—showing how policies can unintentionally drain someone’s motivation. That’s why managers should keep a “motivation balance sheet” in their head for each person. What energizes one might drain another. And if someone’s overall balance is negative, it’s time for a serious conversation—or even a change.

Make Rewards Intrinsic

Even when giving rewards, the goal should be to connect with people’s internal drives. Don’t just buy a gift card—give them something that fuels their curiosity, growth, or social connection. The meaning matters more than the item.

Diversity as Connectivity

This part flips the typical diversity conversation on its head. The author argues that connectivity—the way people form relationships and bring new perspectives into the team—is a more powerful kind of diversity than gender or background alone. Hiring should consider not just skill, but how someone expands the social and knowledge network of the team.

Personality and Team Building

To create balanced and resilient teams, personality assessments can help. Whether it’s the scientific Big Five, the detailed 16PF, or the more fun Myers-Briggs or Enneagram, these tools can build self-awareness and empathy. The author suggests a four-step approach: know yourself, share your results, ask team members to assess themselves, and—only if there’s trust—discuss those results together.

Team Values and Personal Alignment

The chapter wraps up by showing how teams can define their own core values—rather than adopting a generic list from management. Using a list of 50 virtues, teams can collaboratively pick the few values that reflect who they are and what they need. Managers, in turn, should align their own behavior with these shared values. Not by pretending, but by focusing on what comes naturally and striving to improve in areas that don’t.

No Doors, No Distance

Finally, the chapter challenges the idea of the “open door policy.” Instead of symbolically opening their office doors, managers should remove the doors altogether. Sit with the team. Share their environment. Share their coffee. True connection isn’t about access—it’s about being part of the same tribe.

Chapter 6 – The Basics of Self-Organization

Self-Organization Is the Default

Self-organization isn’t a special case—it’s the norm. The author opens by reminding us that linear systems, so loved by mathematicians, are actually the exceptions. Nonlinear, complex systems are everywhere: the universe, nature, societies, and of course, teams. And within those systems, patterns and structures form not because someone told them to, but because that’s just what systems do. This is self-organization in action.

From Quarks to Companies

To explain this, the chapter takes us on a fun journey from the Big Bang to modern-day businesses. Matter organized itself into atoms, atoms into molecules, and eventually into cells, life forms, societies, and yes—companies. No CEO told the quarks what to do. Everything evolved through self-organization within a given environment. This leads to the key idea: self-organization always happens within context, and that context influences the direction of the system.

Self-Organization Needs Direction

Just because systems self-organize doesn’t mean they always go in a good direction. The author points out that viruses are also self-organizing. That’s why humans developed laws, morality, and command-and-control structures—to help steer systems toward what we consider “valuable.” So while self-organization is natural, it’s human consciousness that brought intentional direction into the mix.

Command-and-Control Isn’t the Default

Many think self-organizing teams are a new idea. But the truth is, command-and-control came much later. It’s a human invention meant to protect what we value. Agile teams didn’t suddenly “discover” self-organization—it was there all along. What’s new is our effort to steer it thoughtfully.

It’s Not Chaos, It’s Complexity

Some people confuse self-organization with anarchy, thinking it leads to disorder. But that’s not fair. Anarchy simply means no central ruler—not necessarily chaos. Galaxies and ecosystems are anarchistic but not chaotic. The issue arises when the system behaves in a way the stakeholders dislike—like kids playing loudly while parents are on calls. That’s when governance kicks in. But it doesn’t mean the kids weren’t organizing themselves. They were—just not in the “right” direction.

Emergence and Team Identity

Now, the chapter shifts to the idea of emergence, where the whole becomes more than the sum of its parts. Your personality can’t be reduced to individual neurons. Similarly, team culture, decision-making, and shared identity emerge from interactions—not from any single team member. Like the “alpha rhythm” in our brains, which is more reliable than any individual neuron, teams can develop rhythms and strengths greater than any one person.

Emergent Behavior Is Unpredictable

Another twist: emergent properties are often impossible to predict. You can’t know what kind of team behavior will arise just by analyzing individuals. It’s the interactions that shape the outcome. And sometimes, teams surprise you with creativity, collaboration, or culture you never expected. This unpredictability is a feature of complex systems—not a bug.

Self-Organization vs. Self-Selection vs. Self-Direction
The chapter breaks down similar but distinct terms.

• Self-organization means people naturally arrange themselves and processes.
• Self-selection is when a team chooses its own members.
• Self-direction goes further, meaning there’s no outside authority steering the group at all.

There’s also self-management, which some use as a catch-all, but the author prefers to avoid it due to confusion. The key point is: all teams self-organize to some degree, but how much authority they have varies.

The Darkness Principle

In complex systems, no single person can know everything. This is called the Darkness Principle. Every team member has an incomplete view of the whole. That’s why planning and decisions must be made together. Agile practices like daily standups and sprint planning reflect this reality. It’s not about giving up control—it’s about recognizing that control is best distributed across those closest to the work.

Delegation as Smart Control

This leads to the Conant-Ashby Theorem, which says you can only control what you understand. But in complex systems, understanding is limited. So, the best way to manage is to delegate decisions to where the best understanding exists—usually the team itself. Smart managers don’t try to make every decision. They let subsystems (teams) manage themselves, like how the immune system works without central control.

Distributed Control Is Nature’s Way

Nature teaches us that distributed control leads to resilience. If our immune system had a single controller, a virus could easily take us down. Instead, control is shared among cells. The same goes for the Internet, which stays robust thanks to distributed servers. For teams, empowerment is the organizational equivalent.

Empowerment Isn’t New—But It’s Necessary

Although empowerment has been discussed for decades, it’s still misunderstood. It’s not about making people feel good or calling them “partners.” It’s about delegating decisions because it’s the only way to manage complexity well. Giving people autonomy isn’t a motivational trick—it’s a survival strategy for organizations.

A Story About Decision-Making

The author shares a personal story: he was asked to decide where projects should be executed. Instead of pushing the decision back with clear goals, he analyzed everything and made the choice himself—a waste of time. He should’ve just said, “Here are the goals. Figure it out.” That would’ve been real empowerment.

You’re Not a Machine Operator, You’re a Gardener

One of the most powerful metaphors in the chapter is that of growing instead of building. You don’t “build” a team—you grow it. Like a garden, teams need the right environment, care, and time to thrive. And just like plants, they grow in unexpected directions if not guided gently. Mature teams need less oversight, and when something no longer works, sometimes it’s time to prune or replant.

Self-organization isn’t optional—it’s how things naturally work. The job of a manager is to understand it, support it, and guide it, not to replace it. Empowerment isn’t about being nice. It’s about being smart in a complex world.

Chapter 7 – How to Empower Teams

Empowering Teams Starts with Letting Go

The author kicks off this chapter by reminding us that in today’s world, knowledge workers already hold real power—they just don’t always realize it. Unlike the traditional boss-employee dynamic, modern managers act more like coaches on a sports team. Their job isn’t to bark orders but to help the team win. And the first step is to stop being bossy.

Don’t Create Motivational Debt

When managers tell people what to do instead of asking, they create what the author calls “motivational debt.” It’s that subtle erosion of trust and commitment. People want to be asked, not ordered. The short-term fix of demanding action might feel efficient, but it adds up—and people eventually check out, disengage, or leave. A great example is when two employees were offered transfers to more “challenging” roles and declined—because they liked where they were. That rejection turned out to be a compliment to their current manager.

Be a Wizard, Not a Politician

The book draws a fun metaphor: managers should be like wizards, not politicians. Wizards give guidance, solve problems, and let the team do the real adventuring. Politicians, on the other hand, micromanage, talk endlessly, and love process for its own sake. Good managers, even reluctant ones, often make the best leaders because they focus on results, not control. They invest in becoming better—even if management wasn’t their first love.

Empowerment Is More Than Delegation

Delegation is just handing off tasks. Empowerment means encouraging risk-taking, supporting personal growth, and shifting culture. It’s about helping people realize how powerful they already are. It’s also essential for keeping complex systems, like Agile organizations, running smoothly. Without distributed control, everything breaks down—just like the Soviet system.

Reducing Fear and Building Status

Some managers resist empowerment because they’re afraid of losing control, relevance, or even their jobs. But the reality is the opposite. A manager’s status actually grows when they lead high-performing teams. The better your team, the more respected you are. Empowerment isn’t giving up power—it’s investing it and getting better results in return.

Maturity Levels of Empowerment

The author proposes three levels of empowerment maturity:

• Low: Safe, low-impact activities like choosing workshop topics or office decorations. A good starting point but don’t get stuck here.
• Moderate: Team interviews, choosing tools, flexible hours. This is where most Agile teams should be.
• High: Radical approaches like self-set salaries or choosing what projects to work on. These are rare and often need to be built into the culture from day one.

Just like training for any skill, teams need to earn their way up these levels.

Authority Isn’t All or Nothing

Empowerment also comes in degrees. The book introduces seven levels of authority, from “tell” (I decide) to “delegate” (you decide entirely). Different tasks can have different levels. Maybe you let the team choose their logo together (level 4), but retain authority over salaries (level 3). What matters is being intentional about the level and adjusting as people grow.

Tailor Empowerment to People and Tasks

Not every person or team is ready for the same level of responsibility. That’s okay. But it must be addressed openly and fairly. Explain why someone isn’t ready yet and how they can get there. Political correctness—treating everyone exactly the same despite clear differences in capability—can backfire and alienate top performers.

Also, decide whether empowerment belongs with a person or a team. Sometimes it’s safer to share responsibility across a group, but other times, one accountable person is best.

Use the Delegation Checklist

A practical tool is the Delegation Checklist. It asks things like: Do people have the right skills? The right tools? Do they know what success looks like? Have you given them boundaries and deadlines? If the answer is “no” to any, fix it—or have a transparent conversation and find a middle ground.

If You Want It Done, Be Patient

Here’s the trap: you delegate, something goes wrong, and you jump back in to fix it. Classic micromanagement. But delegation is an investment—it takes time and might feel messy at first. Taking work back too soon just resets the process. Instead, reflect on how you delegated. Did you explain the goal well enough? Set the right boundaries? Provide coaching? That’s your responsibility.

Push Back on Your Boss (Nicely)

Sometimes your own manager will pressure you to “take back control” after a team failure. But don’t fall for it. Instead, show how you manage through thoughtful delegation. Use the checklist. Explain the process. Most bosses care about outcomes, not micromanagement—they just need to know you’ve got a method.

Align Empowerment with Intrinsic Motivation

Not everyone wants more responsibility. Some are afraid; others are just not interested. The best way to shift this is to match delegated tasks with people’s intrinsic motivators. Someone driven by order might love documenting processes. Another motivated by status might jump at high-visibility projects. Understanding people’s desires makes empowerment more natural and effective.

Work on the Environment Too

Sometimes the problem isn’t people—it’s the system. Bureaucracy, outdated policies, and resistant departments can sabotage empowerment. As a manager, you’ll need to massage these parts of the system. Have honest conversations about risks, benefits, and costs. Find compromises that make empowerment possible.

Trust: The Four Directions

Trust operates in four directions:

1. You trust your team – Let them solve problems.
2. Your team trusts you – Keep your promises.
3. Team members trust each other – Encourage communication and follow-through.
4. You trust yourself – Believe in your judgment and decisions.

Each direction matters. Without them, empowerment crumbles.

Respect: The Other Half of the Equation

Respect is just as important. Disrespect leads to turnover, low engagement, and toxic culture. The chapter lays out a long list of disrespectful behaviors (micromanaging, yelling, favoritism, etc.)—the stuff that drives people away. But instead of memorizing the list, just ask for feedback regularly. “What should I stop, start, and continue doing?” The answers will guide you better than any checklist.

Also, understand your team’s work. Technical folks respect managers who “get it.” You don’t have to write code, but you need to speak their language.

Empowerment isn’t about being nice. It’s about building better systems, better teams, and better results. The best managers give power away—not to lose it, but to amplify it. The more you empower others, the stronger you—and your organization—become.

Chapter 8 – Leading and Ruling on Purpose

Why Constraints Matter

The chapter opens with a key shift in the Management 3.0 model—from empowering teams to aligning constraints. The idea is that while giving teams autonomy is great, some boundaries are necessary. A manager can’t just hand over everything and disappear to a beach. Certain responsibilities still belong to leadership, especially when it comes to defining direction, protecting people and resources, and guiding the system with purpose.

Learning from the Game of Life

To explain how systems behave under different rules, the author uses Conway’s Game of Life—a mathematical game where simple rules applied to cells on a grid create fascinating, complex patterns. What’s important is that depending on the chosen rules, the system either thrives, stagnates, or collapses. This shows that while self-organization is powerful, the structure and constraints that support it must be carefully tuned. Without thoughtful boundaries, the system doesn’t evolve—it either freezes or descends into chaos.

Understanding System Types

Stephen Wolfram’s classification of systems offers a helpful metaphor:

• Class I: Boring and dead.
• Class II: Static, overly ordered.
• Class III: Chaotic and unpredictable.
• Class IV: Complex, creative, and stable—the sweet spot.

The goal isn’t to micromanage teams into Class IV, but to create the environment where teams can adapt and evolve toward it themselves. This subtle distinction is critical: managers don’t design the game—they ensure that players can shape the game together.

You’re Not the Game Designer

Here’s where the metaphor gets real. The author stresses that managers aren’t game designers like Conway or Klaus Teuber (creator of Settlers of Catan). Unlike board games, organizations are adaptive—they evolve their own rules over time. Managers who try to define all the rules kill innovation. Instead, their job is to adjust parameters—things like team diversity, information flow, and inter-team connections—to create space for self-organization to thrive. When managers over-control, they actually block the very creativity they want.

Self-Organization Isn’t Always “Good”

The author shares an example from Gomorrah to make a sharp point: self-organization by itself can be dangerous. The mafia, after all, is self-organized. In human systems, without protection and fairness, self-organization can lead to exploitation or even harm. This is where the second responsibility of a manager comes in: protect the system. Just like a government protects citizens, managers must safeguard team members and ensure shared resources are treated fairly.

Manage the System, Not the People

Drawing from complexity science and biology, the chapter explains that complex systems (like teams) can only self-organize within boundaries. Whether it’s a football field or a herd in the savanna, boundaries define the space where self-organization happens. Managers don’t need to control people—they need to shape the system. They’re not puppet-masters, but gardeners, adjusting the environment to let good things grow.

The trick is in directed evolution—adjusting constraints to subtly guide outcomes without dictating actions. In other words, managers influence what emerges by shaping the space in which people collaborate.

How Self-Organizing Teams Begin

Good news: you don’t have to “initiate” self-organization. It happens naturally when people are placed together with boundaries and a shared purpose. Just define the frame, give the goal, and let the team evolve. Trying to force or over-engineer the process is what breaks it.

Leadership vs. Governance

A lot of books contrast leaders and managers, often putting leadership on a pedestal. But the author finds this misleading. It’s not about leaders versus managers—it’s about leadership and governance. Both are parts of the manager’s role.

• Leaders attract followers through influence and inspiration.
• Rulers (or governors) use authority to set laws, assign tasks, and enforce structure.

Both roles are necessary. In a football game, you need the captains (leaders) and the referees (rulers). Some managers lean more toward leadership, others toward governance. That’s fine—as long as they do both responsibly.

The Purpose Question

The chapter ends with a big philosophical question: What’s the purpose of a team or an organization?

The author explains that purpose comes in three forms:

1. Intrinsic – The natural “urge” of a system. For a software team, it’s to build software.
2. Extrinsic – A purpose assigned by someone, like a manager or client.
3. Autonomous – A purpose created by the team itself through its interactions.

It’s tempting to believe organizations exist solely to create shareholder value (hello, Milton Friedman). But that’s a mistake. Organizations are living systems made up of people, and people aren’t machines. Shareholders own assets—not people, thoughts, or culture.

As Jack Welch later admitted, shareholder value is an outcome, not a strategy. A team’s true purpose must emerge from within—shaped by intrinsic tendencies, extrinsic goals, and team autonomy. Trying to impose one fixed goal limits what teams can become.

This chapter reframes what managing actually means. It’s not about controlling people or forcing outcomes. It’s about creating the right boundaries, offering protection, and setting direction so teams can find their way forward. You manage the system, not the individuals. Leadership and governance aren’t opposites—they’re tools in the same toolbox. And purpose isn’t something you dictate. It’s something you nurture.

Chapter 9 – How to Align Constraints

The complexity of goal setting

This chapter dives into the practical side of leading with constraints—specifically how to guide, support, and protect self-organizing teams by setting goals, rules, and boundaries. The author starts by pointing out something that’s surprisingly common: confusion over basic terms like vision, mission, and goal. Experts, dictionaries, and frameworks all disagree. So instead of obsessing over perfect definitions, the author sticks with a simple purpose—helping managers offer teams useful direction through goal setting that actually works.

Give people a shared goal

One of the key lessons here is that teams need a shared goal. Not a vague corporate phrase, not the CEO’s personal KPI—but a goal that the team can rally around. The author distinguishes between “goal” and “meaning,” saying the former is about external direction, while the latter is more intrinsic and personal. Most of the time, we blend the two, but for managers, the goal should be about giving the team a clear sense of direction that aligns everyone without killing their motivation.

He explains how poorly implemented management-by-objectives (MBO) created a backlash in Agile circles. That’s because it often becomes a top-down reward system, where goals are handed out annually with bonuses attached. Agile teams don’t need that—they need a goal that unites them, helps them make decisions, and adds to their sense of purpose.

Checklist for Agile goals

The chapter offers a fun but insightful checklist to test your goals. It goes beyond the usual SMART criteria and asks things like: Is the goal actionable? Memorable? Excitable? Visionary? The point is that not every goal needs to be all these things. It depends on context. A vacation goal doesn’t need to be measurable. A team goal might not be inspiring but must be realistic. The big danger, however, is when goals are tied to external rewards—especially money. That kind of extrinsic motivation tends to mess with team dynamics and can backfire in surprising ways.

Communicate your goal

Setting a goal is only half the work. People have to actually know it. A funny story in the book illustrates this when a company’s “value of the year” was completely forgotten by Christmas. So how do you make sure the goal sticks? Talk about it. Often. Not just in posters and slide decks, but in everyday conversations. Ask questions like, “How does this decision help us reach our goal?” If people can’t answer that, the goal isn’t working.

There’s even a moment of humility where the author admits that, despite his own experience of sharing goals publicly to stay motivated, some research suggests that keeping goals private might work better for some. Still, when it comes to organizational goals, silence doesn’t help anyone.

Vision versus mission

The author makes a thoughtful distinction: vision is outward-facing—what change we want to bring to the world. Mission is inward-facing—how we’ll get there. A team’s mission might be about quality and collaboration, while a company’s vision might be about revolutionizing the industry. One doesn’t override the other. And stakeholders, like Product Owners or shareholders, should not dictate the team’s purpose.

Allow your team an autonomous goal

Self-organizing teams often create their own shared goals, even if they’re informal. That could be as simple as “Let’s make work fun” or “We always deliver clean code.” When that happens, let them have it. Don’t impose a new goal that overrides what already inspires them. Instead, look for alignment—or even better, compromise. A manager’s imposed goal and a team’s own goal can and should coexist. Forcing one over the other will only hurt motivation.

Create a boundary list of authority

This part brings in a powerful concept: invisible fences. Often, people don’t know what decisions they’re allowed to make until they get zapped. That’s demoralizing. The solution? A “boundary list” that spells out authority levels for different decisions—who decides what, and to what extent. It prevents friction, empowers people, and keeps them moving instead of playing it safe.

Choose the proper management angle

Some companies are too rigid, others too chaotic. The author compares ordered systems with too many rules to chaotic ones with no clarity. Good management means finding the sweet spot for each decision area—quality, testing, hiring, and more. It’s about adjusting the level of authority just enough to get good results, without stifling initiative or losing control. This, he says, is the edge between order and chaos—where innovation thrives.

Protect people

One of the most powerful parts of the chapter comes from a personal story. The author shares his painful experience of being bullied in school—a self-organizing system where no one stepped in to protect him. That memory shapes his view that managers must look out for their people. Don’t just assume everyone is fine. Ask real questions like “Who are your friends here?” and observe. It’s not always obvious who needs support, but managers need to care enough to look deeper.

Protect shared resources

The Tragedy of the Commons shows up here: when too many people use a shared resource, it gets ruined. Offices, budgets, system admins—these are all limited resources. Self-organization won’t protect them. Managers need to step in with structure, trust-building, and long-term thinking. The book outlines four “I’s” for sustainability: Institutions (managers), Information, Identity, and Incentives.

Constrain quality

Another overlooked area in most goal-setting frameworks is quality. It’s not even in the classic project management triangle. That’s a problem. If you don’t define what quality means and make it one of your constraints, you won’t get it. The author proposes turning the triangle into a square—adding quality as a key factor along with scope, cost, and time. It’s a reminder that what you don’t ask for, you don’t get.

Create a social contract

Finally, the author introduces the idea of a “social contract.” If you expect a team to buy into your goal, what do they get in return? Beyond a salary, are you offering growth, support, or purpose? The idea comes from political theory—people give up some freedom in exchange for protection and value. In organizations, that translates to investing in people, giving them a voice, and creating an environment where everyone benefits.

This chapter wraps up by bringing it all back to intrinsic motivation. Good management means guiding teams without robbing them of their energy, ownership, or joy. And if we want our teams to thrive at the edge of chaos, then it starts with aligning the right constraints.

Chapter 10 – The Craft of Rulemaking

Why rules alone don’t work

This chapter opens with a simple but powerful observation: creating rules isn’t the same as crafting good management. The author reflects on how tempting it is for managers to introduce rules like “When X happens, people must do Y”—but argues that this approach doesn’t truly help organizations thrive. Instead, real progress comes when teams take ownership of the rules they follow, discovering and refining them through experience, not top-down direction.

Understanding learning systems

To explain this, the author introduces the concept of Learning Classifier Systems (LCS), a model from complexity science. These systems have three parts:

• Performance system: A set of rules (like If-Then statements) that respond to environmental input and produce actions. Think of it like a mental ecosystem of rules competing and cooperating in our brains.
• Credit assignment: The rules that work get stronger; the ones that fail get weaker. Over time, this shapes the behavior of the system.
• Rule discovery: New rules emerge by mixing and matching elements of existing ones—like how genetic evolution works.

The takeaway? People and teams operate like adaptive systems. They constantly test and refine their internal “rules” based on feedback and learning.

Rules vs. constraints

Here’s where it gets interesting. The author contrasts rules with constraints, using flocking birds as an example. Birds follow simple principles—fly in the same direction, don’t bump into others, stay with the group—which lead to complex, coordinated behavior. The idea is that constraints guide behavior without prescribing exact actions, unlike rigid rules. In a team, constraints like “stay aligned” or “avoid conflict” are more powerful than micromanaged procedures.

This is where many managers go wrong. They try to program team members like machines instead of setting the conditions that allow people to self-organize and thrive. When people just follow rigid rules, creativity dies. And ironically, that’s when things tend to go wrong.

Agile’s blind spot: competence

The chapter challenges the Agile Manifesto for assuming that people are naturally skilled and disciplined. But what if they’re not? A team full of unqualified or careless people won’t magically self-organize, no matter how Agile they try to be. The author compares this to traffic management in the Netherlands, where multiple systems—culture, training, licenses, rules, enforcement, and feedback—combine to keep drivers safe.

The same layered approach should apply in teams: teach people well, ensure they’re competent, and use a mix of feedback, constraints, and culture to support performance. Simply trusting the system isn’t enough if the people in it lack the necessary skills or discipline.

Craftsmanship matters

A central theme here is craftsmanship—the idea that good work comes from people choosing to learn, improve, and take pride in their work. Agile methods assume this mindset, but that’s not always the case in reality. That’s why the Software Craftsmanship movement emerged: to bring focus back to skill and discipline.

Being skilled isn’t enough if you lack discipline, and vice versa. The author introduces a Discipline-Skill Grid showing how both qualities must be present for true competence. This dual focus helps explain why some people perform better than others even in the same environment.

Diversity of rules and the subsidiarity principle

People often work differently—different ways of testing, documenting, coding, and collaborating. And that’s okay. In fact, diversity can be good, as long as it’s not chaotic. The key is knowing when to synchronize and when to allow individual freedom.

This is where the subsidiarity principle comes in: decisions (and rules) should be made by the lowest competent level in the organization. So individuals can set their own rules unless it’s proven that centralized rules are more effective. That simple idea helps balance autonomy with coherence.

The illusion of safety and shared space

The chapter takes a surprising turn by exploring how fewer rules can sometimes create more safety. In traffic, turning off stoplights can make drivers more alert. Without signs and signals, people take more responsibility—and accidents actually go down. The same happens in software development. Too many rules create a false sense of security. People follow checklists blindly and stop thinking critically.

Rules should be constraints, not commandments. And sometimes, the best thing to do is remove a rule and trust the team to figure things out.

Memes, memeplexes, and Agile

Borrowing from evolutionary theory, the author explains that practices like standups, user stories, and refactoring are memes—ideas that spread by being copied. When grouped together (like in Scrum or XP), they become memeplexes. These collections of practices reinforce each other and spread more successfully together than alone.

This helps explain why introducing a full Agile framework often works better than picking random practices. The memeplex has more power to stick and influence behavior. The takeaway here is that change spreads more effectively when wrapped in a story, a brand, or a framework people can adopt as a whole.

Broken windows and small problems

Finally, the author turns to the Broken Windows theory: small signs of disorder, like a messy desk or bad code, lead to more disorder. If people see that nobody cares about quality, they stop caring too. So it’s essential to fix small problems before they grow.

This ties into everything else: creating a culture of competence, attentiveness, and self-improvement starts with addressing the little things, not just the big strategic shifts.

Chapter 11 – How to Develop Competence

Forget maturity models—focus on real competence

The chapter opens with a provocative thought: labeling people or organizations with one “maturity” score just doesn’t make sense. The author argues that maturity models are too process-obsessed and fail to capture what actually matters—results. It’s like evaluating a plumber not on the work they did but on whether they followed a checklist. That’s not helpful. Instead of assessing entire organizations with one label, we should focus on the competence of individuals and the specific tasks they perform.

Competence starts with performance, not processes

The chapter introduces a big idea: organizations are living systems. Trying to assign a single “maturity level” to such systems ignores their complexity. The author prefers the term competence over maturity and suggests that performance—not rigid process—is what really matters. Competence is seen as the sum of small actions by individuals that create larger patterns of capability across an organization.

The seven-layer stack of competence development

To help organizations build competence, the author lays out seven levels—each one a fallback when the previous isn’t enough:

1. Self – It begins with people holding themselves accountable. If someone can’t reply to emails on time or follow through on tasks, that’s on them.
2. Coach – When self-discipline fails, a coach steps in to support skill development.
3. Tests – Verification helps confirm that someone can actually do the task required.
4. Tools – Reminders, checklists, and automation keep people on track.
5. Peers – Peer pressure, when positive, can push individuals toward better habits.
6. Supervisors – Supervision ensures tasks are done right when all else fails.
7. Manager – The final safety net. If everyone else drops the ball, the manager must catch it.

Each level of this “competency stack” plays a part in helping people and teams stay on course. The higher you go in the stack, the more costly and reactive the solutions become.

The trap of suboptimization

The author raises a crucial point about measuring performance: if you focus too narrowly—say, just on one team or one metric—you risk hurting the whole system. This is the suboptimization principle. To truly improve, you must measure across multiple levels (individual, team, business unit) and dimensions (quality, time, value, etc.). Isolating one dimension leads to blind spots, and blind spots lead to trouble.

Seven dimensions of performance

Projects shouldn’t be evaluated by just one or two indicators. The author lists seven dimensions: people, tools, functionality, quality, time, process, and value. It’s not enough to just measure “working software”; you have to look at the full picture. Think of it like tracking your health—not just your weight, but also heart rate, calories, and sleep. The same goes for teams and projects.

Better performance metrics

When it comes to evaluating performance, a few ground rules help:

• Separate skill (doing things well) from discipline (doing them consistently).
• Don’t rate people just on knowledge—look at delivery.
• Rate across multiple tasks and over time.
• Use relative comparisons (to themselves, to others, to industry benchmarks).
• Keep feedback loops short, using both early indicators and end results.
• And, perhaps most importantly, let the environment—not just the manager—generate the ratings.

Self-discipline is the foundation

A big part of competence comes down to self-discipline. The author lays out four essential ingredients:

1. Understand its importance – People must believe a task is worth doing.
2. Manage your time – No time means no action.
3. Don’t forget – Use tools and routines to remember.
4. Stay motivated – Make the work fun or meaningful.

Even when all of these are in place, people still need to see leaders modeling the behavior. If you skip meetings or ignore emails, others will do the same.

Coaching isn’t always a manager’s job

Managers don’t need to be everyone’s coach. In fact, it’s often better to let others—senior team members, external experts—coach those who need it. Competence leaders are not always line managers, but they play a key role in helping others grow. Delegating coaching helps people learn from those closer to their level or specialty.

Certification is a tool—not a badge of honor

The chapter takes a skeptical stance on certifications. They’re not useless, but they don’t guarantee competence either. Certification works best as part of a larger system—combined with coaching, feedback, and real-world experience. Just like getting a driver’s license doesn’t make you a good driver, a certificate doesn’t make you a good professional.

Use social pressure wisely

Peer pressure isn’t just for teenagers. In teams, it can be a force for good. But for it to work:

• People need to feel part of the group.
• The team must own a shared goal.
• Managers need to step back and let peer norms shape behavior.

When done right, social pressure can raise standards naturally, without top-down control.

Tools should guide, not just support

Tools should help people stay disciplined. The best ones are proactive—offering alerts, reminders, and guardrails to avoid mistakes. But here’s the catch: tools need to be adaptable to your business, not the other way around. If a tool can’t evolve with you, it’s holding you back.

Supervisors still matter

Despite all the emphasis on self-organization, there’s still a role for supervisors. While Agile discourages inspection and bureaucracy, some level of oversight is needed—especially to catch problems early. Zero-defect policies are unrealistic. Instead, the goal is just enough inspection to avoid chaos, not to enforce control for its own sake.

One-on-ones are your superpower

Regular one-on-one meetings are essential. They keep information flowing and provide a space for feedback and support. The advice here is simple: block out time, make it enjoyable, and treat these meetings as the heartbeat of your team.

360-degree meetings that actually work

Forget the stiff, top-down performance reviews. A real 360-degree meeting happens in a relaxed environment where people give feedback to each other face-to-face. Managers should go first to model the process and build trust. When done right, these meetings generate deeper understanding, more balanced feedback, and real learning.

Let standards grow organically

The author makes a compelling case for letting standards evolve bottom-up. When teams experience the pain of disorganized code or inconsistent practices, they’ll push for standardization themselves. The key is to make the value of standards visible through goals and metrics—so people want to change.

The manager’s real job: improve the system

In the end, developing competence isn’t about fixing people or enforcing rules—it’s about designing better systems. That means:

• Encouraging feedback loops.
• Creating full “packages” of habits and practices.
• Letting people lean into their strengths.
• Nipping small issues before they become big ones.

This chapter offers a roadmap for growing real competence, without relying on artificial ratings or rigid models. It’s about trust, feedback, clarity, and support. In a complex system, the best way to lead is by shaping the environment so people can thrive.

Chapter 12 – Communication on Structure

The structure of communication shapes the success of teams

The chapter opens with a fun but eye-opening observation: structure deeply influences communication. Whether it’s a wall between coworkers or the shape of your organization chart, physical and organizational barriers matter. The author starts by reflecting on how even pastries created more interaction than glass walls at his former job. This sets the stage for an exploration of how communication flows—or doesn’t—within systems, especially complex ones.

A loose gear knob and the illusion of problems

The story of the author’s car gear knob is not just amusing—it’s a perfect metaphor. What he saw as a quirky feature, the mechanic saw as a problem and “fixed” it without asking. This small event illustrates a much bigger issue: assumptions in communication. We often assume what others want or need, without confirming. That’s not communication—that’s projection. And it’s exactly the kind of thing that causes friction in teams and organizations.

Why most communication fails

The author dives into how real communication works: it’s not just sending a message, but ensuring it’s received with the intended meaning. Communication breaks down easily—through poor word choices, cultural differences, tech hiccups, or simply different mental models. And even when the message is received, there’s no guarantee it’s interpreted correctly unless there’s feedback.

In technical systems, we have ways to ensure the message was received (like TCP/IP protocols). In human conversations, the equivalent is mutual understanding—and it’s surprisingly rare. That’s why, the author explains, face-to-face interactions are so valuable in Agile teams. They help close the communication loop.

Communication = Information × Relationships × Feedback

Here’s a key idea in the chapter: communication is more than just information. You also need relationships to carry the information and feedback to verify it landed as intended. Roger Lewin points out that broken relationships are at the core of many organizational problems, and the author builds on that—saying it’s not enough to have good data or even good people; they need the right channels and trust to communicate effectively.

Nine capabilities of communicators

Rather than forcing people into rigid categories, the author introduces a more flexible way of looking at communication: through nine capabilities. Each person might excel in some and be weak in others.

• Connecting: Knowing lots of people
• Filtering: Knowing what to pay attention to
• Empathizing: Actually caring about what others say
• Understanding: Grasping the content of the message
• Developing: Creating new ideas from what’s received
• Managing: Prioritizing and organizing what gets communicated
• Broadcasting: Sharing messages widely
• Influencing: Persuading others
• Conversing: Having two-way exchanges that build understanding

This approach is powerful because it moves beyond stereotypes and looks at how communication actually works in networks.

The power of networks

Social networks—both physical and digital—are full of fascinating effects. The author highlights things like the “tipping point” where ideas suddenly explode in popularity, or the “long tail” where obscure ideas shared by many small voices can outweigh a few loud ones. Then there’s the “Matthew effect”—what’s popular gets even more popular, as attention tends to snowball.

Even within organizations, the way people are connected matters more than we often think. And you don’t need deep connections to create movement—sometimes it’s the weak ties that have the most influence.

Tuning connectivity and attention

Too many connections can overload people. Too few, and ideas don’t flow. Complex systems, like teams, need a balance. And most importantly, people need to learn how to filter. Information overload isn’t the problem—lack of filtering is. Good teams, especially those that stay together longer, get better at managing how they handle information together.

Selfishness leads to cooperation

One of the most insightful parts of the chapter is how selfishness, oddly enough, can fuel teamwork. Like ants or genes, people collaborate not because they’re saints, but because it benefits them. The author calls this “coopetition”—a mix of cooperation and competition. We work together when it helps us win.

From individuals to groups—and how boundaries help

Groups can form in different ways: by management, by team initiative, spontaneously, or by circumstance. But no matter how a group starts, to become a real team, it needs clear boundaries and a shared goal. Those boundaries shouldn’t be too tight or too open—they should be permeable, letting in new ideas without losing cohesion.

Autocatalytic teams and hyper-productivity

Here’s a great concept: autocatalysis. In some teams, people accelerate each other’s work so much that the whole group becomes faster and more productive. Everyone contributes to making everyone else better. That’s the sweet spot. The author compares it to molecules in a chemical reaction that reinforce each other. Agile practitioners might call it a “jelled team.” The author suggests that increasing diversity and connectivity makes this kind of productivity more likely.

Patterns and self-organization

From snowflakes to zebra stripes, nature is full of self-organizing patterns. The same can happen in teams. But meaningful patterns (like your heartbeat) are different from random ones (like frost on a windshield). For patterns to be useful in organizations, managers need to create space for them to emerge naturally—not try to control every detail.

Scale matters—but bigger isn’t always better

Fractals, which repeat patterns at every level, offer a model for growth. The lesson? Don’t scale by building one massive thing. Instead, replicate small systems that work. In biology, the biggest total biomass comes from small organisms like krill and ants—not elephants. The same applies to organizations. It’s often better to grow out (with many small teams) than to grow up (one big structure).

Communication isn’t just talking—it’s making sure meaning is shared. That’s harder than we think. But by understanding how networks, people, and systems interact, we can build smarter, more connected, and more adaptive teams. And sometimes, that just starts with recognizing that what looks like a bug… might actually be a feature.

Chapter 13 – How to Grow Structure

Why structure matters

Jurgen opens this chapter with his love for structure—be it in folders, blogs, or businesses. But he’s not a fan of rigid, fixed organizational charts. Instead, he argues for a flexible and adaptive structure that evolves with the people, products, size, and environment. His point is simple: no single structure fits all, and organizations must be ready to change, often and wisely.

Structure is context-dependent

You wouldn’t compare a spider to a starfish and say one is better. The same goes for companies. The structure that works for one might be a disaster for another. Environment, type of products, company size, and the people involved all influence how an organization should be designed. As these factors shift, so should the structure—otherwise, teams get stuck doing work no one needs, just because they have time to fill.

Start with specialization, then generalize

Jurgen makes a case for starting with specialists. He argues that trying to make everyone do everything (generalization) sounds good in theory but often fails in practice. Productivity comes from people doing what they’re great at. But pure specialization can cause bottlenecks and rigidity. That’s where generalizing specialists—or T-shaped people—come in. They’re experts in one area but can jump in to support others when needed. It’s a balance: depth in one skill, range in others.

Forget fancy job titles

He’s not fond of job title inflation. Instead, he recommends broad titles like “Software Engineer” or “Team Member” and reserving specific responsibilities for roles that can shift over time. This allows for flexibility and avoids the trap of people saying “that’s not my job.” Teams become more adaptable when responsibilities aren’t locked into job labels.

Support informal leadership

Leadership doesn’t always need a title. Sometimes the best leaders emerge informally—because of trust, skill, or initiative. Jurgen encourages fostering this kind of distributed leadership, where team members naturally take the lead in areas they’re passionate or skilled in. It makes the organization more fluid and avoids the bureaucracy of managing roles that might disappear next week.

Manage team boundaries carefully

People need to know who their team is. Clear team membership helps with identity, trust, and communication. Jurgen encourages small, stable, and long-lived teams. Ideally, people belong to one core team, not multiple, and they should stick together across projects when possible. Constant reshuffling kills cohesion. And yes, in case you’re wondering, his favorite team size is 5.

Functional vs. cross-functional teams

Most communication happens between people working on the same project—not people doing the same job. That’s why cross-functional teams (those built around delivering a shared outcome) usually work better than functional teams (grouped by role). But he’s realistic: cross-functional teams still need coordination, and that comes with its own challenges. The key is balance and context.

DP1 vs. DP2: Who coordinates?

Jurgen introduces two models of coordination. DP1 is top-down—managers make the decisions. DP2 is bottom-up—teams coordinate with each other. DP2 fits agile organizations better, allowing teams to self-organize and solve problems collaboratively. But DP1 might still be needed when teams aren’t ready for that level of maturity. It’s about picking the right tool for the job.

Create value units, not silos

Whether teams are cross-functional or specialized, they must all see themselves as value creators. A team isn’t just a cog; it’s a mini-business serving a customer—even if that customer is internal. This mindset helps avoid suboptimization, where teams focus on their own efficiency instead of broader goals.

Specialist teams have a place too

Jurgen isn’t dogmatic. He admits there are times when creating a specialist team (like system admins or UI designers) makes more sense than embedding them in every project. The key is to ensure these teams act as service providers, not gatekeepers. And if they’re no longer adding value? Time to dissolve them.

Use hierarchy for authority, not communication

Hierarchy isn’t evil. It provides a clear line of accountability and authority. But it’s a terrible way to handle communication. That should flow through networks—relationships, informal structures, and shared tools. A healthy organization blends hierarchy and network—what he calls a hybrid.

Hybrid and panarchy: A flexible approach

Jurgen introduces the idea of panarchy—a system where authority is distributed and teams can form, evolve, and dissolve as needed. It’s a step beyond hierarchy or even matrix structures. In a panarchy, people belong to multiple overlapping structures based on value creation. It’s about freedom and adaptability, not control.

No secrets, no barriers

Good communication depends on transparency. People need access to real information—not rumors or assumptions. Jurgen encourages open access to systems, reports, and even (controversially) salaries. Visibility inspires trust. And when good behavior is visible, people copy it. If you want teams to stand up every morning, hold those meetings in open spaces. Make the good stuff easy to see.

Connect and relate

Relationships matter. Resilient, innovative organizations are built on strong connections. Managers should know their people—not just their skills, but their families, interests, and dreams. Trust and openness come from real human connection. This isn’t fluff; it’s how information flows and problems get solved.

No structure is permanent. The real goal is adaptability. That’s the heart of this chapter: don’t get stuck with rigid org charts or processes. Let teams shift, merge, specialize, dissolve. Let structures emerge from value, from communication, from real needs. That’s how modern organizations grow—not with top-down planning, but through bottom-up adaptation.

Chapter 14 – The Landscape of Change

In this chapter, the author delves into the concept of improvement in the context of changing environments, with a particular focus on how systems adapt.

One of the core ideas explored is that environments are not static and are influenced by the systems that operate within them. This notion is illustrated through the author’s experience in Sweden, where the presence of humans—specifically the author and their partner—immediately attracted mosquitoes, showcasing how the introduction of a system into an environment alters that environment.

The Environment Is Not “Out There”

The environment is deeply connected to the systems within it. The idea is that the environment you encounter isn’t the same as one without your influence. This means that when you introduce something—like a software product—it will inevitably change the environment. For example, the introduction of a software product changes users’ behaviors, and unforeseen changes will emerge from this new interaction. The key message is that acting and observing are necessary to truly understand how an environment responds to a new system. The author emphasizes that acting first is crucial because it lets you shape the environment and not just react to it.

The Fear of Uncertainty

The chapter then shifts into discussing the inherent uncertainty present in complex systems. This uncertainty, highlighted by concepts like Heisenberg’s Uncertainty Principle and the Butterfly Effect, affects not only physical systems but also the business landscape. People fear uncertainty, and this often leads to decision paralysis. The fear of making mistakes can result in avoiding opportunities altogether. The author contrasts this fear with a real-world example: environmentalists’ fear of non-native species. Despite their apprehension, research has shown that most non-native species either have neutral or positive effects on ecosystems, illustrating that fear of the unknown can often be overblown.

Laws of Change

The author introduces Professor Meir M. Lehman’s eight laws of software evolution, emphasizing that systems must continually change to stay relevant. If they don’t, they lose their effectiveness over time. One interesting observation is that the effort required to change and adapt remains constant throughout a system’s lifecycle. The constant cycle of adaptation, along with increasing complexity, is seen as a fundamental aspect of successful systems.

Every Product Is a Success… Until It Fails

The chapter also touches on defining success in the software world. The traditional metrics—on time, within budget, and according to specifications—are often insufficient. Instead, the author suggests that a product is successful until it fails. In other words, it’s about postponing failure, which is inevitable for all products. The success of software products should be seen as a temporary state. Even products that seem to be failures initially can experience recovery and rebirth if the feedback and environment are adjusted correctly.

Success and Fitness: It’s All Relative

The concept of “fitness” is explored in terms of how systems evolve. Fitness, like success, is relative and determined by how well a system can adapt to its environment. For software products, their “fitness” is not simply about their features but their ability to serve a specific user base and deliver value. Fitness is dynamic, not fixed, and it reflects how well a product can meet its users’ evolving needs.

How to Embrace Change

The author stresses that managing change isn’t about following rigid processes but about embracing continuous improvement across multiple dimensions, not just processes. This is especially important in complex environments where processes alone cannot address the uncertainty and unpredictability of the system. Continuous improvement, therefore, should encompass not just processes but also the product’s functionality, quality, and the people involved.

Adaptation, Exploration, Anticipation

For change to happen, it needs to be embraced in a flexible, iterative manner. The author advocates for the use of adaptation, exploration, and anticipation as a constant cycle of improvement. The challenge is not only to adapt to what works but to explore new possibilities and anticipate future needs. Through cycles of reflection and learning, this iterative approach leads to continuous progress.

Doesn’t Anticipation Violate Agile?

Anticipation, while important, should be used in moderation within Agile methods. The key takeaway is that Agile doesn’t reject anticipation but keeps it to a minimal, manageable level. Overuse of anticipation can hinder the benefits of flexibility, making it essential to balance planning with the freedom to adapt.

The Red Queen’s Race

The “Red Queen’s Race,” derived from Alice in Wonderland, is used to explain why continuous improvement is necessary for survival in a competitive landscape. Just like the Red Queen said, “It takes all the running you can do, to keep in the same place,” businesses must continuously adapt to stay relevant. The constant evolution of software products—whether in response to users’ needs or market competition—mirrors this idea of a never-ending race to stay competitive.

Can We Measure Complexity?

As systems grow, complexity increases, and the challenge lies in managing that complexity. While there’s no single metric to measure complexity, it’s clear that as systems evolve, they tend to become more intricate. The author reflects on the balance of complexity—while it’s not always desirable, a certain level of complexity is necessary for systems to evolve and thrive.

Are Products Getting More Complex?

The chapter concludes with a discussion on the increasing complexity of systems over time. Systems, whether biological or technological, often evolve to handle more complex environments. However, as the complexity increases, so do the challenges of managing it. The key to surviving in this complex landscape is adaptability, which helps systems find balance amidst the growing complexity.

Fitness Landscapes

The idea of “fitness landscapes” is introduced as a way to visualize how systems navigate change. A fitness landscape plots how a system’s performance evolves relative to its changes. The more a system adapts to its environment, the higher it climbs on the fitness landscape. This continuous adaptation, akin to a hiker navigating a mountain range, is what allows systems to maintain or improve their fitness over time.

Shaping the Landscape

The chapter wraps up by discussing the challenges of navigating a fitness landscape. The interconnectedness of system parts makes navigating change more difficult, but also necessary. The more a system can reduce dependencies between its components, the more successful it will be at adapting and improving over time. For software projects, this means maintaining a balance where changes can be made without causing major disruptions.

In summary, this chapter highlights the importance of embracing continuous change and improvement in complex systems. Whether through adaptation, exploration, or anticipation, the key to surviving and thriving in a changing environment is flexibility. Change management, therefore, isn’t just about improving processes—it’s about continuously adapting the entire system, including people, tools, and practices, to meet evolving demands. Ultimately, success lies in postponing failure and staying adaptable in an ever-changing world.

Chapter 15 – How to Improve Everything

The trap of improvement models

This chapter opens with a bit of humor around how many improvement models are out there—so many that they could form their own agency. But while these models look nice in presentations, the author argues that most of them don’t go deep enough. So instead of relying on one of them, he proposes SLIP—Simple Linear Improvement Process—which pulls the common steps from five popular models (PDCA, QIP, AMI, IDEAL, DMAIC) into eight simple steps. It’s like creating your own GPS route using bits of different apps.

Why linear improvement is not enough

The SLIP model is helpful, but it assumes that each step brings you closer to a better outcome. The problem? Real life—and especially complex systems—don’t work like that. The improvement journey isn’t always up and to the right. Sometimes you do everything right and it still feels like a setback. That’s because teams often get stuck on local peaks of performance and can’t move to higher ones without first going through a valley. It’s like being in the Belgian Ardennes when you really want to get to the Swiss Alps. You need more than gradual tweaks—you sometimes need bold jumps.

Kaizen vs. Kaikaku

Here, the author introduces a useful contrast: Kaizen (continuous, gradual improvement) vs. Kaikaku (radical change). Most improvement efforts emphasize Kaizen, but teams also need Kaikaku when they’re stuck. You might have to change the whole game before small improvements start working again. He makes the case that radical jumps help you reach better territories, after which incremental changes can take over. It’s not either/or—it’s both, at the right time.

Adaptation, anticipation, and exploration

Improvement isn’t just reacting to what’s wrong (adaptation). It also includes imagining better futures (anticipation) and trying things just to see what happens (exploration). Nonhuman systems improve only through adaptation and exploration. But human teams have the edge: we can anticipate. Continuous improvement should combine all three modes.

Start by knowing where you are

This part tells a fun story about the author getting lost on a road trip—because he thought he knew the way. The lesson? Before you improve anything, you need to know where you’re starting. Otherwise, you’re just wandering. The same goes for teams. Tools like retrospectives, 5-Whys, and value stream mapping are there to help you get oriented. But even more important is for managers to go see the work with their own eyes. It’s hard to lead meaningful change if you’re stuck in the office far from the real action.

The landscape is always changing

In the real world, things don’t stand still. Mountains move, competitors shift, technologies evolve. So what worked yesterday might not work tomorrow. That’s why you shouldn’t aim for one perfect solution. Instead, improve continuously, make quick iterations, and avoid huge reorganizations that take months—because by the time you finish, the target might have moved.

Change the environment, not just the team

Sometimes the best way to improve a team is to change the environment around them. That means adjusting how other departments work, revising contracts, and rethinking the organization’s structure. Want teams to move fast? Then clear the obstacles in their path. And most importantly, create an environment where change is normal, not exceptional. If everything is always “a big initiative,” people will grow tired and resistant. Instead, normalize small, ongoing change.

Make change desirable

People embrace change when it makes them feel good. If it brings status, excitement, or a sense of purpose, they’re in. So, highlight what’s cool about the new thing. Let passionate experts inspire others. Celebrate wins. Make change taste like dark chocolate, not bitter medicine. And use your “early adopters” to spread the message naturally, without forcing it on everyone.

Make stagnation painful

The author shares a relatable story of losing data and how the disaster forced him to create a better system. Why didn’t he fix it earlier? Because there was no pressure. People don’t change until the pain of not changing becomes stronger than the effort required. If positive motivation doesn’t work, sometimes a little pain is what it takes to trigger action.

Celebrate errors and noise

In nature, mutations lead to evolution. In teams, mistakes lead to learning. So don’t fear failure—embrace it. Small errors help teams discover better ways of working. The author even suggests deliberately introducing small amounts of disorder (like “noise” or variation) to avoid getting stuck. He calls this “performance improvement by imperfection.” You shake up the system just enough to keep it from getting complacent.

Mix things up (like nature does)

Nature uses three powerful strategies for evolution: mutation (tweaks), crossover (mixing good stuff from two sources), and horizontal transfer (copying ideas from others). The author applies these to teams too. Retrospectives help teams mutate and improve. Mixing practices from two good teams can create something even better. And openly sharing practices—via blogs, conferences, or just coffee chats—lets good ideas spread quickly across the organization.

Don’t do copy-paste improvement

Here comes a warning. Just because something worked for another team doesn’t mean it’ll work for yours. Context matters. You can borrow ideas, but don’t blindly copy them. Understand your environment, adapt what you borrow, and always check if it truly fits your needs. Otherwise, you might end up with chocolate-flavored medicine that still doesn’t work.

The chapter wraps up with a list of practical ideas: run retrospectives, keep a visible improvement backlog, use structured improvement cycles like SLIP, set up a transition team to support change, explore Kanban as a framework, and support communities of practice. But the overall message is simple: don’t ever stop improving. Keep moving, stay aware, and treat change as a normal part of life—not a one-time event.

In the end, improvement isn’t a destination. It’s a habit. The peaks and valleys are always shifting, and your only job is to keep skating toward the next best spot—always moving, always learning, always adjusting.

Chapter 16 – All Is Wrong, but Some Is Useful

The trouble with finishing a book on complexity

The author opens this chapter with a confession: wrapping up a book about complex systems is almost impossible. Every model, every conclusion, every attempt at clarity risks being incomplete—or just plain wrong. Complexity thinking, as he puts it, is like marrying a black hole. It sucks you in and challenges everything you thought you knew. Still, despite this warning, he walks us through the core of his Management 3.0 model and what it’s really about.

The six views of Management 3.0

Rather than offering rigid pillars or fixed principles, the model is built around six views—because, in a complex world, different angles help us understand the same system in multiple ways. The six views are:

• Energize People
• Empower Teams
• Align Constraints
• Develop Competence
• Grow Structure
• Improve Everything

These are not isolated silos. They often overlap. For example, Communities of Practice (from Chapter 13) touch on competence, structure, and improvement. Team values (from Chapter 5) relate to energy, empowerment, and alignment. Everything connects.

Why the model is “wrong”

This is where it gets philosophical. The author talks about a concept called incompressibility—the idea that you can’t create a simple model that fully represents a complex system. The only accurate version of a system… is the system itself. That’s why any summary, framework, or model—including Management 3.0—is inherently incomplete. But that doesn’t mean it’s useless. As Gerald Weinberg suggested, multiple incomplete views are better than one oversimplified truth.

Models are useful, not perfect

He compares this to how we use wave and particle models in physics. They’re contradictory, but both help us understand the world. The same goes for software methods—Scrum, Kanban, XP. They’re complementary, even when they clash. What matters is understanding when and how to use them—not proving one is better than the rest.

Other management models are also “wrong”

The author doesn’t stop at criticizing his own model—he includes others in the same boat:

• The Toyota Way focuses on Respect for People and Continuous Improvement, which align with Energize People and Improve Everything. But it says little about structure.
• Deming’s 14 principles cover almost all the views in Management 3.0, except perhaps minimizing total cost.
• Mintzberg’s model shows what managers actually do—like dealing, linking, and controlling—whereas Management 3.0 is more about what managers should be doing, based on theory.
• Gary Hamel’s principles emphasize innovation, diversity, and creativity. But they seem to skip over the development of competence, assuming great people just parachute into teams.

Despite these differences, the author appreciates all these models. None are complete, but all offer value.

The Agile community’s identity crisis

The chapter then takes a more critical tone with the Agile world. Many Agilists argue about the “right” practices—automated testing, refactoring, unit tests—as if Agile has a checklist. But it doesn’t. The Agile Manifesto never mentioned those practices. Agile, the author reminds us, is about staying successful in changing environments. That’s it. It’s not about mandatory tools or rigid certifications. Declaring a practice “essential” often says more about the consultant’s agenda than the needs of the team.

Enter the Complexity Pamphlet

To offer some sanity in all this messiness, the author lays out his own mini-manifesto for thinking in complexity:

• Each problem has multiple solutions – There’s no single right way to do anything.
• Solutions depend on context – What works in one place won’t work in another.
• Changing context requires changing solutions – Today’s great idea might be outdated tomorrow.
• Strange solutions are best somewhere – Even weird practices have their place.
• Solutions change their own environment – One change leads to others, sometimes unpredictably.
• Simplicity requires understanding complexity – Without understanding how things work, simple answers become dangerous.
• We can’t predict the best solution – We have to try, learn, and adapt.

The key message? It depends. In a complex world, nothing is universally right or wrong—only more or less useful, depending on when and where you apply it.

The book closes with humility. The author knows his model is “wrong” in the sense that it can’t explain everything. But that’s the point. In complex systems, no single model ever will. That’s why we need multiple perspectives, ongoing learning, and a willingness to adapt. He invites us not to fight over who’s right, but to focus on what’s useful—and to keep improving based on what the context demands.

4 Key Ideas from Management 3.0

6 Main Lessons from Management 3.0

My Book Highlights & Quotes

“… The path for managers is clear: When they care about organizational survival, they need to care about innovation. When they care about innovation, they need to care about creativity. When they care about creativity, they need to care about intrinsic motivation. It’s almost like a Natural Law…”

“… The primary focus of any manager should be to energize people, to make sure that they actually want to do all that stuff. And doing all that stuff requires motivation…”

“… The 21st century is an age of complexity. It is the century where managers realize that to manage social complexity, they need to understand how things grow. Not how they are built…”

“… Agile recognizes that people are unique individuals instead of replaceable resources and that their highest value is not in their heads but in their interactions and collaboration…”

“… Delegation of control is a manager’s way of controlling complex systems. You push decisions and responsibilities down to a level where someone has information that is smaller in size and more accurate. Smart managers understand that they must try to make as few decisions as possible. For better overall control of a complex system, most of the decisions should be made in the subsystems…”

“… When aligning constraints for a group of people, a third responsibility of a manager is defining the direction of the self-organizing system. So yes, it’s true. Managers are manipulators. But they are manipulators of the system, not the people…”

“… Only by repeatedly accepting failure and subsequently purging its causes from the system you can steadily grow a software project and allow it to perform successfully…”

“… Self-organization is the process where a structure or pattern appears in a system without a central authority or external element imposing it through planning…”

“… Your job as a manager is not to create the right amount of rules in the organization. Your job is to make sure that the people can create their own rules together…”

“… Chaos theory taught us that even the smallest changes in a dynamic system can have tremendous consequences at a later time…”

“… Motivation is a fine example of social complexity. It is nonlinear and sometimes unpredictable. It cannot be defined or modeled with a single diagram…”

“… Simplicity is the key to a good design of each feature, and after their implementation, the usefulness of features is immediately verified by the customer…”

Conclusion

Management 3.0 won’t give you a tidy formula for leadership—and that’s the point.

Instead, it gives you a better lens to see your team, your company, and yourself.

It invites you to stop trying to “solve” people and instead start designing systems where people can thrive, adapt, and improve together.

If you’re ready to think differently about what leadership really means in today’s complex world, this book is your next must-read.

I am incredibly grateful that you have taken the time to read this post.

Support my work by sharing my content with your network using the sharing buttons below.

Want to show your support and appreciation tangibly?

Creating these posts takes time, effort, and lots of coffee—but it’s totally worth it!

If you’d like to show some support and help keep me stay energized for the next one, buying me a virtual coffee is a simple (and friendly!) way to do it.

Do you want to get new content in your Email?

Do you want to explore more?

Check my main categories of content below:

• Book Notes
• Career Development
• Essays
• Explaining
• Leadership
• Lean and Agile
• Management
• Personal Development
• Project Management
• Reading Insights
• Technology

Navigate between the many topics covered in this website:

Agile Art Artificial Intelligence Blockchain Books Business Business Tales C-Suite Career Coaching Communication Creativity Culture Cybersecurity Decision Making Design DevOps Digital Transformation Economy Emotional Intelligence ESG Feedback Finance Flow Focus Gaming Generative AI Goals GPT Habits Harvard Health History Innovation Kanban Large Language Models Leadership Lean Learning LeSS Machine Learning Magazine Management Marketing McKinsey Mentorship Metaverse Metrics Mindset Minimalism MIT Motivation Negotiation Networking Neuroscience NFT Ownership Paper Parenting Planning PMBOK PMI PMO Politics Portfolio Management Productivity Products Program Management Project Management Readings Remote Work Risk Management Routines Scrum Self-Improvement Self-Management Sleep Social Media Startups Strategy Team Building Technology Time Management Volunteering Web3 Work

Do you want to check previous Book Notes? Check these from the last couple of weeks:

• Book Notes #126: Inevitable by Mike Colias2025-03-24
• Book Notes #125: Revenge of the Tipping Point by Malcolm Gladwell2025-03-21
• Book Notes #124: Radical Candor by Kim Scott2024-09-04
• Book Notes #123: The Personal MBA by Josh Kaufman2024-05-09
• Book Notes #122: The First 20 Hours by Josh Kaufman2024-05-02

Support my work by sharing my content with your network using the sharing buttons below.

Want to show your support tangibly? A virtual coffee is a small but nice way to show your appreciation and give me the extra energy to keep crafting valuable content! Pay me a coffee: