In this part, we will explore together why companies frequently (unintentionally) screw up their constraints and what we must do to fix it.

Everybody who has ever worked at a bigger company has suffered from overconstraining. Picture the micro-managing manager who forces you to do things exactly their way, despite much better options being available. When we feel like we we don’t have a say, it sucks and hurts our work enjoyment.

What’s far less intuitive is that underconstraining is equally painful for our work enjoyment.

👋 Digging the content? Let’s talk Product☕. I’m available for Fractional Product Management, Workshops, Coaching, and Speaking.

Let me explain using a real-world example: buying jams.

Do You Want 24 or 6 Jams to Pick From?

Would you rather have 24 jams or 6 jams you can buy? Most likely you’ll answer more, because why would you settle for less options?

Scientists ran the following experiment: imagine two scenarios where you’re given the opportunity to try out and buy jams

1. 24 jams on the table

2. 6 jams on the table

In which scenario, do people buy more jams?

Do you believe the scenario where they have more choice will result in more sales, because you’ll be able to satisfy more and different needs?

Or the scenario with fewer options?

Which scenario would you prefer to participate in? Most people, if given a choice, would rather have more options than less options.

When people are faced with 24 jams, they can’t choose anymore. It’s too cognitively exhausting. They don’t want to exert the effort of trying out 24 jams and evaluating each to make a decision. So they don’t buy anything, despite having more options to choose from.

This phenomenon is called ‘Choice Overload’ and it’s extremely common. If we burden people with too many choices, this hurts their ability to choose.

Essentially, the the number of choices is too overwhelming and they become so scared of making the wrong choice that they don’t choose.

Smart right?

If you don’t choose you can’t make a wrong choice either.

In short: the second scenario with fewer jams is actually where you will sell more jams.

Choice Overload Is Prevalent

Choice overload is extremely common, here are some real-world examples:

• Someone struggles to pick from the menu due to too many options.

• You struggle to pick a travel destination or the hotel you’re going to stay at.

• You’re in a book store and you struggle to buy a book, because are just so many options.

However, choice overload isn’t just a problem in our every day lives, it’s also a massive problem at companies.

Let me give you some real-world examples of the consequences of choice overload:

• Company all-hand meetings. Every department is giving a presentation. After 30 minutes, everybody is depleted and stops listening. Leaders couldn’t pick who should present (choice overload), so everybody must present something. Now listeners will be forced to listen for many hours and struggle to remember what matters the most (cognitive overload).

• Having more than 3 OKRs. Leaders experience choice overload so they don’t choose. As a result, everybody who has to follow ten or more OKRs experiences cognitive overload. They settle for way too many OKRs and nobody remembers them. People can’t keep more than 3 - 4 elements in their heads at the same time, unless we can chunk many elements into groups of a 3 - 4 chunks.

• Roadmaps. When you look at a roadmap, you immediately get a headache because it’s filled to the brim with a gazillion roadmap items.

• Resumes. There are too many stories to tell and too many things you can put on your resume. We become overloaded and confused. We offload the hard work of deciphering the resume and why it matters to the recipient of the resume.

How do you prevent the problem of choice overload?

By providing the right amount of constraints. Constraints limit the number of viable choices.

We can define agency as the raw ability to achieve our goals. We want to have organizations where individuals have high agency, as that’s what makes solving complex problems possible.

We can visualize the relationship between agency and constraints as follows:

If employees experience diminished agency, it becomes difficult to solve complex problems.

If employees experience high agency, they can solve problems effectively, but the number of available options is limited by the constraints.

The most common situation at companies is one of low agency and high constraints: Railroading.

Railroading - High Constraints, Low Agency

In gaming, Railroading is a derogatory term for when player agency is restricted to go down a planned story path, regardless of player choice.

When you play a game where you’re being railroaded, everything is scripted and your choices don’t make a difference. These games can easily become boring, because your agency is basically limited to the pre-planned railroad tracks in front of you.

As companies grow, the number of constraints usually grow as well:

• Rules

• Layers & Hierarchy

• Approvals

• Processes

• Silos

The combination of high internal constraints with accompanying friction and bureaucracy usually results in a low agency situation where everyone is busy keeping the train running on its tracks: railroading.

Coordination becomes more important than collaboration and the number of constraints is so high that almost all cognitive capacity is expended to keep things chugging along on the tracks.

Now, imagine you would have a magic wand and you could remove all internal constraints by waving it around, would this fix anything?

Drifting At Sea - Low Constraints, Low Agency

If anything is possible, yet your employees are not used to handling this responsibility, then you’re going to be Drifting At Sea.

People are not used to having very few constraints and being faced with infinite possibility is extremely paralyzing. Remember, agency is about the ability to achieve our goals, but that still means you need goals and you need people who are capable of handling that agency.

If you’re used to working in an over-constrained environment with lots of railroading, you will struggle once those constraints are removed because you’re going to have choice overload and unable to handle the responsbility.

Sandboxing - Low Constraints, High Agency

Remember playing in a sandbox as a kid? Anything was possible within the sandbox, despite there being clear constraints. The constraints are actually what makes agency possible, because you’re not facing the cognitive overwhelm of too many or too few choices.

A sandbox game is a video game that provides players a great degree of freedom to interact creatively, usually without a predetermined path. Think of a game like Minecraft or the Legend of Zelda: Breath of the Wild.

What’s important is that you do need the right amount and right type of constraints to have agency. Internal constraints frequently limit agency, explicit intentionally chosen constraints can enable agency.

Sometimes, you’re in a situation, despite having few internal constraints you’re still overconstrained: this is called maze-solving.

Maze-Solving - High Constraints, High Agency

In the famous Apollo 13 space mission, the second oxygen tank exploded. The crew was forced to rebreathe the oxygen inside the capsule. Over time this would result in dangerously high levels of carbon dioxide (CO₂).

Engineers back in Houston put all the spare parts that were available in the Apollo 13 space craft on a table. How could they any combination of these available parts (constraint) to MacGyver a solution to prevent the astronauts dying from carbon dioxide poisoning?

They created a makeshift adapter using socks, duct tape and many other items which they dubbed ‘The Mailbox’. Here’s a picture of the Mail Box:

The ugly contraption worked and saved all the astronauts. This is an example of a problem with a high number of constraints together with high agency. You’re effectively trying to solve a maze and there are very few different solutions available.

The key thing is that these constraints are related to the problem you’re trying to solve, and not your internal constraints that limit your options of solving the problem of interest.

As otherwise those high constraints will limit your agency, and then you’re busy railroading.

The difference between rail-roading and maze-solving is the origin of the constraints that are being imposed. When you’re railroading, your organization is imposing constraints that limit your options in a way that increases your chances of becoming disconnected from the reality of the work.

When you’re maze-solving, the problem you’re trying to solve itself is imposing hard constraints which limits the different options available to solve it.

You Don’t Need Better People, You Need Better (Enabling) Constraints

If you want to prevent railroading or drifting at sea, then it’s crucial to limit internal constraints and implement powerful (enabling) constraints like

• Product Vision

• Product Strategy

• Pull-based roadmaps with goals that provide intent

The better your vision, strategy and roadmap provides (enabling) constraints, then help foster the conditions for autonomy and agency by leaving many options off the table. They should help with sandboxing and providing the right amount of constraints.

Providing the right amount of constraints means you enable play and collaboration. You’re effectively sandboxing your teams to collaborate in an effective way. It feels like everybody is playing on the same playing field, but with different areas of expertise.

If you have too many internal constraints, or you’re imposing too many constraints on your teams, then everyone will be busy railroading and focusing on the internal logistics of making anything happen at all.

The most common symptoms of railroading your teams are:

• Work is pushed to the teams.

• Everybody is always in meetings.

• Getting anything done is operationally taxing and decisions are slow.

• Solution-focus with lots of coordination.

• Lots of opportunities for cannibalization and unproductive conflict.

• Decisions are front-loaded as much as possible, because that’s people deem that’s what railroad tracks need to function.

In short, railroading is a symptom of an organization that’s optimizing for overcoming internal obstacles, while sandboxing is a symptom of an organization that’s optimizing for solving real-world problems.

The question isn’t: how do we prevent having constraints? Because we need constraints to do our best work. We should be asking the following questions instead:

• How do we provide the right amount of constraints, so that we promote collaboration, innovation and experimentation?

• What kind of (unintentional) constraints are we imposing on our teams that limit agency and result in railroading?

Break down those railroad tracks and try to create a sandbox with the right amount of constraints so that your best people can exercise their agency. When you remove internal constraints, your teams will initially perform worse, as due to learned helplessness it will feel like they’re drifting at sea.

But if you stick with it, they will leverage those (enabling) constraints to exercise all their agency and brilliance.

Stop railroading, and start providing the right amount (enabling) constraints to support the autonomy and agency that high-performing teams need to be high-performing.

In part III, we will explore together how you can use your roadmap to quickly identify the degree of railroading that’s taking place within your organization.

Your bee hive needs a new place to live. If you don’t find one within a few days the whole colony will perish.

Pressure, I know.

👋 Digging the content? Let’s talk Product☕. I’m available for Fractional Product Management, Workshops, Coaching, and Speaking.

You’re the lucky bee tasked with this prickly problem. Please bear with me, I promise to relate it all to Product Management in the end.

• How would you approach this high-stakes situation?

• What is the maximum number of days you would spend on exploration?

• What kind of places should you inspect for viability?

• How would assess the viability of every place you discover?

Easy questions for bees, much more difficult questions for us. Why are bees much better than us at finding the right location for their hive?

Bees Exploit Constraints To Optimize the Search Space

If we’re tasked with finding a new hive, we treat it as an Unconstrained Optimization Problem.

It’s a search problem without constraints: the search space is unbounded and there are near infinite options available.

In simple words, our unbounded search space is too large:

1. We see too many options that could be viable.

2. We don’t know what options are actually viable.

As smart as you are compared to any bee alive today, you’d probably still end up killing the whole colony. Because you don’t know any of the real-world constraints that matter for selecting a great home.

The reason bees are able to find a good hive for their colony is because they treat finding the right location as a Constrained Optimization Problem. The only way for bees to find a hive successfully is by considering the right number and right type of constraints.

If you use too few or the wrong constraints, then the whole colony may go extinct. Too many constraints, they’ll keep searching for too long, and the hive will die as well.

There are a gazillion ways for a hive location to be unsuitable and there are much fewer ways it can be satisfactory. Bees find the right hive for their colony by turning their exploration into a Constrained Optimization Problem with a bounded search space.

What Are Constrained Optimization Problems?

To paint a picture about the kind of constraints that apply for finding a viable bee hive (based on the research by Thomas Dyer Seeley and Roger A. Morse in the 70s):

• Ideal cavity volume of around 40 liters (roughly 10 gallons).

  • Less than 10 liters is to be avoided as it won’t be possible store enough honey to survive the winter.

  • If it’s more than 100 liters, they won’t be able to keep it warm during the winter.

• Entrance height of around 7 meters (21 feet). To keep safe from ground-dwelling predators.

• Distance from the original hive should be at least 800 m (half a mile), so they don’t compete for exactly the same nectar and pollen.

By introducing the right number and type of constraints you can turn an Unconstrained Optimization Problem into a Constrained Optimization Problem.

Ok, enough talking about bees. Why does all of this talk about constraints matter for Product Development?

Great Products Need Constraints

Almost everybody in Product Management has seen the below Venn diagram before, which is what Marty Cagan calls the four big risks in Product

This Venn diagram matters, because it helps to turn an Unconstrained Search Problem with near infinite options into a Constrained Search Problem with a limited number of options.

Why does this matter?

• If your product has too many constraints, your search space will become too small and your product will suck - we call this Overconstrained.

• If your product has too few constraints, your search space will become too large and there is a good chance your product will fail - this is called Underconstrained.

• If you’re using the wrong constraints, you’re searching in the wrong search space and your product will likely hemorrhage money. This unfortunate situation is called Misconstrained.

Building great products is about intentionally and intelligently introducing the right constraints to limit the search space so you optimize your chances of building a great product.

In other words: there are near infinite ways for a product to suck and there are much fewer ways it can succeed.

Constraints Are Necessary For Great Products

Do you know the computer game Duke Nukem Forever? If you do, do you think it’s a great game? 99.99% of the population will answer no to at least one of these two questions.

Duke Nukem 3D, it’s predecessor, is considered one of the best games of all time. Duke Nukem Forever, if you take into account the 14 years it took to make it, is one of the worst games of all-time.

Duke Nukem Forever is the textbook example of a game developed with too few constraints. Duke Nukem 3D was so successful that game developer 3D Realms could splurge DukeNukem Forever’s development with money.

Duke Nukem Forever is what happens when you send a swarm of bees to look for a new hive location without any constraints. The end result is lousy and unforgettable. Plus it will take forever.

You need constraints to build a great game. If you can lazily solve every problem by throwing more money at it, you will get a lazy and lousy product.

You might be thinking now: every company comes with constraints, we don’t all have money to splurge like 3D Realms. It’s important to differentiate between internal involuntary constraints and voluntary (enabling) constraints.

You don’t pick internal involuntary constraints, like the company working in silos, or the CEO demanding teams to develop a large feature that will take more than 6 months. You deal with these kind of constraints in the best way possible.

Sometimes your internal organization may already introduce involuntary constraints that may making developing a great product nearly impossible. Constraints are one of the primary reason why big companies struggle to innovate. Big companies usually come with so many baked-in internal constraints (hierarchy, layers, silos, approvals) that your search pace is already barren and boring before you even start.

Let’s say you’re one of the lucky ones and you have a manageable number of constraints at your big company, then you still have to impose the right constraints to limit the search space of your product.

Okay, let’s make this less abstract and more concrete by talking about some real world examples of why constraints help with building great products or doing great work.

I want to stress, it’s super easy to find hundreds of examples across all kinds of industries, because that’s how crucial constraints are for driving innovation.

I stumbled on most of these examples while reading books, doom-scrolling Reddit and YouTube.

The Right Constraints Driving Innovation

Food & Beverages

• Nutella

  • Invented during the World War II by an Italian pastry maker because of the cacao shortage.

• Fanta soft drink

  • Invented in Nazi Germany by Coca Cola from cheap ingredients and leftover craps (fruit pulp) to keep the plant alive despite Allied trade embargos.

• Popcorn

  • Popularized during the great depression as THE movie snack as it was super cheap yet still could offer an astronomical mark-up for movie theaters.

• Doritos

  • At Disneyland they threw away a lot of stale tortillas every day. Someone decided to cut these tortillas and fry them, so they had less waste t and could make more money.

Software

• Quake

  • Computers did not have the processing power for real-time, fast-paced 3D environments like Quake. John Carmack invented Binary Space Partitioning (BSP), to only render what the player is able to see.

• King’s Quest / Space Quest / Police Quest / Larry

  • Floppy disks could store very little data, yet these point-and-click games required players to walk around in fancy graphical worlds. To circumvent the storage constraint, all drawings were made using vector graphics.

Hardware

• ASML EUV lithography

  • Everybody thought the technology was so ridiculously complex that nobody would be able to pull it off. Now that complexity is their moat.

  Nespresso

  • Swiss aerospace engineer Eric Favre was annoyed by his Italian wife who kept complaining she could not find good espresso anywhere in Switzerland. He vowed to make a machine that was so simple that even the Swiss could make good espresso.

• Ipod

  • Thousand songs in your pocket.

• Iphone

  • Must use your fingers as a stylus and not allowed to have a physical keyboard.

• Palm Pilot

  • Had to fit in the pocket of a dress shirt.

• Lisa Mouse

  • Cost less than 15 dollar to manufacture

  • Must track smoothly on a Formica desk or a pair of blue jeans

Entertainment

• El Mariachi

  • Sundance winning movie made with a budget of 7000 dollars. The script was written around the location that was available and every shot was only a single take. Through clever editing Robert Rodriguez worked around any mistakes that inevitably were present in the single takes, which actually made the movie look incredibly fresh and unique.

• The Pitt

  • Everything takes place at a single location (hospital). No logistics, permits, scheduling conflicts. This allows for 15 episode seasons that can be delivered once per year, which is insanely fast compared to other high-quality TV series that frequently delay seasons for many years, like Game of Thrones.

• Four Finger Cartoon Hands

  • Almost all cartoon characters have four fingers, because five fingers were too expensive to animate, look bad on old movie projectors, and put you at risk for entering the uncanny valley where all the characters looked like aliens with spaghetti hands.

• Jaws

  • The mechanical shark Bruce did not work after production of the movie had already started. Steven Spielberg rewrote the whole movie based on the viewers not being able to see the shark. John Williams hard carried the movie with the two-note leitmotif that indicated the shark was coming. This movie was the first summer blockbuster ever and if the shark hadn’t broken down, the movie would never have been as successful.

• Star Wars IV: A New Hope

  • There was no budget to build space ships with custom plastic molds. George Lucas set a hard constraint to only buy off the shelf plastic model kits of tanks, ships and air planes which they refurbished and reused to build all the iconic space ships. This is why Star Wars looks so grimy and the rebels look like they scraped everything together, because they literally did.

Writing

• The Diving Bell and the Butterfly.

  • Written by Jean-Dominique Bauby by only using the blink of an eye.

• Green Eggs and Ham.

  • One of the most popular works from Dr. Seuss (Author of The Grinch) where he allowed himself to only use 50 distinct words.

Too Many, Too Few or Wrong Constraints Killing Innovation

• The Metaverse

  • $80 Billion spent to achieve absolutely nothing

• Boeing 747 Max MCAS Disaster

  • Don’t make any changes that will require pilot retraining while adding massive new engines that change completely how the plane flies in the sky. Boeing added an automatic system to prevent the plane from crashing, but didn’t adequately tell pilots about how it worked because then they would have not wanted to fly the plan. Boeing nearly went bankrupt because of this whole ordeal.

• Game of Thrones - The Winds of Winter

  • George R.R. Martin is 77 years old, loaded with money, and has been working on the book for almost 15 years. If he was starving, I bet it would be finished within a month.

• Vasa - Swedish Warship

  • Everything is better with MOAR CANNONS! Until your ship sinks.

• The DBA Act - The Netherlands

  • To prevent false-employment and ensure a fair working relationship (e.g. to prevent people working as freelancers without health benefits while they should be employees), the Netherlands rolled out the DBA act. Now, the Dutch government doesn’t want to hire freelancers anymore, even if they cost 500 euros per hour, because they are scared of being fined. As a result the whole Dutch freelance market has collapsed.

Building Great Products - Wide First, Narrow Later

The moment throwing more money at a problem becomes the default and lazy solution, then you can forget about driving any disruptive innovation.

Robert Rodriguez, who won the Sundance movie festival with the cheapest movie ever, expressed it in the best way:

“Lack of money and resources leads to creativity. When films have a high budget, they try to solve every problem with money.” - Robert Rodriguez

Movie director Michael Bay is the opposite of Robert Rodriguez, he makes movie with extremely high budgets and solves everything with money.

Everything is loud: explosions, CGI, car chases and property destruction. Michael Bay frequently makes popcorn movies where spectacle is more important than plot, pacing or logic. The movie Armageddon is an excellent example where they crazily enough sent oil drillers to become astronauts instead of training astronauts to become oil drillers.

I want to stress, Michael Bay made some great movies. He also directed the movie the Rock, which is one of my favorite action movies. This movie has much more restraint, creativity, and a legendary score by Hans Zimmer. The first Transformers was also pretty good (I skipped all the other ones).

As humans, we need the right type and number of constraints do our best work. It’s part of our job to find and apply the right number and type of constraints. If we don’t do the hard part of forcing intentional constraints, then we will be frequently be cursed by constraints.

Building great products requires exploration. This is what we call discovery. You should go wide first, to discover the constraints that matter for what you’re trying to achieve.

We shouldn’t prevent constraints, we should work hard to have the right number and type of constraints. Only then can we be blessed with our constraints.

The reason why Robert Rodriguez was able to film a Sundance winning movie for $ 7000 dollars, because he treated all his constraints as creative obstacles to be overcome. Here are some examples from his playbook:

• Don’t have money to write a script? He checked into a drug testing lab where he was paid money to participate in a drug trial. He had to stay here for one month.

• Don’t have a script? Write it in one month when you’re staying at the clinic for the drug trial.

• Don’t have actors? Ask some of your fellow patients to participate in your movie. The lead actor of El Mariachi was someone he met in the drug testing facility.

• Don’t have money for a movie set or to travel anywhere? Write your whole script around a location you know and can easily reach.

Once you believe you’ve got the right set of constraints, then you should go narrow and leverage those constraints to build the right product.

Product Management is hard, because there are a gazillion ways to fail and there are very few ways you can succeed.

As Product Managers, we should think more like bees:

How can we turn this Unconstrained Search Problem into a Constrained Search Problem?

What are the right (enabling) constraints for what we’re trying to achieve?

If we don’t think carefully about our constraints, there is a good chance they will end up working against us. And we’ll settle for the default choice of working harder or throwing more money at the problem.

The choice is simple: do you want to be cursed by your constraints, or do you want to be blessed with constraints?

In part II, we will explore together why companies frequently unintentionally screw up their constraints and what we must do to prevent it from happening.

We’re fooling ourselves if we believe autonomy is the wonder pill that makes everything better.

In fact, it may only make things worse.

👋 Digging the content? Let’s talk Product☕. I’m available for Fractional Product Management, Workshops, Coaching, and Speaking.

We’re going to explore the following three misconceptions together:

• Being autonomous means you can make completely independent decisions.

• More autonomy is always better.

• Autonomy is more important than alignment.

Autonomy ≠ Independence

Daniel Pink, who coined and popularized Autonomy, Mastery and Purpose in his magnificent book Drive, defines autonomy as follows:

“Autonomy is the desire to be self-directed, it increases engagement over compliance.” - Wikipedia

I want to emphasize, that the model of Pink is rooted in Self-determination Theory based on the pioneering research of Deci and Ryan, who created the original model with different labels: Autonomy, Competence and Relatedness.

Autonomy is not about being independent, it’s about acting with choice. Autonomy means carrying yourself with a sense of volition. You’re doing what you’re doing because it’s your choice to do so.

If another team gives instructions and tells you what you must do without additional context, that hurts autonomy: your self-direction and ability to choose.

If another team asks for your help and you decide to help them, even if you would be doing the exact same thing that they would have instructed you to do, then your autonomy is preserved.

Same end result, but a completely different outcome from the perspective of autonomy.

Autonomy has nothing to do with being completely independent, because we all know that is a fantasy in the modern workplace.

It’s incredibly rare that we’re a lone cowboy working in the Wild West.

Low Alignment = Independence

Autonomy is not about being independent of others. You can be highly autonomous AND be highly dependent on other teams.

Look at this picture of Aligned Autonomy by Henrik Kniberg from the famous Spotify Model:

Do you see anywhere in this matrix that autonomy is about working independently?

No, absolutely not. The matrix tells a completely opposite story: autonomy has nothing to do with independence.

The top left situation of high alignment and low autonomy shows everyone is still pulling in the same direction. They’re just less motivated and driven (see the sad faces) due to the lack of autonomy. The bottom half of the 2 x 2 matrix actually depicts the situation where everyone is doing their own thing, even if they score high on autonomy.

Low alignment is what causes people to work independently and not low autonomy.

Lack of Alignment = Independent Action

Let’s assume you have teams that are truly independent: they don’t need each other and don’t affect each other in any way. I want to emphasize this is a purely hypothetical example that rarely exists in the real world, but just try to follow my line of reasoning.

If teams are truly independent and don’t need each other in any shape or form, then alignment between teams becomes completely irrelevant. Everybody will move in their own direction, but given their independence it doesn’t matter.

I live in the Netherlands and somewhere in Australia there is a random person living their own life who also has a family with wife and two kids. Our families are not aligned in any way and it doesn’t matter because we’re literally living on the other side of the world minding our own business.

The problem is that our teams are not randomly constructed and they frequently do need each other.

In reality, if you’re working at a company, you’re invariably dependent on others outside the team in some shape or form. You’re not living in a completely different world in an insular bubble. You’re sharing a workplace environment that only works well if everyone plays ball together.

In a situation where teams depend on each other, alignment is more important than autonomy, because in such a scenario you can’t have autonomy without alignment.

No Autonomy Without Alignment

We need alignment for two reasons:

1. In the real world, teams do depend on each other. No matter how you structure them, they will need coordination or collaboration outside the team. Whether it’s HR, buying a new software license, or making sure everybody attends a security training, it doesn’t matter.

2. Autonomous teams that depend on each other require alignment. If your teams are heavily dependent on each other, then you can’t have autonomy without alignment.

When you take both of these points together: the situation of high autonomy and low alignment rarely exists in the real world, because teams that heavily depend on each other won’t have autonomy when they have low alignment.

When you have many teams working on the same product, even if they own independent features, domains, or different parts of the user journey, they will still need to be aligned. You could even argue that the way their teams are split up is already an implicit form of alignment.

If you’re in a situation of low alignment where many teams must collaborate with each other to create value and capture it for the business, then you roughly have two scenario’s:

1. One team chooses and gets exactly what’s they want. They enjoy high autonomy while the other teams don’t.

2. Everybody wants to exercise their autonomy in an environment of low alignment. Low alignment results in conflict and they struggle to reach agreement. Nobody has the freedom to choose and nobody gets what they want. The end result is diminished autonomy and teams may even end up undermining or sabotaging each other.

Autonomy is about maximizing the degrees of freedom so people can make the right choice, but it’s not about maximizing the degrees of freedom in isolation or at the expense of others.

When teams are dependent on each other, then the lack of alignment will hurt their autonomy. Lack of alignment in combination with the desire for autonomous teams is actually one of the primary reasons that companies end up working in silos.

Silos are not a symptom of low autonomy, they are a symptom of low alignment. The low alignment also produces low autonomy, but the root cause is the lack of alignment.

When teams have low alignment while they desire high autonomy, they will create silos to try and preserve the illusion of high autonomy. Teams will latch on to the little strands of autonomy they still have with their little fingers until their knuckles turn white.

The end result of trying to preserve high autonomy in an environment of low alignment is what I’d like to call ‘Snow Globe Ownership’, where every team is trying to operate from the insulated world of their perfect and magnificent little snow globe.

The snow globe is the only place where the team can enjoy high ownership and autonomy. We all know the snow globe is a lie, as there is a whole big scary world outside of the snow globe that matters far more than the team would like to admit.

Life is great as long as we stay in the snow globe. As long as everybody stays in their lane, we can have good things. But because we still need each other, we can’t have good things. The problem is that the snow globe approach fails when we need each other, because each snow globe looks at the problem from their limited and insular perspective.

Everybody is trying to maximize autonomy from the limited vantage point of their snow globe. There is the illusion of high autonomy when teams don’t need each other, but if you look at the big picture, the actual autonomy is low because there is no alignment.

You don’t fix silos by increasing autonomy, you fix them by first addressing alignment. Only when you fix alignment will it become possible to have high autonomy outside the myopic realm of the snow globes.

In summary: you can’t have autonomy without alignment. At least not when team need to work together to succeed.

Alignment Beats Autonomy

I believe we should not be talking about Aligned Autonomy, because in the real world talking about aligned autonomy is like talking about cold snow: you can’t have snow when it’s not cold and you can’t have autonomy without alignment.

Remember how I started this article with two false statements:

• More autonomy is always better.

• Being autonomous means you can make completely independent decisions.

In the real world, Autonomy does not exist in a vacuum. We inevitably need other teams or people outside our team.

The work we do, frequently does depend on others. In this context, if you incorrectly define autonomy as being able to act independently, then more autonomy for one team by definition, will hurt the autonomy of other teams.

The reason why autonomy frequently gets conflated with independence is because the moment teams are highly dependent on each other, then that increases the chance one team will begin telling another team what to do, which puts autonomy at risk. Telling people what they must do without them having a say is the opposite of autonomy.

Instead of giving orders and instructions, turn it into a conversation where everybody chooses to collaborate with each other to find the overall best solution. The only way this kind of collaboration can happen is when there is high alignment.

When there is low alignment, people will actually begin giving instructions to other teams to prevent collaboration from happening. They will cross their fingers that by simply throwing instructions over the fence we won’t end up in conflict and disaster due to the lack of alignment.

High Alignment Enables High Autonomy

In conclusion, high alignment is what opens the door for autonomy and collaboration. When teams are properly aligned, there is decent chance they will self-issue the same instructions in collaboration that you would have given them in isolation.

The end result may seem the same, but don’t be fooled, the difference is massive: you’re respecting their autonomy. Your teams will be highly engaged and highly motivated.

Why does understanding the the tight coupling between alignment and autonomy matter?

When you optimize for autonomy without addressing alignment, then you’re going to have neither autonomy and alignment.

Lack of autonomy isn’t the reason the Spotify Model failed at most companies. Increasing autonomy for individual teams, while not addressing alignment, means you’re actually going to reduce autonomy further and create even more silos. That’s why the Spotify model failed.

Restructuring teams is easy, addressing the fundamental alignment problems is infinitely harder. Without addressing alignment, the team structure won’t matter much.

Every team will make autonomous decisions without understanding how it affects others, thus diminishing each others autonomy even further.

Alignment = Providing (Enabling) Constraints

Silos are extremely common and are what happens when everybody will optimize for their own autonomy at the expense of the big picture due to lack of alignment.

The best thing you can do if you want your teams to make better choices is by limiting their options in a way that increasing their chances of making better choices.

This is exactly what makes alignment hard. We hate limiting choices and the immediate sting of saying no to things. The moment we limit choices, loss aversion kicks in, but it’s actually what’s necessary for high autonomy when many teams must collaborate together.

Limiting choices sounds extremely counter-intuitive, because we defined autonomy as the ability to self-direct and make choices, but constraints are actually the guard rails that make autonomy possible in the context of a multi-team environment where they need each other to succeed.

Alignment is about providing (enabling) constraints, like Vision, Strategy and Goals that intentionally limit the different options for teams so it becomes easier to operate in the same direction with the same intent.

Constraints are not rules, they don’t tell you what to do, but they enable you to make better decisions about the right course of action beyond the scope of the snow globe. Constraints are actually what makes collaboration possible, because if you don’t have constraints, then it becomes really difficult to make decisions.

Without clear (enabling) constraints, everybody will self-invent their own constraints from their limited team or department perspective to make the right decisions possible. And because everyone has their own constraints and agenda, they will be serving the insular perspective of their little snow globe and diminish each other’s autonomy.

Only when you have sufficient overlapping constraints does it becomes easier for teams to make collaborative choices in a way that serves the best interests of the company.

As a concrete example: providing a list of 100 things that must be delivered next quarter limits options, but it does so in a way that actually limits their chances of making better choices by hurting both alignment and autonomy.

If you have alignment problems, then your lack of autonomy is the least of your concerns. Fix alignment first. Alignment is what helps make autonomy possible when many different teams must collaborate together to succeed.

Don’t tell people what to do, but provide them with (enabling) constraints together with intent. That’s the best way to have high autonomy and alignment.

If you’re telling people what to do, then you can’t have high alignment, because you’re not providing (enabling) constraints. The moment the plan goes off the rails, everybody will struggle to align and you won’t have autonomy nor alignment.

Providing (enabling) constraints will hurt more right now so that you will have potentially less pain later. As long as we can’t accept the sting of guaranteed early loss by providing (enabling) constraints, we will guarantee late loss by working in silos and autonomy won’t be able to shine.

The best way of explaining this is by talking about a bird everyone knows: the Peacock.

👋 Digging the content? Let’s talk Product☕. I’m available for Fractional Product Management, Workshops, Coaching, and Speaking.

Here’s a picture I made of a Peacock on a cannon in Madrid:

Look at the magnificent creature and ponder the following question:

Why do male Peacocks have a massive and extravagantly colorful tail?

From an evolutionary perspective the Peacock’s tail doesn’t make sense:

• The tail is like a giant neon sign that says ‘Please eat me, I’m pretty’.

• The sheer size and weight ruins their mobility. The tail makes up to 60% of the bird’s total body length and makes them clumsy, slow to take off and terrible at flying away from danger.

• It drains energy. Growing and renewing all those massive, complex and beautiful feathers every single year takes energy, which could be better used for other purposes, like having more muscles, superior eyesight or being better able to fight diseases.

From a purely evolutionary perspective the tail already puzzled Darwin in the 19th century. Natural selection is supposed to favor traits that make organisms more fit, not less fit.

Here’s Darwin writing about the puzzling nature of the Peacock’s tail in a letter to Asa Gray on the 3rd of April 1860:

“The sight of a feather in a peacock’s tail, whenever I gaze at it, makes me sick!” - Darwin in letter to Asa Gray

The Peacock’s tail was an anomaly that made Darwin sick.

Despite all these completely valid arguments, a Peacock’s tail still evolved from evolutionary pressures that provided a benefit from having one. If the benefit isn’t increasing the fitness of the Peacock, then why do they still have such a tail?

Why Do Peacocks Have Self-Handicapping Tails?

In 1975, the Biologist Amotz Zahavi was wondering exactly these same questions: the Peacock’s tail doesn’t make any sense, yet the peacock still has one.

What is the evolutionary reason behind the self-handicapping Peacock’s tail?

Zahavi proposed the following reason which he called the Handicap Principle:

“Flashy ornaments, such as the proverbial peacock’s tail, evolved precisely because they are costly — to signal the genetic and phenotypic quality of the bearer. The handicap principle maintains that the costly signal will be honest because a weaker individual would pay a higher cost to carry the same handicap than a stronger animal. - Nature Obituary of Amotz Zahavi”

The most important part is in bold.

Zahavi reasoned that the only reason a Peacock feather works as a signal is because: “In order to be effective, signals have to be reliable; in order to be reliable, signals have to be costly.”

So how does this relate to the age of AI? Well, let’s talk about LinkedIn before the age of AI.

Let’s say you’re doom scrolling through LinkedIn before the age of AI. Every post you see, you can be pretty sure someone invested time to write that post. You could consider it a costly signal as writing a good post isn’t easy.

Also, it’s easy to distinguish the good and the bad posts, because you can easily see when someone didn’t put in any effort. We could visualize our LinkedIn timeline as follows:

The only post you’re going to read is the one with the Peacock feather, because it seems interesting. You breeze past all the crap.

If someone wrote a lengthy and well-reasoned post, you pretty much knew it was written by them and took considerable time and effort. It might still turn out to be rubbish and uninteresting, but there’s a good chance it will be good.

The signal of decent prose is reliable and costly, just like the Peacock feather.

Flash forward to the age of AI, and when you see a lengthy, well-reasoned post, it could actually be created in 2 seconds with AI. Our AI sloppified timeline looks as follows:

We scroll and see Peacock’s tail, but upon closer inspection it turns out to be total crap. The Peacock’s tail no longer is a costly and reliable signal that says something about the bearer.

Luckily, most posts on LinkedIn are shit, even with AI, but I’ve noticed that I no longer attach the same value to the work of other humans, because it could literally be generated in a few seconds with AI.

And as a result, I trust what they write much less. I can no longer trust upon the fact that it was a costly signal where they spent real effort, or blood, sweat and tears.

Before AI, Writing a single post was even costly. Writing a good post on a regular basis was almost insanity, the majority of writers are incapable of doing that. I remember on Medium, that the number of writers that wrote more than 3 posts was less than 1%. Today, I’m pretty sure that number no longer holds true.

Writing is no longer something costly that takes lots of time. If you see something, you can be no longer confident that someone invested lots of thinking time to write a piece. It’s no longer a reliable and costly signal.

Hence, we can no longer trust the Peacock’s tail of writers. The reliability and costliness of the signal is lost.

Mimetic Signal: The AI-Driven Erosion of Trust

There always was lots of noise. In the Great Moon Hoax of 1835, the Sun in New York published a series of articles about the alien lifeforms they discovered on the Moon.

The moon was populated with man-bats and highly similar to earth. These fake articles were never retracted, but the Sun did admit the articles were fabricated one month after publishing.

However, the problem is that in the past noise was much easier to distinguish from signal. We’re being flooded mimetic signal: noise that’s actively crafted to resemble signal despite not holding any real informational value.

In short, it’s great that everyone can Peacock on LinkedIn now through the illusion of well-written posts, but we’ve lost something important:

Trust.

We can no longer trust the Peacock’s tail, because it no longer is a costly and reliable indicator of fitness. I don’t trust what I read on LinkedIn anymore, because I can’t trust it was written by a human who invested lots of time to make it happen.

I’m no longer reading much online and I’m finding myself reading more and more books, because I just can’t be bothered to wade through all the crap with fake Peacock’s feathers sticking out.

If you find someone who writes high-quality posts, share their work and subscribe to them, because they’re saving you lots of time by preventing doom scrolling through mimetic signal.

I’m highly in favor of everyone writing. I review articles and help fellow writers every week.

But throwing slop over the fence isn’t writing. All that does is make everything worse for everyone.

The only short-term solution I see is to curate your own sources you can trust, but if I figure out something else, I’ll promise to write about it.

Special thanks to for giving feedback on this piece to make it stronger.

Your experience is irrelevant.

Nobody cares about your experience.

This may sound extremely harsh, but it’s the truth. The sooner you realize this, the better.

Nobody wants to hear your whole life story and all the things you did. Yada yada yada blah blah blah. The interview is not about you, but how you’re the perfect fit for the job.

👋 Digging the content? Let’s talk Product☕. I’m available for Fractional Product Management, Workshops, Coaching, and Speaking.

What they want to hear instead is this:

Your relevant experience is relevant and they will only remember your relevant experience if you wrap it in an interesting story. If they don’t remember, it doesn’t matter how relevant it is.

This might seem like a subtle and semantical difference, but it’s not.

Interviewing people frequently feels like you’re digging for a $20 dollar bill in a dorm room couch, meanwhile all you’re finding is ramen noodle dust and pizza crumbs.

Those resumes and interviews are the worst. Even though you’re working super hard to try to get the best out of the candidate and make them shine, they won’t play ball.

You never get any of the answers you really wanted, apart from droning, rehearsed answers that don’t tell you anything about their ability to do the job.

By the end of the interview you’re exhausted and happy it’s over.

I’m intentionally painting this frustration picture so you can experience what it’s like and why it doesn’t work. I want you to shine and succeed. What is relevant experience you might be wondering? That is highly dependent on your experience and the job you are applying to.

If you’re applying to a Product Manager job with lots of Product Management experience then relevant experience is easy. If you’re applying to a job as a Product Manager without experience as a Product Manager, then you have the much tougher job of framing apparently obscure experience as obviously highly relevant.

Let’s stop making jabs at interviewees, because interviewers are frequently even worse.

Interviewers Are Unreliable Narrators

One of the primary reasons this happens, is actually not the fault of the interviewee but of the interviewer. You should always treat the interviewer as an unreliable narrator:

• What they ask for, is not necessarily what they want.

• What the they want is not necessarily what they need.

• What they need, is not necessarily what they want.

Frequently the ‘Asked’ Experience is a classic case of unintended “Liar liar pants on fire”.

Watch out if you’ve diligently prepared your interview, as it might be a trap.

All the experience you think they care about is not what they care about at all. Telling them the experience you believe to be relevant will actually be a total waste of their time.

I want to stress, treating them as an unreliable narrator doesn’t mean you should second-guess or challenge them like they don’t know what they want. That’s a guaranteed way to never get hired, as nobody wants to work with a smart-ass who can’t read the room.

But you should get them to paraphrase what kind of person they’re looking to hire and treat every question as a clue to what kind of candidate they’re really looking for.

Keep your eyes open for clues of congruence, as that will help you to better position yourself and give the answers they actually care about.

Spot Clues of Congruence

The best-case scenario is that they’re congruent. The kind of questions the job interviewers ask match the expectations set in the job description.

This congruence is unfortunately rare and you should do your best to maximize the opportunity, because all the stars are aligned and it’s now your opportunity to shine!

The worst-case scenario is that the interviewer’s narrative is completely incongruent. In that case, you should trust what the different interviewers are telling you over whatever is written down in the vacancy and think quick on your feet.

Why does this happen?

Whatever is in the vacancy, might be written by someone in HR, who doesn’t have the faintest clue about the actual job. In fact, sometimes the vacancy hasn’t been updated in years. These are all red flags by the way, but this is more common than you’d think.

Even if the vacancy is accurate, whoever is interviewing might not even know it by heart. How do you deal with this unreliable narrator situation?

When you write your resume, but also when you answer questions, remember why you’re here.

You’re not here to tell your experience. You’re not here to tell your whole life story or all the things you did. You want to tell a story that helps the interviewer answer the following simple question:

"Do I Trust You’re Capable of Doing the Job?”?

The key word here being: building trust.

You don’t build trust only by giving all the right textbook answers. Nobody wants to work with a drone. You build trust by being a real, interesting and interested human being.

The moment when the interview is over, you want the interviewer to remember you, not just for what you’re capable of but for who you are.

What makes you different? Sometimes the one tiny thing you’ve told them makes you stand out from everybody else becomes way more important than being the best.

Different is frequently better than best.

When you write your resume, but also when you answer questions, always keep the following model in mind:

Your experience can be split in three parts, which in essence all boil down to ‘Trust Signaling’ to answer the following question: “Do I Trust You’re Capable of Doing the Job?”

1. Signal. Anything that increases Trust you’re capable of doing the job.

2. Noise. Anything that distracts or might drown out the Trust of you’re capable of doing the job.

3. Doubt. Anything that decreases the Trust that you’re capable of doing the job.

Go through your resume, and mark every line on there either as Signal, Doubt or Trust. Remove anything that isn’t Signal.

Apply ‘Experience Dilation’ for the parts that provide Signal. If something is especially relevant, stretch it, but of course don’t do it such an extent it turns into Noise or Doubt.

Remove duplicate Signal. If you’ve done the same thing at three jobs, I know you’re capable of it after the first job. Don’t provide the same level of detail for all three, because that’s noise.

Think hard now that you’re reading this post: what will you remember from what I’ve written?

The only thing you will remember is the story that played out in your mind.

The better I do my job, the more this piece felt like a story in your brain that evoked emotions. You might even disagree with some things, which is all fine.

You might remember what you agreed with, if I did a good job of wrapping it in an emotional story that resonated with you.

You should do the same when you’re interviewing: Story-Driven Interviewing.

Story-Driven Interviewing: Serving Your Relevant Experience On a Silver Platter

Tell a story, with concrete details and emotions. You can’t fake that and it builds trust more than anything else. People are connected through stories and story-telling: we remember stories and emotions. It’s the thing that made religion big.

We struggle with remembering facts unless they’re part of a larger narrative. Facts without a story are boring. Our brains have been TikTokked. You must break the pattern and invite curiosity before people will listen.

In short: nobody cares about your experience. Get over it.

You’re a human being and you’re different. Different is better than just better.

Stop sinking yourself by drowning interviewers with all your experience. Tell a story that builds trust that you’re capable of doing the job.

It’s incredibly hard, but the alternative is that when you leave the interviewing room is that nobody will remember you.

Your experience is irrelevant.

Only your relevant experience is relevant, and it’s only relevant if they remember it.

People only remember the relevant experience you served to them on a silver platter by telling an emotional story only you could tell.

What’s the relevant story only you can tell? That’s what you should be thinking about.

👋 Digging the content? Let’s talk Product☕. I’m available for Fractional Product Management, Workshops, Coaching, and Speaking.

To quickly recap part I:

• If you want leverage all the potential of your employees, then they should enjoy more Trust than their level of Competence.

• Most organizations Trustcap their employees, which means employees get less Trust than their level of Competence. Trustcapping results in reduced Competence and reduced Agency - the ability to influence results with your decisions and actions - and may even cause people to begin under-performing.

• When you’re Trustcapping your employees, your organization is like a dinosaur waiting for the meteor to strike in the age of AI. If your employees can’t exercise the Competence they already have without AI, then increasing their Competence with AI won’t make a difference.

Upskilling your employees with AI when you’re Trustcapping them is like trying to put rocket fuel in a rusty old land mower: it won’t change a damn thing.

If you’re in a situation of Trustcapping with low Agency and the Cannibalization of Competence going on, what should you be doing instead of heavily investing in AI?

Let’s answer this question by examining what kind of organizations will benefit from AI.

What Kind of Organizations Will Benefit From AI?

Let’s talk about what kind of organizations will benefit the most using a real-world example from my personal experience.

Imagine you join a company where the level of Trust is significantly greater than your level Competence. Let’s assume you’re extremely inexperienced and low in Competence, but you’re joining a start-up that already possesses a high Trust environment.

That’s exactly what happened to me when I landed my first job as a Product Manager.

If you join a company where you enjoy a much higher level of Trust than your Competence then you’re in a Sink or Swim situation.

Just like you shouldn’t throw a kid in a swimming pool when they can’t swim, it’s not the best idea to put a new employee in a sink or swim situation.

I was working overtime for many months and toiling away to grow my level of Competence. Because I was trusted to make many decisions I was incapable of making, I was accumulating many mistakes resulting in diminished Trust. I was not only Swimming, I was also Sinking. I was struggling and I believed I didn’t do a good job.

It was the only job I had where I wondered why they didn’t fire me, as I really was in over my head.

What would happen when we introduce AI in this environment with a high amount of Trust? Let’s wave the AI magic wand we also used in part I again.

The same caveats apply: AI isn’t good enough (yet) to massively increase our level of Competence and it’s impossible to instantly increase Competence because that will be something gradual. It’s still a valuable thought experiment to show what will happen.

Let’s explore the ramifications of instantly leveling up Competence with AI using our trusty old friend the Slipstream Model of Trust once again:

Life would be great! I would no longer be anxious and miserable, and I would enter the Slipstream of Trust, where I enjoy slightly more trust than I deserve based on my level of competence.

The Slipstream of Trust is where you can safely grow Competence and Agency. You have enough freedom to experiment grow and learn, but not so much freedom that it feels like you’re nearly driving off a cliff.

We can explain the Slipstream of Trust s using an example from the world of racing. A racer who is in the slipstream of another driver will move faster. Once you become to too far removed from the slipstream you will encounter dirty air that increases drag and will make you move slower.

The Slipstream of Trust is the place where you want to be. It’s the perfect area of Proportional Trust: Enough freedom to make decisions and not too so much freedom that you’re at risk of majorly screwing things up.

Let’s say you’re convinced by my argument and that Trust is the key factor we should focus on first. Imagine you’re in an environment where your employees are being Trustcapped.

To address the issue of high Trustcapping, you decide to drop AI for now and splurge your employees with Trust. You suddenly believe that only if we wrap our employees tightly with a snug little blanket of Trust, then we can be safe from the impending AI meteor.

That’s not the solution either, allow me to explain why.

Splurging With Trust is Dangerous

Would you let a 18 month year old cross the road who just learned how to walk?

1. Competence: can they make the right decisions regarding crossing the street? HELL NO! A child of 18 months old is close to wholly incompetent when it comes to crossing roads. They are unable to make the decision whether it’s safe to cross and even if they could make a sound decision, since they just learned how to walk, there’s a good chance they’ll trip in the middle of the street as they’re crossing.

2. Trust: would I allow them to make the decision of crossing the road by themselves? Absolutely not - PERMISSION DENIED.

So what I’m going to do instead of trusting them to cross the road on their own? I’m going to hold their hands and cross the street together. I’m giving the 18 month year old Proportional Trust: a level of Trust that is appropriate for their level of Competence.

I’m basically holding their hand and creating an environment of Proportional Trust by riding the Slipstream of Trust together.

It’s absolutely crucial that employees receive Proportional Trust. Both too much Trust and too little Trust for their level of Competence hurt Agency.

Ideally you enjoy slightly more Trust than you deserve based on your level of Competence, because that’s the ideal environment for safely growing your Agency.

The bandwidth of the Slipstream of Trust is mostly determined by two things:

1. Acceptable risk levels. How much risk is acceptable? A start-up vs. an established bank with millions of customers has a totally different risk profile.

2. Psychological Safety. How safe do people feel to take risks and make mistakes without fear of repercussions?

The lower the risk, the higher the acceptable risk, and the higher the psychological safety, the wider your Slipstream of Trust can be.

Trust Is More Important Than AI

If you want to know whether it makes sense to upskill with AI, it’s far more important to map your current situation on the model below, because depending on where you are, AI won’t change a damn thing.

Let me explain the different zones in the model:

• AI Sweet Spot. Employees with high Agency: high Competence, high Trust and high Psychological Safety will benefit the most from AI. They know what they’re doing and they know the risks they’re taking. This is the place you want to be if you want to get the most value out of AI.

• AI Adoption Zone. When your employees enjoy mid or slightly higher Agency and they’re not Trustcapped, you should adopt AI.

• AI Caution Zone. When your employees have low to mid Agency, and they receive an appropriate level of Trust because they’re not Trustcapped, it makes sense to adopt AI, but you should proceed with caution. Make sure they work together with more senior people and ride the Slipstream of Trust, as they’re potentially juggling chainsaws and AI does not have the judgement yet to prevent this from happening.

• Fix Trust First. If your employees are being Trustcapped and they don’t have High Agency, then the ROI of increasing Agency by improving Trust and Psychological Safety is far greater than adopting AI. In fact, if you adopt AI too soon, it might even decrease the level of Agency. Increasing Competence with AI when they’re already being Trustcapped is a recipe for frustration and even further diminished Agency.
  

In a nutshell:

• If you’re below the middle line, unless your employees have high Agency, you shouldn’t be leveling up your employees with AI, you should work to increase Trust and Psychological Safety so that you can get all their current competence without AI on the road.

• If you’re above the line, Trustcapping isn’t a problem anymore, but you should create the conditions for Agency to grow so you can benefit even more from your existing expertise with AI.

Once you’ve addressed the Trustcapping, only then should you worry about gradually increasing Competence even further with AI.

Most organizations are in a situation where they are Trustcapping their employees. All implementing AI will do, is only serve to frustrate them even further and make them appear as even more incompetent.

If you want to upskill with AI, the best area to be is or near the Slipstream of Trust - where you enjoy slightly more Trust than your level of Competence. The bandwidth of the Slipstream is determined by the acceptable level of Risk and the level of Psychological Safety.

When you’re in the Slipstream of Trust: as you gain more Competence, you will get more Trust and as you gain more Trust you can gain more Competence, which ultimately will allow to develop the high Agency environments that will benefit the most from AI.

I want to stress, we need inexperienced people with low Agency more than ever. Once those low Agency employees reach high Agency they will be able to do things with AI that your current best employees will never be able to do.

Most Organizations Are Black Holes For Employee Brilliance

Most organizations are black holes for their employees — devouring brilliance and leaking frustration - because they prevent them from making the right decisions through Trustcapping.

According to Gallup in 2025, roughly 21% of employees is engaged at work, which means 79% is not engaged or even actively disengaged. ‘Not Engaged’ is an euphemism for people that are ‘Checked Out’ They don’t really care what happens in your organization.

There is a silver lining and the whole situation regarding Engagement and Competence isn’t as depressing as I’ve portrayed: The best teams rarely have the best individuals.

Read that sentence again and let it sink in.

I’ve even experienced the opposite: the worst teams I’ve worked with had the most competent people I’ve ever worked with.

The best teams I worked with weren’t packed with geniuses or industry veterans.

Companies don’t need better individuals, they need better teams with more Agency.

High Trust organizations with high Competence and high Psychological Safety will benefit the most from AI, because those are the only companies where employees can exercise their Agency to get the most out of AI.

If your teams don’t already have Agency then adding AI won’t matter much. Your Competence is already capped without AI. There is a huge opportunity for many companies to increase Agency, Competence and Trust through riding the Slipstream of Trust.

That’s what we should be working on, as only then we can truly reap the benefits AI promises to offer.

Special thanks to , Ujjwal Sinha, Tanner Wortham, Koen Muurling for their feedback.

That’s how I would describe the current age of AI: everybody has Fear Of Missing Out (FOMO) and jumps at any opportunity to use AI.

Even when it makes no sense at all to use AI.

👋 Digging the content? Let’s talk Product☕. I’m available for Fractional Product Management, Workshops, Coaching, and Speaking.

I get the hysteria. I really do. I’m also excited about AI and experiment with it every day.

Every company and every individual wants to make sure they don’t miss the AI wave as it passes by.

However we must watch out that we don’t develop AI tunnel vision. AI isn’t the only thing that matters in your organization.

AI FOMO is the very reason I believe most organizations will be like dinosaurs waiting for the meteor to strike: completely unprepared for the age of AI.

The fact they believe their AI expertise is THE problem is what will guarantee their demise once the meteor hits.

Yes AI expertise matters, but it’s not nearly enough. It’s not a magic wand that changes everything with a single wave.

Something else is going to become way more important and it has NOTHING to do with AI.

What should we do to prevent being hit by the AI meteor? Instead of asking yourself the question:

“How can our organization better make use of AI?”

You should be asking yourselves the much more interesting and useful question:

“What kind of organizations will benefit the most from AI?”

When you answer this last question, you will understand why for most organizations upskilling their AI expertise won’t make a big difference. It may even make their existing situation worse.

Let’s answer the last question by first exploring the kind of organizations that won’t benefit from AI.

What Kind of Organizations Won’t Benefit From AI?

"I don't trust any of you", the CTO blurted out.

The room fell silent. All eyes were darting around the room, looking at each other in disbelief. I was sitting in a meeting room with ten competent Product Managers working at a local department of a multi-billion-dollar organization.

The surprising answer of the CTO was a response to a question I had asked: "Why don't you let us Product Managers together decide on how we do roadmapping?”

Every single person in that room was more competent than the CTO in the realm of roadmapping. But because they didn’t trust us, our expertise didn’t matter.

We can easily visualize the above situation using the Slipstream of Trust model, but let me first briefly explain the model.

The Slipstream Model of Trust in the Age of AI

We can visualize the relationship between Competence and Trust as follows using the Slipstream Model of Trust.

X-axis - Competence: your ability to make the right decisions: can you make the right decisions?

Y-axis - Trust: your ability to call the shots: are you allowed to make decisions?

Why Competence and Trust as the two dimensions? Well, the the higher your Trust and Competence, the more Agency you can have.

Agency is defined as:

“The capacity to decide and act intentionally to produce desired results.”

The better you’re capable of making the right decisions (Competence) and the more degrees of freedom you have to make decisions (Trust), the more Agency you have.

The more Agency you have, the better you can make decisions and act intentionally to produce superior results.

What’s the purpose of the straight line running right in the middle between Competence and Trust?

It’s pretty simple:

• Above the line: you have more Trust than you deserve based on your level of Competence.

• Below the line: you experience less Trust than you deserve based on your level of Competence.

There is a bi-directional relationship between Trust and Competence: Trust enables the growth of Competence and Competence enables the growth of Trust.

The opposite is also true: Distrust cannibalizes Competence and Incompetence creates even more distrust.

Above the line you enjoy Agency and the potential growth of Agency. Below the line you’re actively undermining and Trustcapping Agency.

Trustcapping Agency: The Cannibalization of Competence

When you’re below the line, it’s difficult to grow Competence and Agency, because you’re being Trustcapped.

Trustcapping limits the growth of Competence and may even result in Distrust, which then further works to diminish your level of Competence.

Trustcapping employees is extremely common, especially as organizations grow in size. Have you ever been in a situation where you knew the right thing to do, but you were not allowed to do it? Congratulations you’ve been Trustcapped.

Here are some extremely common examples of Trustcapping:

• Launch date is set without involving any of the teams responsible for delivering on said date.

• Silowork. Teams work in silos because they trust their own area of expertise more than the expertise of others. Silos are a highly effective way to Trustcap employees.

• Every team must follow the same process and way of working.

• The teams are forced to work with Scrum or an ineffective Scaling Framework like SAFe.

• Developers are not allowed to talk to customers and/or employees are not allowed to talk to developers.

• Managers don’t give the information teams need, because they are scared of losing power and control.

• Excessive approvals before doing anything.

• Asking a consultant to advise you how to fix your organization and they tell you everything you already know, but now you listen because you’re paying a lot of money to them.

We’ve all been in these kind of situations where we knew the right thing to do, but we lacked the Agency to make it happen. Even if it was something ridiculously simple e.g. like getting a license for a sofware product that will unblock your whole team that’s waiting for months.

Why does it matter to understand if you’re being Trustcapped or not?

In the Age of AI, increasing Agency will become more important than ever. Trustcapping your employees means you won’t be able to reap the benefits of AI because Trustcapping Agency results in the Cannibalization of Competence.

We can explain the Cannibalization of Competence by visualizing the story I told you about the CTO who said they didn’t trust us. We were in an environment of heavy Trustcapping, which resulted in an environment of low Agency, where we were not able to make decisions and take the right course of action.

The end result was that we were burning lots of money with little value to show for. We can visualize our frustrating “I don’t trust any of you” predicament as follows:

We’re experiencing the Drag of Distrust and our Agency was being Trustcapped: We could make the right decisions, but we were not trusted to make the right decisions. When you’re not making the right decisions you could be making due to lack of Trust, you’re actively Cannibalizing your existing level of Competence.

The Cannibalization of Competence happens when you know the right thing to do, but you’re not allowed to do it.

As a result of the low Trust environment, you will struggle and be perceived as less Competent. As your Competence drops, Trust will drop even further, resulting in even more drag and frustration.

The Cannibalization of Competence is far more common than you’d think, especially at larger companies.

The Cannibalization of Competence is extremely visible when you’re a Product Manager. The biggest challenge that many Product Managers face is NOT not knowing what to do, but convincing others that it’s the thing we should be doing because they lack the Agency to do their job.

How does the Cannibalization of Competence relate to AI?

The Cannibalization of Competence + AI

Now let’s add AI to the mix: Imagine I have a magic wand that I can wave to implement an AI that instantly levels up my Competence to the desired range.

The AI magic wand is purely a thought experiment we can run to assess the impact of instantly increasing Competence. The AI magic wand doesn’t exist for the following reasons:

1. AI isn’t good enough (yet) to massively increase our level of Competence.

2. Increasing Competence is something gradual, not something instant.

You might be thinking, if it’s impossible to do this with AI, why does this thought experiment even matter?

Even with an impossible perfect AI as envisioned in this thought experiment we can explore the repercussions of being able to instantly increase Competence.

Okay, let’s wave our magic wand and see what happens:

All that’s going to happen is that you’re going to experience EVEN MORE drag and frustration because you’re still being Trustcapped and not trusted to make the right decisions. Adding AI won’t magically work to increase the level of Trust you enjoy.

When you’re experiencing the Cannibalization of Competence you already had more than enough Competence to do a better job than you’re currently doing, so leveling up your Competence with AI is completely irrelevant.

Any competence you might be gaining will immediately be cannibalized by the lack of Trust. When you’re Trustcapping Agency, there is a natural tendency for the further reduction of Agency through the ongoing Cannibalization of Competence.

The Cannibalization of Competence: Organizations With Low Agency Will Benefit the Least From AI

When you’re in an environment of low trust where your employees are being Trustcapped then adding AI isn’t the flex you think it is. In fact, it will only make things worse and frustrate your employees.

If your employees don’t have Agency without AI, then all you’re trying to do is put rocket fuel in a rusty, old land mower: it won’t change a damn thing.

Most organizations are trying to put rocket fuel in rusty, old land mowers by dousing employees with AI trainings and AI tools.

If you’re currently Trustcapping your employees and limiting Agency, you don’t need more AI, you need more Trust and higher Agency to prevent the Cannibalization of Competence.

In summary:

If your employees can’t exercise their Agency without AI, they won’t be able to exercise Agency with AI.

If you only focus on leveling up your AI when your employees have limited Agency, then you’re simply waiting for the AI meteor to strike and you won’t survive.

When AI makes your people more Competent, it’s crucial they have sufficient Agency to exercise their newly gained Competence.

The unfortunate truth is that most employees are being Trustcapped and have constricted Agency. Companies with Trustcapping won’t reap the benefits of AI, because AI requires employees to have more Agency not less.

If you’re in a situation of Trustcapping with low Agency and the Cannibalization of Competence is going on, what you should you be doing?

Stay tuned for part II that I will publish next week.

We will explore what kind of organizations will benefit the most from AI and what we must do to prevent the Cannibalization of Competence and increase Agency.

Special thanks to , Eman Mifsud, , , , , William Richards, Koen Muurling, , and for their feedback.

One of the most surprising things I’ve learned over the years, is that usually the best way of helping them is by not giving them what they want.

Sounds surprising and counter-intuitive right?

Allow me to explain.

That something they want help with rarely is the real thing they need help with.

When companies approach me for help, I frequently experience the following internal conflict:

1. Give them what they want. When I give them what they want, they’ll be happy and there’s a good chance they want to work together. But it’s pretty much guaranteed it won’t solve their problems. I can charge money doing something that, at best, offers a surface-level solution that will make things both better and worse in ways I can’t even foresee.

2. Don’t give them what they want. The risk of not giving them what they want, is that they won’t hire you and you won’t have a shot at helping them fix their problems.

What would you do? Do you pick option 1 or option 2?

I prefer option 2, because I want to make a difference. I want to emphasize option 2 is much easier if you don’t have financial problems and don’t have benched employees who must be billable.

Integrity is easy when conditions are easy.

But this is not an article about integrity, let’s answer the following question: Why do companies rarely know the real problems they need help with?

The Symptoms Are NOT The Problem

The main reason why I’m approached by companies is because they have a problem they’re unable to easily solve by themselves. That’s why they are looking for outside help.

The most common reason they’re unable to solve their problem, is because they don’t understand the actual problem they’re having. One of the telltale signs of this problem ignorance is that they come to you with a solution instead of a problem they’re trying to solve

Usually when companies reach out, they come to you with a solution, like:

1. Can you do an Agile maturity scan?

2. Can you assess the level of our Product Management maturity?

3. Can you help roll out the Product Operating model?

I usually then begin to ask questions along the lines of: what problem(s) are you trying to solve for? What challenges are you facing in your daily jobs? The answers you get are usually surface-level symptoms and NOT the real problems they’re having.

The symptoms are the tip of the iceberg, Let’s explain this using a simple example: let’s say you’re overweight and want to lose weight.

Being overweight is both a symptom and a problem. It could be a symptom of not exercising enough, or maybe it’s a symptom of your genetics. It’s also a problem. Maybe your knees hurt when walking, or you can’t walk the stairs without having to catch your breath. Maybe you can no longer fit in an economy class seat and need to buy more expensive tickets every time you travel.

Why does understanding the difference between symptoms and problems matter?

Your body is a complex system. There are no recipes to follow to resolve your problems.

If you make something better, something else will usually become worse. You don’t know exactly how it will pan out before you actually do it. Ozempic is a great example. The medication makes some things better and it will make other things worse. It’s all about making the right trade-offs.

The better you understand all your problems and symptoms, the better you can come up with a solution to fix them. Because your problem and symptoms are a complex web of interdependencies that all relate to each other.

Fix one thing, and you may break something else. This is why losing weight is so difficult, because we need to change our existing system with all its habits and behavior that produce the current status quo. Our habits and status quo are unique and almost flawlessly run on automatic pilot. The better we understand our current automatic pilot, the better we can resolve our current challenges.

The same logic applies for organizations. When you move up on your Agile or Product Management maturity model, you may actually end up making your problems worse. That’s because prickly complex problems can’t be linearized into a simple maturity ladder with a discrete set of levels.

It’s crucial to develop a solid understanding of your symptoms and problems before you can begin thinking about of the best way of improving your situation.

Where do you start? Enter the world of Force Mapping.

Force Mapping: A Tool For Fixing Systemic Organizational Issues

Force Mapping is a tool inspired and influenced by the magnificent work of on Dysfunction Mapping for Scrum Teams.

Force Mapping is a framework agnostic version of Dysfunction Mapping that you can use to tackle organizational challenges.

Force Mapping helps you to build a mental model of all the internal forces, problems and challenges you’re facing so that you can figure out the best way of addressing them.

How do you do that? There are 8 steps to producing a Force Map.

Step 1: Formulate a Big Hairy Audacious Problem (BHAP)

Force Mapping begins with a BHAP: Big Hairy Audacious Problem. What’s the single biggest problem your company is currently facing?

This is the lens through which you’re going to view all the challenges, symptoms, problems and dysfunctions that are present in your organization.

The important thing to keep in mind: there are also things are going well. That’s why it’s called Force Mapping. There are good and bad forces at play. You want to discover the positive and negative forces that shape the current status quo.

The reason why it’s important to start with a BHAP is because you can’t fix everything at once. It’s not wise to quit smoking, lose weight and stop your gambling addiction all at the same time.

Force Mapping starts with a BHAP: what’s the single most important problem you’d like to fix?

Some examples of (anonymized) BHAP’s I’ve used in the past:

• Our teams are struggling to deliver. What’s slowing us down or making us less effective as a team?

• We have too much firefighting. What can we do to reduce firefighting and create a less stressful environment?

• We’re shipping lots of features nobody uses. What’s preventing us from delivering features that create value?

• How you frame the BHAP is the lens through which you view your existing organizational system. It has a big impact on the kind of answers the Force Mapping exercise will produce, therefore you should consider it carefully.

Some different flavors you can consider for a Force Mapping exercise:

• Cross-functional Force Mapping Workshop. You produce a Force Map together with leaders and team members.

• Team-level vs. Management-level Force Mapping Workshop Let teams(s) produce a Force Map and let managers produce a separate one. Where is the overlap? Where do both have blind spots? This can be incredibly informative.

• Pure team-level Force Mapping Workshop. Let one or more team(s) produce a Force Map together. Then use this team-level Force Map to engage with leaders.

If you only invite team members, you will get insight into the lower-level team challenges but maybe not the higher-level organizational dynamics that produce those team-level dysfunctions. It’s not necessary to include everyone in one or more teams, simply use delegates that adequately represent the different skillsets and perspectives.

Let’s use this as an example BHAP for now to better explain how a Force Mapping exercise might work:

Congratulations, you’ve completed Step 1. Now let’s go to the next step.

Step 2: List All Your Symptoms and Problems

When you have everyone in a room, list all all the symptoms and problems that are related to your BHAP. What symptoms or problems do we observe that influence our BHAP?

The key thing to stress here, we’re interested in the relationships. It doesn’t matter if it’s a symptom or a problem, or something else.

A problem can be a symptom, a symptom can be a problem. The categories used in Force Mapping are there to make sure we cover all our bases. It’s not about nailing the buckets and make sure everything is in the right category.

Ultimately, drawing all the relationships and interdependencies are what matters the most. Not whether we’ve placed them in the perfect (right) bucket.

Here is a simple example of what the second step might look like:

Make sure you don’t waste your time discussing whether something is a problem or a symptom, unless it results in adding something that’s missing which is not yet on the Force Map.

The point is to discover how all the different factors relate to each other to produce the BHAP. Not whether all the factors are in the right place.

Step 3: List All the Behaviors

We do things and don’t do things that produce the problems and symptoms. What are those things we do and don’t do (Behaviors)?

When everything is always considered urgent, this means we don’t have the time to do things the right way. When we don’t take the time to do things the right way, this will result in tech debt and production issues. Tech debt increases the number of production issues, and the elevated number of production issues ensures we don’t take the time to do things the right way.

Step 4: List All the Forces

Behaviors don’t exist in isolation. What are the Organizational Forces that are at play that shape our current behaviors?

You may decide to move some of the existing Problem or Symptoms to the Forces bucket, if you feel it fits better. But as I said, don’t have huge discussions about it, it doesn’t really matter, as long as the relationships and interactions are accurate.

The key reason why it’s important to think about the Forces is because the things you’re observing may be shaped by something else you’re not taking into account.

We’re going from the tip of the iceberg (symptoms and problems) to the bottom to discover the systemic issues which are more difficult to observe and spot.

Step 5: Explore the Status Quo

Organizational Forces don’t exist in isolation. What in the Status Quo of our organization shapes the forces we’re observing?

These should are the higher level aspects of how we’ve decided to organize ourselves.

Some examples of the status quo as related to our BHAP:

1. There is no clear company strategy or vision. What the company calls the strategy isn’t a real strategy.

2. The business decides the roadmap - resulting in too much work being pushed to the teams and technical debt not getting a priority

Step 6: Unravel the Mental Models

Our current Status Quo is shaped by beliefs and mental models. Unless we talk about the beliefs and mental models that underpin how we’ve chosen to organize ourselves, we can’t talk resolve the issues we’re facing in a systemic way.

The best way of unraveling mental models is by including an outsider or a newcomer who is still an outsider. Here are some limiting beliefs / mental models that affect the kind of solutions we come up to tackle our BHAP:

• Fixing technical debt slows us down.

• Estimates are supposed to be accurate, hence PUSHING work to teams is a sensible approach.

• We’re scared of making tough choices and trade-offs.

Step 7: Draw Relationships and Interactions Together

How do all the different factors on your Force Map affect each other? The most important thing of this whole exercise is to:

1. Create a shared mental model and shared understanding of the current challenges your organization is facing.

2. By drawing the relationships and interactions, you might realize something is missing, or something is redundant. Use this understanding to update the Force Map.

3. The finalized map can be used to decide on actions and experiments.

Step 8: Decide On Concrete Experiments (Actions) together

These are the kind of questions you should be asking and discussing together:

• What are the choke points on our Force Map that have the biggest influence on our BHAP?

• If we fix that one thing, will it potentially make something else worse?

• What elements on our Force Map should we tackle to resolve our BHAP?

• What are the experiments we will try to influence our BHAP?

• How will we know whether the change we’ve implemented has been a success?

Once you have a Force Map, you can repeat the same exercise and revisit it to see if you’ve actually fixed your problems and not made things worse.

Here is an example of what a finalized Force Map can look like together with all the relationships, interactions and action points:

As you can see, you now have a much better idea of what’s going on within the organization instead of potentially being distracted by surface-level symptoms that are impossible to resolve on their own.

Force Mapping: Stop Talking Symptoms and Start Solving Problems

Force Mapping helps organizations and teams to stop talking about symptoms and start talking about the real problems they’re facing.

Once you have a Force Map, then you can use use that understanding to inform the next actions and experiments you will run.

Those actions and experiments will then inform your future understanding and use that information to update the Force Map and come up with future actions and experiments.

Remember, the map is not the territory but without a mental model of what’s really going in your organization you’re flying blind: it will be hard to make changes or run experiments.

Instead of jumping to solutions and conclusions, the next time you run into a prickly problem, try running a Force Mapping exercise to understand what’s really happening and explore different avenues of resolving your problems together.

Feel free to send me a message in case you want to run a Force Mapping workshop. I’m happy to help out!

It’s happened to me many times over in my career and it’s a sign of pure incompetence. Late descoping is a red flag, because those must-haves were never must-haves to begin with.

Descoping late in the project is bad, because you’re descoping at a point in time when it matters the least.

Everybody has already been burdened with the unnecessary scope. You waste huge amounts of time to deliver things you no longer need. All that unnecessary scope and complexity is still lurking in your codebase ready to drag you down.

👋 Digging the content? Let’s talk Product☕. I’m available for Fractional Product Management, Workshops, Coaching, and Speaking.

Amateurs descope late in the project. Professionals descope before it’s even necessary and rescope when they have more and better information at their disposal.

That may seem like a strong statement, but let me explain why.

Gall’s Law and the Folly of Late Descoping

Professionals who have suffered the wreckage of late descoping feel Gall’s law in their bones.

Gall’s Law:

“A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.”

Because of their scars of experience they can’t help but to aggressively descope early and add complexity gradually by taking into account reversibility and optionality.

You can only do this if your scope is rooted in solving a real-world problem, not a fixed functional scope decided up-front. If a stakeholder screams something is a must-have that doesn’t make it a must-have. There must be a real-world reason for it to matter.

You don’t build a complex system that works: you grow one. A working system evolves by making changes to a simple system that works.

Professionals know that excessive scope decided up-front can put your whole project at risk.

Set Internal Milestones That Focus On Early Disappointment

You should work in a way that fosters early disappointment and respect Gall’s law. The alternative, late disappointment, is extremely risky. Late disappointments is one of the biggest reasons why many projects fail.

The best and quickest projects show early and swift progress. I’ve been involved in many product rebuilds, and all of them that didn’t respect Gall’s law failed miserably.

But what if your stakeholders make everything a must-have? You’re not powerless and still have control over the early internal milestones. When your stakeholders don’t allow you to descope, you can still set internal development milestones where you do aggressively descope.

You can use the information from those internal milestones to rescope future must-have milestones they don’t want to budge on, before you run out of time.

Evolve your complex system gradually from a simple system that works. The key part is that it works.

Late scope cuts are scars of incompetence. Early scope cuts are a sign that you know what you’re doing. If it’s an option, you’re delaying important decisions to a point in time when you have a better understanding and more information.

Stop being a victim to late descoping, by doing early and gradual rescoping. Postpone what you can easily add later and delay decisions that greatly benefit from more information to the last responsible moment.

Don’t build a cathedral unless you know what makes your shed inadequate.

Once you know what makes your shed inadequate, you might no longer need a cathedral.

Dizzy yet?

👋 Digging the content? Let’s talk Product☕. I’m available for Fractional Product Management, Workshops, Coaching, and Speaking.

Yet all this labor is completely futile and unnecessary.

The fact that you believe this is an effective approach is the very reason you will never reach your goals.

If you want to understand why this approach doesn’t work, all we have to do talk about the fate of our trusty old rock-pushing friend Sisyphus.

Meet Sisyphus.

If the name rings a bell, you probably know the story. In case you don’t, here’s a summary:

“Sisyphus was condemned to an eternity of futile struggle by the gods for outwitting them twice. His punishment was to roll a massive boulder up a steep hill, but just as he nears the summit, the stone’s weight becomes unbearable and it rolls back. This repeats ad infinitum.”

TLDR: Being Sisyphus sucks. You don’t want to end up in a Sisyphean tragedy, yet it’s precisely what most companies do.

The same Sisyphean rock-pushing cycle is precisely what’s going on in most organizations. We’re wasting our time polishing spreadsheets, improving estimates and perfecting fancy capacity calculations, just to PUSH a big boulder up a hill that keeps rolling back.

If you’ve got a fancy spreadsheet for velocity forecasting to plan your work, then you’re just like Sisyphus: you’re PUSHING rocks up-hill and you will never reach the summit.

Pushing Work to Roadmaps

Most companies have a ‘PUSH’ system for their roadmaps. Especially the kind of laggard companies that still use SAFe.

How does a push system work? As follows:

Companies that PUSH work rely on fancy spreadsheet magic to more accurately predict capacity and forecast estimated effort. Because their whole PUSH system hinges on the fact that the two should match: your forecasted capacity should be more than your estimated effort.

The problem with PUSHING work is that it only works if you can accurately forecast your capacity AND your estimated effort. When you’re doing Complex work, you will encounter so many surprises that neither will be ever accurate.

Hence the PUSH system inevitably fails. Like Sisyphus as you’re approaching the summit and exhausted from pushing the big rock, you’ll suddenly realize you won’t make it and the rock rolls back.

Everybody is disappointed and as long we stay in the PUSH paradigm, the end result will always be the same, like with an Sisyphean tragedy: the boulder is too freaking big.

If PUSH works for your team, that’s great! I’m happy for you, as your life is much easier than for teams doing complex work.

You don’t need Agile, you don’t need Scrum, and you don’t need SAFe either. You can travel straight to ‘Go’, collect 200$ and put some fancy hotels on Waterfall street instead.

What should we do if you want to escape this Sisyphean Tragedy? It’s pretty simple: stop PUSHING, start PULLING.

Look how much capacity you’re using and control for that based on the real-world effort the work you’re trying to accomplish seems to take.

What matters isn’t how much capacity you THINK you have, or how accurate your estimate WILL be. What matters is how much capacity you have and how much work it really takes. That’s what a PULL system helps with.

You’re pulling more work as more capacity becomes available based on THE REALITY OF THE CAPACITY and the REALITY OF THE WORK.

Instead of pulling a big boulder, you’re adding tiny rocks to the boulder as you’re pulling based on your experience how much work you are able to pull off.

When you PULL instead of PUSH, you can escape the Sisyphean Tragedy.

Escape the Sisyphean Tragedy: Stop Guessing, Start Pulling

Forecasted capacity and estimates are unreliable narrators. You can’t place your trust in them when you’re doing complex work. That’s why PUSHING never works.

The problem is that all our estimates are guesses we make at a point in time we lack information to predict accurately. We can’t trust our estimates because they suffer from the Fog of Beforehand - what we can know before starting the work.

What we can’t and don’t know before starting the work is what makes our estimates often explode and balloon out of control. And because we’re polishing our estimates and forecasts to perfection, we actually introduce the Fog of Speculation - over-fitting our plans to make them even worse.

In short, PUSH is the road to misery. When you PUSH work, you create tension between two systemic flaws that are not created equal:

• Our inaccurate ability to predict our capacity

• Our wildly inaccurate ability to estimate work

When you understand this well, this brings us to the heart of our Sisyphean Tragedy: capacity micro-management and obsessing over planning poker is the wrong way of approaching planning and indicates a profound misunderstanding of the real problem you’re facing.

The real problem is that our estimates can’t be trusted. We simply don’t know what we can’t know. That’s where the biggest variance comes from. You can’t control for this by PUSHING work.

The rock of Sisyphus is always bigger than we guess and would like it to be.

Stop guessing. Don’t turn your planning and roadmaps in a paper victory exercise that hinges on your inability to forecast capacity and sculpt perfect estimates.

Let the reality of the work dictate your planning. PULL work instead of PUSH.

PULL keeps your boots on the ground and allows you to get a good feeling for the true size of the boulder you’re facing.

PULLING is the only way you can escape the Sisyphean Tragedy of PUSHING work.

👋 Digging the content? Let’s talk Product☕. I’m available for Fractional Product Management, Workshops, Coaching, and Speaking.

Management acted adequately and immediately evacuated the building after turning off all potential sources of ignition - lights, power, etc.

After the building was evacuated, two technicians from the local gas company arrived to investigate the matter. Upon arrival, they struggled to navigate in the dark. To their frustration, none of the lights worked.

One of the technicians reached in their pocket to grab a lighter. When he lit the lighter, the warehouse exploded, instantly killing both technicians and sending debris flying up to three miles away.

How could such a tragic mistake happen?

Nominated For the Darwin Awards

The above sequence of events was considered so astoundingly stupid, that in 1999 the technician was posthumously nominated for a Darwin Award. The Darwin Awards recognize individuals who contributed to human evolution by selecting themselves out from the gene pool.

You’re only eligible for the Darwin Awards under three conditions:

1. Nominee must be dead or rendered sterile.

2. Astoundingly stupid judgement

3. Capable of sound judgement

The third condition is key.

One of the first rules anybody learns when investigating a gas leak, is to turn off the lights and power, and to refrain from doing anything that may ignite a spark.

You don’t have to be a gas technician to know this. Almost everybody knows this. The problem is that when mistakes like this one happen, our typical response is to patch these mistakes by adding more rules.

Adding a rule to fix this problem is a massive mistake.

If you add a rule to fix this problem, there is a good chance you will never fix the real problem.

I define a rule is something you must do or follow. If you don’t, there will be (potential) repercussions.

Rules come in many shapes and forms (list not exhaustive):

• Plain rules. You’re not allowed to accept more than 50 dollars from anyone in an official capacity or it will be considered a bribe.

• Procedural rules. You must exactly follow all the steps in the agreed upon process.

• Layers. The moment you have more layers, it (implicitly) comes with rules who is responsible for what, and when you must consult higher-ups.

• Hierarchy. You’re not allowed to make certain decisions without approval.

The rules I’m talking about exclude constraints, guidelines or rules imposed by society, e.g. through law. I’m talking about the optional rules that companies intentionally decide to impose on themselves.

The problem with rules is that they might not fix the problem you’re trying to solve. In fact, adding a rule may even make things worse, because you’re only trying to treat the symptoms and not the root cause.

You didn’t fix the original problem and introduced an additional problem: an unnecessary rule you must now follow. Whenever your considering adding a rule to fix a problem, it’s extremely important to consider whether adding a new rule is the right way of solving your problem.

Enter the 7 Laws of Rules, that you can use to determine whether adding a new rule is the right of course of action.

The unfortunate gas leak disaster brings us to the first Law of Rules: rules, even when you’re capable of sound judgement, can’t prevent mistakes.

1. Rules Can’t Prevent Mistakes

No matter what happens, mistakes will be made.

We are fallible and imperfect human beings. Plus we may not even possess the intellect to keep the entirety of all the imposed rules in our head. Especially the more rules there are.

Even if you have rules covering precisely the scenario you’re facing, somebody will still make that mistake despite the rule. The gas leak disaster illustrates this perfectly.

Rules can help decrease the chance of a mistake happening, but they can never eliminate it entirely. Because no matter what you do people will make mistakes in following the rules.

If a mistake happens, carefully reconsider whether adding a new rule is the right course of action. You may be only treating the symptom and not the root cause.

2. Rules Preserve Incompetence

The more competent people are, the less rules they need. Not because those rules don’t matter - they still do - but many rules will be obvious when someone is competent.

Even if you know almost nothing about gas and electricity, it’s immediately obvious you shouldn’t turn on the light. You don’t need a rule for that, except if someone is truly incompetent.

If someone is truly incompetent, the rule won’t fix the actual problem: their incompetence.

Rules often become a special case of what Nassim Taleb calls ‘Minority Rules’. Where the least competent shape the rules that apply for the most competent. The danger of implementing such rules is that they don’t prevent the downside and they may actually cap your upside as well.

Relying on rules to fix incompetence means that rules tend to have a natural tendency to preserve incompetence. Rules that try to address the incompetence treat the symptoms, not the root cause.

When your rules exist to serve the incompetent, then for the competent they will simply serve as a reminder of something they already know, or even get in the way when they are faced with a situation where the rules are meant to be broken.

3. Incompetence and Distrust Fuel More Rules

When you’re in an environment with low trust and lots of incompetent people, then there is one thing you can be sure of: there will be many rules.

Mistakes will be common, due to incompetence, and those mistakes will be immediately turned into rules and processes due to the distrust.

I once worked at a company where the Security Officer said that no integrations were allowed to go live unless he personally reviewed all the code.

They didn’t trust their developers and they were probably right, but implementing such a rule would back-fire and not solve the actual problems.

4. Rules Can Sabotage Competence

Rules cannot increase competence, they can decrease competence. The more rules you have, the more they will undermine competence, because people will begin relying on rules instead of the real-world reason why those rules exist.

A good example of a rule that undermines competence is that every piece of code must be tested by a QA and that they are responsible for quality. By offloading quality to a single department, you will deliver less features, at a slower pace and at a lower quality.

Quality can’t only be the concern of only one subgroup of team members.

5. Rules Generate More Rules

The more reliant we become on rules to make the right decisions, the more elaborate and extensive those rules will become.

When these rules fail, our natural response will be to add more rules or to polish the existing set of rules.

I once saw a Jira workflow with more than 30 statuses. It didn’t start with 30 statuses, but once they went down the path of too many statuses to solve their problems, it became pretty likely that their workflow would explode out of control.

6. Excessive Rules Detach People From Reality

As Dee Hock, the founder and CEO of Visa, expressed much better with the Hock Principle:

“Simple, clear purpose and principles give rise to complex and intelligent behavior. Complex rules and regulations give rise to simple and stupid behavior.” - Dee Hock

Excessive rules are an internal consideration that rarely reflect reality. Reality is too complex to capture in a set of rules to follow, no matter how many rules you come up with.

All you will be doing by having excessive rules is making yourself look dumb. Reality is taxing enough without rules, let alone when you must navigate a maze of rules before you can make a decision.

7. The Spirit of the Rule Is More Important Than the Rule Itself

Rules serve a purpose. When you have rules people must follow, it’s crucial that people understand the intent and purpose behind the rule. Because only if people understand the intent and purpose, do you empower them to break the rule when it’s no longer applies.

If what you’re doing is complex, no rule is perfect, and there will be situations where the rules doesn’t apply. This is what horribly goes wrong when people use Scrum. They try to apply rules that don’t work for their situation.

Usually because they don’t understand the rule, but then they believe they’re doing something wrong instead of the rule being wrong. The 7th rule is more important than any of the rules that precede it, even for the 7 Laws of Rules.

The Unexpected Interplay of Rules, Competence and Trust

Let’s say you work in an organization with high trust and highly competent people. In such a situation most rules will be unnecessary (top right in the matrix below).

The more rules an organization has, the more busy its people will be with navigating the history of every mistake ever made. They will waste time complying with the internal considerations of an organization as imposed by the rules. This is a daily, sad affair in organizations with low trust and low competence (bottom left in the matrix above).

When you’re ruled by rules, the internal considerations become more important than real-world consequences. The problem with these internal considerations is that they are never more important than the real-world consequences.

Organizations that are ruled by rules, are the kind of organizations where terrible and inhumane disasters can happen because someone blindly follows rules that produce a terrible outcome.

If you’re in a situation with high trust and low competence (top left in the matrix above), then there will be a tendency for rules to preserve your incompetence. Rules frequently provide the illusion that you’re solving your problems. When faced with incompetence rules are often risky, because all they will do is cement your existing incompetence by treating the symptoms and not the problem.

If you’re in a situation where your people are highly competent but low in trust, then the more rules you have, the more you’ll be busy sabotaging your most competent people.

The mistake of not having a rule is not what you should be worried about.

The biggest mistake you can make is having too many rules. When you undermine your most competent people, they will leave to another place where they can actually be competent.

If you have incompetent people whose performance you try to elevate through rules and processes, then you will be dragging your most competent people down.

You will be stuck infinitely looping through the Cycle of Distrust, where rules beget more rules, until nobody is capable of doing anything anymore.

Rules cannot prevent incompetent people from making mistakes, they can prevent competent people from doing the right thing.

That’s the real thing you should be worrying about, as competent people intentionally not doing the right thing because they are blinded by rules is what can cause a Prime Minster to Resign.

The Dutch childcare benefits scandal crippled tens of thousands of Dutch families. The Dutch Tax Service wrongly accused 26.000 parents of fraud, leading to tens of thousands of families being driven in severe debt, resulting in suicides, divorces, bankruptcies, foreclosures and kids unnecessarily being placed in foster homes.

The whole affair was considered a systemic failure and caused the Dutch cabinet, including the Prime Minster, to resign. Everybody looked for someone to blame, but there wasn’t a single person to blame, as much as we wanted to find that person.

The more competent your people, the less rules you need. The more rules you have, the less competent your people will become. People are always more important than rules.

In the words of Jesse Frederik, a journalist who wrote a great book about the Dutch Childcare benefits scandal:

“It’s the people, far more than the rules, who ensure our country doesn’t come to a grinding, squeaky halt. People who don’t hide behind regulations because they make life easier, but who try to bend the rules until they are straight again.” - Jesse Frederik, Zo Hadden We Het Niet Bedoeld (This Isn’t What We Intended)

You try to hide behind rules that prevent you from doing the right thing but when your rules are inadequate at some point they will be exposed by reality.

That’s why the 7th rule is the most important: the Spirit of the Rule is always more important than the rule itself. We need more people who are unafraid to bend the rules until they are straight again.

The problem is that these reasonable rule-benders who are seen as unreasonable are precisely the kind of people who are unable survive in the harsh environments imposed by excessive rules.

It’s technical people who are used to operating in silos that believe the constraints have changed.

Delivering shit was never the bottleneck, except for truly shitty organizations.

• More features isn’t better. Even in the age of AI.

• More lines of code isn’t better. This still holds true with or without AI.

• A bloated codebase still sucks and drags the whole company down. You can get there now even faster with AI.

In fact, if you believe your constraint has changed, your ability to deliver value will be further out of reach than ever before.

Just look at social media: we’re being flooded with AI slop, because of the ‘More Is Better’ paradigm.

Yes, more is being shipped than ever, but we can all safely say that ain’t great AT ALL. We’re just seeing MORE crappy features.

More isn’t better. In most cases we actually want ‘Less But Better’.

That still hasn’t changed.

Let’s illustrate this by using a much simpler example: writing.

Writing a Book By Blinking

Jean-Dominique Baby suffered a stroke and lapsed into a coma. He awoke 20 days later unable to move anything except his head and eyes. His mental capacities were unaltered and he was fully aware of what’s going around him. This cruel phenomenon is called Locked-In Syndrome (LIS).

Bauby wrote a whole book by only blinking his left eyelid. It took him two months, working 3 hours a day, 7 days a week. The volume took 200.000 blinks to write at an average of two minutes per word.

His book was called ‘The Diving Bell and the Butterfly’. It sold many millions and even turned into movie starring Mathieu Amalric who you might know from the Grand Budapest Hotel, The Phoenician Scheme or Quantum of Solace.

I can write 120 words per minute. I’m easily a 100X faster writer than Jean-Dominique Baby was. Yet I will never write a multi-million bestseller like he did. Even if AI makes me 10.000X faster at writing than him.

The Bottleneck Hasn’t Changed

The bottleneck is still the same. Being able to write more words, deliver more features, or lines of code, will never remove the real bottleneck: real-world results.

A comedian that tells more jokes than another comedian isn’t a better comedian. The better comedian is the one who gets more frequent and better laughs out of the audience.

Delivering a feature is like telling a joke. Your joke doesn’t matter unless it makes people laugh.

The bottleneck is still the same: are you able to make people laugh?

Most people work at companies that ship shitty features and they will just ship more shitty features. There will just be🎵🎵 Feature Diarrhea Cha Cha Cha🎵🎵.

How good are you at connecting the dots between the features you’re shipping and the real-world results you’re trying to produce for your users, customers, and the business?

Don’t confuse your ability to ship features with your ability to deliver value. Just like my writing speed is not the bottleneck for my ability to write a best-selling novel.

If you don’t know how to slowly ship features that make a difference, then you won’t be able to do it quickly. Shipping more features won’t make a difference, in fact it will slow you down even more.

Focus on less but better before you go speedrunning based on the belief that more is better.

Ship faster and ship less. Spend more time on reworking and leveling up what you’ve shipped until it’s great.

That’s the real bottleneck, not the shipping itself. Make your audience laugh and rework those jokes.

Don’t tell more jokes, tell better jokes.

1. Roadmaps that make your job easier

2. Roadmaps that make your job more difficult

As you’ve probably already experienced as a Product Manager: most companies have roadmaps that make your job more difficult.

👋 Digging the content? Let’s talk Product☕. I’m available for Fractional Product Management, Workshops, Coaching, and Speaking.

Sometimes it’s so bad how the company does roadmapping that it makes people want to quit. I’ve been there and got the t-shirt. Think meetings about meetings, slow and ineffective decisions, and lots of unnecessary up-front legwork that only undermines our ability to do our job.

If we want to understand why roadmaps frequently suck and what the difference is between Blue and Red Roadmaps, we must first talk about Penguins.

The Penguin Principle For Roadmaps

Adélie penguins mainly inhabit the continent of Antarctica and nearby islands. You often see these penguins huddled together in dense groups near the water. Every penguin is reluctant to enter the water and waits until an unlucky individual (accidentally) falls in the water.

When the water surface stays calm and doesn’t turn red, the coast is clear. Other penguins rush to jump into the water to hunt for food. When the sea turns bloody red, it means sharks, leopard seals, or killer whales are around.

When they see blood, The penguins then decide it is better to stay on the ice and wait until the danger has passed. Most companies have bloody Red Roadmaps filled with sharks, leopard seals and killer whales that make your job as a Product Manager more difficult.

The Penguin Principle:

“Your roadmap exposes your organizational flaws. The more bloody red your roadmap becomes, the more sharks and internal obstacles are present in your organization that can make delivering the roadmap nearly impossible.”

The more internal obstacles your roadmap contains, the more red it becomes. Red Roadmaps are inside-out: they expose our internal organizational struggles and are optimized for the logistics of our organization - overcoming the internal struggles we’re facing.

You can easily spot Red Roadmaps because they usually have the following characteristics:

• Operationally taxing (big room planning, PI planning, release trains and other nonsense)

• Slow decisions

• Push work to the teams

• Solutions

• Coordination

• Cannibalization & Unproductive Conflict

• Operationally expensive

• Plans resistant to changes and lots of politics

Some companies, usually with lower organizational complexity like start-ups and scale-ups, have Blue Roadmaps that are strategically taxing and operationally easy to produce and adjust. Blue Roadmaps are outside-in: they expose our struggles with solving real-world problems. and are optimized for helping teams make decisions based on the latest and best information.

You can easily spot Blue Roadmaps because they usually have the following characteristics:

• Strategically taxing

• Fast decisions

• Teams pull work as real-world capacity permits

• Problems

• Collaboration

• Creative Conflict

• Humble and emergent plans inviting possibility and curiosity

Why do roadmaps turn bloody red, and what can we do about it?

The Tax of False Predictability

Most companies want things to go according to plan.

Delivering as planned is what gets you promoted. Stakeholders flash beaming smiles at you and pat you on the shoulder for a job well done.

Half-baked plans are a considered a sign of incompetence, but what if I told you that half-baked plans can actually be a sign of competence? Plans that look great on paper are actually the plans that should worry you the most, at least in the context of software development.

Let’s explore the tax of false predictability by talking about neural networks. What’s counter-intuitive about predictability is that by trying to completely eliminate the risk of failure, we can exponentially increase our risk of failure.

This can be explained much better using the Plasticity - Stability Dilemma that applies to Neural Networks. Let’s say you work at a company that develops a neural network that can detect whether a hot dog is present in an image. They want to update the image model to also be able to detect hamburgers.

To be able to learn through new information, the model must exhibit plasticity. Plasticity is what allows the neural network incorporate new information to detect hamburgers. However, a model must not only have plasticity, it must also remain stable. Stability is what allows the model remember what it learned in the past about detecting hot dogs.

If the model exhibits excessive plasticity, then it will no longer work for detecting hot dogs. If the model exhibits excessive stability, then it will only work for detecting hot dogs.

In a nutshell:

• Plasticity: you want the system behavior to learn and change from significant events

• Stability: You want the system to remain unaltered by insignificant events

How do plasticity and stability relate to planning and predictability?

Organizational systems exhibit the same kind of characteristics as neural networks. I call it the Predictability - Adaptability Dilemma.

The Predictability - Adaptability Dilemma

On the one hand, companies want predictability. Teams must limit surprises, foresee the unexpected and deliver exactly as planned. Companies that want predictability, often focus on Front-Loading decisions. They spend lots of time to nail the plan before starting the work.

On the other hand, companies want adaptability. If the unexpected happens, the teams must deal with it as necessary or maybe even turn it into an opportunity. Companies that want adaptability spend more time on Backloading Decisions using humble and emergent plans. Doing planning as it’s necessary when better information becomes available.

Adaptability and predictability are inherently at odds with each other. As I’ve expressed in the past:

“The more we try to prevent sucking at predicting, the more we will guarantee to suck at adapting.”

We can visualize the Predictability - Adaptability Dilemma as follows:

Red Roadmaps are optimized for predictability. Blue roadmaps are optimized for adaptability. I want to stress, both Red and Blue Roadmaps require extensive planning. The key difference is the type of planning and when the planning takes place.

The redder your roadmap, the more you’re planning like all the cards are already on the table. Red Roadmaps are taxing to create and focus on operational planning. Red Roadmaps are great if what you’re doing is highly predictable, you have lots of internal obstacles, and innovations isn’t important.

Blue Roadmaps are optimized for adaptability. The bluer your roadmap, the more your back-loading decisions until a later point of time when there are more cards on the table and you have better information to make a decision.. Blue Roadmaps are strategically taxing: lots of thinking is required to keep our plans emergent and decide what decisions we can postpone to the last responsible moment. Blue Roadmaps take into account reversibility and optionality when making decisions.

Blue Roadmaps are great when what you’re doing is unpredictable. You expect to encounter many surprises and you want to innovate. You focus on keeping your roadmap focused on the real-world challenges you’re trying to solve in a novel way.

Blue Roadmaps Aren’t Better Than Red Roadmaps

Blue and Red Roadmaps exist on a spectrum. Organizations may work in a way that exhibits characteristics of both roadmaps. The crucial thing is that you work in a way that fits in your situation.

If you have a Blue Roadmap, even though what you’re doing is highly predictable, then you end up in the following situation:

You are underfitting your plans and not thinking enough steps ahead. This can create huge operational waste and sometimes may even make rework impossible. You should spend more time on planning and making sure you create adequate plans that are operationally taxing.

If you have a Red Roadmap even though what you’re doing is unpredictable, then you end up overfitting your plans and thinking too many steps ahead. This creates huge operational waste and sometimes may even make rework impossible as well.

Red Roadmaps Should Be an Intentional Choice

Most larger organizations have Red Roadmaps, not by choice, but because the Penguin Principle comes into play: the roadmap exposes their organizational flaws. They are thinking lots of steps ahead not because the problem they’re solving demands it, but because it’s necessary for their organization to function and deliver anything at all.

These are the kind of companies that use Scaled Agile Framework (SAFe). As long as they keep on using SAFe, they will never fix their problems. SAFe is optimized for Red Roadmaps and operating in an inside-out manner which will won’t allow innovating and dealing with uncertainty effectively.

Most smaller organizations have Blue Roadmaps, not by choice either, but because they have extremely few organizational obstacles to overcome. The natural tendency then becomes to make your roadmap in an outside-in manner, so you’re better able to deal with the real-world challenges you’re facing.

But small organizations become big and as organizations become bigger and the kraken (internal bureaucracy) grows, their roadmap will naturally become more red.

The important you should be asking yourself: do we have a Red Roadmap because what we’re doing is highly predictable and not innovative, or is it red because we simply trying to survive and deal with our internal obstacles?

If what you’re doing is unpredictable and uncertain, then you should work on fixing your organizational struggles, because focusing on predictability will actually make you less predictable by cannibalizing your adaptability.

Remember in the context of complex work: the more you try to prevent sucking at predicting, the more you will guarantee to suck at adapting.

👋 Digging the content? Let’s talk Product☕. I’m available for Fractional Product Management, Workshops, Coaching, and Speaking.

Any first version of my articles? It’s a boring sludge of clichés.

That first MVP scope you proudly cobbled up? It’s an over-engineered mess where you could cut 2/3 of the scope and achieve much better results.

This happens because the default of our brain is ‘Bloat Mode’. The only way to fight Bloat Mode is to intentionally torture your brain. We don’t like punishing our mind, so we offload our laziness to the receiver of our work.

What should we be doing instead?

Write that e-mail. Rewrite it ten times. Remove as many words as possible and replace complicated sentences and words with simpler ones. Make sure that the first sentence is the most important one.

Doing this well is extremely hard and we rarely make enough time for it. We’re too busy and don’t have time to escape our default Bloat Mode. Because we don’t make time to replace our bloat with clarity, our lazy sludge comes back to haunt us.

Someone misinterprets that e-mail and sends an e-mail back. Another person doesn’t even read it, because it’s too long. A third person takes the wrong action, because they misunderstood the message.

We’re trading being less busy now for being ten times busier later. Our bloat mode ensures we will forever remain in bloat mode. Sometimes a wrong e-mail means we’ll be making wrong and irreversible decisions.

That bloated MVP you came up? After the release it contains a convoluted permission system you didn’t need that 10X’ed any future feature we want to deliver. The permission bloat even makes certain features impossible, unless we redo everything.

Brevity is confidence. You can only be brief when you know what you’re talking about. You can’t hide in simple language. Leaving out stuff is incredibly scary. It’s much easier to ramble and add on more words.

When you’re rambling, you’ve left nothing out, but you’ve buried what matters the most. Don’t be scared of leaving something out. Important things have a natural tendency to resurface.

The unnecessary is what should scare you the most. It’s like a forever chemical that sticks around indefinitely and cannibalizes what’s necessary. Bloat is like an evil cuckoo that throws out all the eggs that matter.

Eliminate the unnecessary to reveal what’s essential. Escape your bloat mode by pruning branches so the fruit can show and grow.

The framing of simplicity to be achieved by simply NOT doing work is misleading. Simplicity isn’t only YAGNI (You Ain’t Gonna Need it).

Simplicity means MORE work. It's harder to simplify than to do nothing and leave things complicated. The first version is almost never is the simplest version.

Keeping things simple means doing hard work and then doing even more hard work to get rid of your hard work.

Simplicity is hard because we hate removing and losing what we poured our heart and soul in

Yes, do make it easier for yourself by not adding unnecessary things in the first place.

But don’t be fooled: no matter what you do, simplicity won’t be easy.

I’m not worrying about that. I wish we had that problem right now. AI is frequently stupid and accidentally brilliant.

I’m afraid of no longer being able to see the stars because of all the ultra bright AI city lights flooding the sky.

I miss seeing those darn stars.

All the signal is being drowned more and more by irrelevant noise. AI has demoted us to raccoons rummaging through trash to find valuable content that matters to us.

Every month the noise is leveling up and getting better at creating mimetic signal. Every day more and more people use the sophisticated megaphone to produce noise with fake substance.

We’re currently having the con artist Frank Abagnale from the movie Catch Me If You Can constantly flooding our timelines with slop. Every single minute that passes the trash heap we must rummage through is growing.

Sayonara to all the stars.

I’m not worried about Nineteen Eighty-Four. We are currently living more and more in a Brave New World.

A Brave New World of AI

As a kid, I loved reading dystopian novels, like Nineteen Eighty-Four, A Brave New World, The Time Machine, and many more. As a teenager, I always believed Nineteen Eighty-Four was more likely to become true than A Brave New World.

Until Neil Postman surprised me with his brilliant book Amusing Ourselves to Death.

Neil Postman compares Nineteen Eighty-Four and A Brave New World, and comes to the conclusion that A Brave New World is more likely to come true than Nineteen Eighty-Four.

Stuart McMillen made a beautiful visual summary of the argument.

In essence the argument boils down to this:

We frequently worry about censorship or information being concealed. This definitely is a problem but there is a much bigger problem happening. We should worry even more about becoming so distracted that useful information gets buried in a sea of irrelevant pleasure.

This is precisely what’s happening right now.

Censorship Ain’t Our Biggest Problem

Trump can get away with all his nasty shenanigans not because of censorship, though that’s definitely happening too. All his insanity is already out there for the whole world to see. He is a convicted felon, even with the Epstein files not being fully released.

Trump has mastered the art of pulling wool over people’s eyes by spouting so much bullshit it can distract us from what’s really going on. Remember when he suggested we should inject disinfectant as a treatment for coronavirus?

A Brave New World is currently unfolding before our very eyes.

AI is flooding social media with irrelevant and fun content, like Elsa from Frozen singing Golden or a Jazz Version of Michael Jackson singing Billie Jean. This lazily and hastily generated AI content is competing for our attention with real artists.

When I search for a review of something I want to buy, more and more I’m confronted with fully AI-generated videos that waste my time by pretending they actually reviewed the product.

If I perform a search on Google, I’m presented with an AI answer that frequently completely misses the point.

When I visit Reddit, more and more posts are written by AI that pretend to offer substance but only want you to buy the product they’re promoting.

Everything online is simply getting worse and this doesn’t jibe with the fact that AI supposedly is getting better.

What worries me the most?

Today, when you travel on the train, there are more people looking at their phones than the outside world.

We’re living in the age of Amusing Ourselves to Death. Huxley was right, and Orwell was wrong.

We should stop only worrying about the truth being concealed, we should worry about the stars we can no longer see.

Did you ever work at a company and wonder: “Why don’t they just trust me and let me do my job?”

Have you ever experienced the reverse and ponder: “Why are they giving me so much trust? I have no clue what I’m doing and I’ve never done this before.”

I have experienced both of these situations. Both situations are stressful and frustrating, but one is much easier to fix than the other.

Let’s explain these two situations through the lens of the Slipstream Model of Competence.

Trust Vs. Competence

We can visualize the relationship between Competence and Trust as follows:

X-axis - Competence: can you make the right decisions?

Y-axis - Trust: are you allowed to make decisions?

If you’re above the line, you experience more trust than you deserve based on your level of competence. If you’re below the line, you experience less trust than you deserve based on your level of competence.

Pretty simple right? By now you’re probably wondering: why is it important to consider competence and trust together in this way?

Well, that’s because the level of trust you enjoy has a big impact on your competence.

Let’s explore this using an everyday example: raising a kid. What’s really hard as a parent is that you must prevent danger for your kids, but you must also allow them to take enough risks so they can learn and grow.

In the long run: the biggest danger is that they depend on you to make decisions. At some point they will leave the house and need to make their own competence.

If you don’t trust your kid slightly more than they are capable of, you will hurt their development. If you trust your kid too much, they may hurt themselves.

When you do it well it’s a beautiful thing to behold: your trust pays off with more competence. Increased competence helps to build their self-esteem and confidence.

The end result of giving more trust than they deserve is: trust begets more trust. As they become more competent, they deserve and receive more trust.

As simple as the relationship between competence and trust seems, the ramifications are profound.

Let’s explore the relationship between trust and competence further by visualizing my first job as a Product Manager:

My First Job As a Product Manager: Sink or Swim

I joined one of the fastest-growing start-ups in the Netherlands. The environment was fun, turbulent, stressful and high-trust.

I remember being completely surprised about the level of trust I enjoyed, given my level of incompetence.

What happens when you’re in a situation like that? It’s called a ‘Sink or Swim’ situation. Just like you shouldn’t throw a kid in a swimming pool when they can’t swim, it’s not the best idea to put a new employee in a sink or swim situation.

I was working overtime for many months and toiling away to grow my level of competence.

We could visualize my tricky situation as follows:

Because I was trusted to make many decisions I was incapable of making I was accumulating many mistakes. I was not only swimming, I was also sinking. It’s the only job I ever had where I was wondering why they didn’t fire me.

We can visualize this sinking of trust as follows:

All those unnecessary and preventable mistakes were putting me at risk to demolish the level of trust I was enjoying. Luckily I wasn’t fired, because I was swimming faster than I was sinking.

As a result, at some point I ended in a comfortable place: The Slipstream of Trust. This is the place you want to be most of the time. You want to experience slightly more trust than you deserve. Being in the Slipstream of Trust means you can grow your competence further and earn even more trust than you’re currently deserve.

As a parent, I try to raise my kids in the safe environment of the Slipstream of Trust. I don’t want them to sink, but I also want them to learn how to swim. But dang, it can be hard sometimes to find the right balance.

Now, let’s imagine you would start from the completely opposite situation: you experience significantly less trust than your level of competence:

My Second Job As a Product Manager: Drag and Disappointment

This is the equivalent of a parent telling a kid ‘No’ all the time and constantly repeating what they can and can’t do.

This happened to me when I left my first job as a Product Manager for a much bigger company. I worked with much smarter and better people (on paper), but I had much less ability to make decisions because of the low-trust environment.

If your level of competence is much higher than the level of trust, you will experience Drag and Disappointment. You will frequently struggle to make the right decisions, despite knowing the best course of action.

As a result of the low trust environment, you will struggle and be perceived as less competent.

We can explain why this happens using an example from the world of racing. A racer who is in the slipstream of another driver will move faster. Once you become to too far removed from the slipstream you will encounter dirty air that increases drag and will make you move slower.

The same happens with the Slipstream of Trust. Once you leave the Slipstream of Trust and trust decreases, then you will suffer from the Drag of Distrust. You will move slower and as you struggle to make decisions you will be perceived as less competent.

As your competence drops, it will be more difficult to create trust and escape towards the Slipstream of Trust again.

Once you’re in a situation of distrust, it’s extremely hard to restore trust. Delivering results predictably, reliably and competently helps restore trust, but since distrust hurts your (perceived) competence and ability to deliver results, this is a very difficult situation to crawl out of.

In Dutch we have a saying, trust comes by foot and leaves by horse. Once you’re below the Drag of Distrust, there is a natural tendency for teams to sink further and and create even more distrust. Which will make it even more difficult for them to become high-performing.

This is called the Cycle of Distrust I’ve written about before:

Are You Trust-Capped or Competence-Capped?

Why does understanding of all of this matter? It’s extremely important to understand whether your level of competence is Trust-Capped or Competence-Capped.

It’s important to understand this, because any progress NOT at the bottleneck is an illusion.

If you are in a Competence-Capped Competence situation, you should work on increasing your competence in a way that doesn’t significantly decrease trust.

Because if trust decreases too much, then you may end up being Trust-Capped together with the Drag of Distrust potentially dragging your competence down even further.

If you’re in a Trust-Capped Competence situation, you should earn trust and convince leaders to give you more trust. This may also mean getting rid of processes, rules and hierarchy.

The lower the trust, the more drag you will experience that will handicap your competence, which will hurt your ability to restore trust.

Once distrust is so high that competence is significantly impacted, it will be extremely hard to increase trust. Because that distrust will come seeping in all kinds of unnecessary bureaucracy, departments, hierarchy rules, processes and rituals, which create so much drag it will become nearly impossible to show that your competent.

The end result: distrust fuels even more distrust.

When your teams experience enough drag and disappointment, your best people will leave. You will be left with the people who choose to remain in your low trust environment.

Those are exactly the kind of people that will never get you out of that situation, because they only way they can stay and survive is by deciding to accept their low-trust fate.

Trust and competence are closely related to each other. If you want your people to be more competent, you should give them slightly more trust than they deserve.

If you want your people to gradually become more incompetent, you should give them less trust than they deserve.

Unfortunately, giving people less trust than they deserve is what most companies do. They waste a lot of time trying to hire the best people, only to put them in situations where they experience much less trust than their level of competence.

If that’s what you want to do, a much smarter (and cheaper) course of action is to hire less competent people. Because that’s what inevitably will end up happening anyway: your most competent people will leave.

If you want your people to be(come) competent, you better trust them. If you want them to become incompetent, you better distrust them.

I learned far more from working in a high trust environment with inexperienced people than I ever did from working in a low trust environment with brilliant people.

In the simplest possible terms: Trust fuels competence and competence generates trust.

Distrust fuels incompetence, which in turn creates more distrust.

Cloudflare recently crashed half the internet. Many funny pictures followed, like:

The one thing you can be sure of after massive outages like this: there will be a Post-Mortem.

The goal of a Post-Mortem isn’t to assign blame, but to understand why the issue happened and come up with concrete actions to prevent it from happening in the future.

The default starting point of a Post-Mortem: everyone makes mistakes. The fact mistakes can happen isn’t the problem. It’s about reducing the chance of the mistake happening again.

A good example of this is the GitLab incident in 2017 where a developer accidentally dropped the production database. The developer in question wasn’t fired. They did publish a post-mortem with mitigations on how they can prevent it from happening in the future.

Post-Mortems are incredibly valuable. But I’m going to argue many companies running Post-Mortems are missing out on something that can be even more valuable: Meta Post-Mortems.

The Benefit of Meta Post-Mortems

The problem with Post-Mortems is that they are usually isolated to the single incident you’ve just experienced.

Here is a simple visualization from Atlassian:

You’re trying to prevent that specific incident from happening again in the future by discovering the root causes that allowed it to happen.

Then you come up with mitigations to prevent from happening again in the future. But don’t be fooled: it all revolves around the original incident.

The problem with this approach, is that you’re unlikely to discover the deeper problems that allowed the incident to happen in the first place. Of course, we try to do that by keeping asking why, but let’s be honest many teams settle for surface-level mitigations.

Every production incident not only says something about the situation, but may also say something about your organization.

Imagine you’re in any any of the following situations:

1. One of the teams in the company frequently has post-mortems for incidents.

2. A company frequently has post-mortems across many different teams.

If either of these two situations apply, it’s a good idea to run a Meta Post-Mortem (MPM).

What’s a Meta Post-Mortem (MPM)?

In a Meta Post-Mortem, you’re not concerned with the specifics of the incidents. You’re simply using the past high-quality information of those incidents to potentially address systemic issues greater than any individual incident.

A Meta Post-Mortem focuses on uncovering the deeper problems and issues that allowed those production incidents to happen.

All those Post-Mortems are a treasure trove of high-quality content that potentially contain lots of systemic issues that are waiting to be addressed.

By looking through the lens of the Meta Post-Mortem (MPM), you can effectively look at the quality issues that you must address in your organization that go beyond any single team or single incident. You can even use AI to help speed up this process.

In short, if you see many Post-Mortems happening, it may be time to make it more reflective and meta, by running a Meta Post-Mortem. You can then uncovered deeper issues, like:

• Teams working on too many different things at the same time

• Too much technical debt

• Not enough expertise present in the teams

• Poor collaboration between teams

There are a gazillion possible reasons why you’re having too many production incidents. The beauty of the Meta Post-Mortem you can use it to look at all those incidents and go beyond the surface-level issues to discover the much deeper systemic issues that fester in your company.

In short, the next time you’re running yet another Post-Mortem, try to run a Meta Post-Mortem instead and make a much bigger impact beyond any single incident.

A single incident is a problem. Many incidents are a pattern and should trigger a Meta Post-Mortem.

1. The higher the trust in an organization, the more decisions you can make.

2. The more decisions you can make, the more ownership you can have.

You can’t have ownership without the ability to make decisions. It’s that simple.

In many organizations, there isn’t enough trust. When there is no trust and psychological safety, the following happens:

1. If you can’t make decisions, you will restructure the organization around the inability to decide. Think silos, departments, processes, rules and lots of meetings. Departments will actively try to maximize their decision-making power over little pumpkin patches of responsibility and begin to fight each other.

2. If you can’t make decisions, you will struggle to deliver results, and trust will plummet.

3. When trust plummets, you will get even more bureaucracy, rules and processes to compensate for the lack of trust. Basically it will amplify point 1.

4. As a result, it becomes even more difficult to make decisions, take ownership and deliver on results.

Congratulations, you’ve now entered the Cycle of Distrust:

When you don’t trust your people, you will develop an organization where you can’t trust your people. Distrust fuels distrust.

Leaders: if you feel like teams are not taking enough ownership, it’s most likely not the fault of your teams, but a symptom of a dysfunctional organization.

You can’t have ownership with little pumpkin patches of responsibility that actively cannibalize each other.

If you can’t trust your people, then that’s the problem you must fix.

Anything else is insanity.

The cat will jolt up and run away in fear.

This happens because our mammal brains are prediction machines. The cucumber gets mistaken for a snake. A snake means danger, so the cat immediately jumps away to escape the danger.

Our brain loves predicting. However that prediction machine, just like the cucumber that gets misinterpreted as a snake, comes with significant biases and mistakes. Our minds love turning cucumber into snakes, especially if we lack information and understanding.

An example of the cucumber that gets mistaken for a snake is the lack of predictability in software development.

Complex work means many surprises. What you thought to be a snake turns out to be a cucumber. The cucumber may even turn out to be a snake.

In other words, no matter what we do some of our predictions will turn out to be wrong and there will be many surprises. Because our brain doesn’t like when it can’t predict, it will still find a way to pretend it can predict.

Pretending to predict when we can’t predict is where Story Points and Velocity come in.

We waste a lot of time to arrive at silly numbers, so we can pretend that we’ve discovered all the snakes. In the process, we create a gazillion cucumbers that we treat as scary snakes.

We lose sight of what truly matters and get distracted by the cucumbers we treat as snakes. We forget to pay attention to the real snakes that matter.

Focus On Snakes and Not Cucumbers

If you want to focus on the real snakes that matter, stop wasting too much time on estimation. Try something else, like Roman Estimation, that prevents you from getting distracted by cucumbers.

Stop wasting time on estimation, it’s a fool’s game.

The irony of an obsessive focus on prediction, Story Points and Velocity:

The more you try to prevent sucking at predicting, the more you will guarantee to suck at adapting.

When we become better at adapting we make more progress and our predictions will become more accurate as a result.

Focus on keeping your boots on the ground and evading the snakes, not keeping your head in the sky and spawning imaginary cucumbers.

It’s easy to say and extremely hard to do, because remember: our brains are prediction machines and they hate not knowing.