The Phenomenon of Prevalence Induced Concept Change

In organizational change, people may respond to improvements in unexpected ways - even though things are getting better, they may be under the impression that things are getting worse - and they may even have data to back up their claims! So, how do you get out of the dilemma of having to justify improvement without starting a theoretical debate detached from what people see, hear and feel?
In this post, we will take a peek at a typical case of Prevalence-Induced Concept Change (PICC) and how to address it in a constructive manner.

What is Prevalence Induced Concept Change?

"Prevalence induced concept change" (PICC) occurs when the frequency of events changes, leading people to modify their definition of what constitutes a problem. This shift in criteria means that as major problems become less common, minor topics start to gain more attention and are perceived as more significant than they actually are - or in reverse!

We will take a common example connected to "Agile Transformation" to illustrate our case - although you may encounter PICC in many forms and shapes.

Transitioning from Classic Project Management

In Classic Project Management, we have our ways of doing things, and everyone knows that nobody's perfect, so there are always some concerns. But, we have arranged ourselves with them, understand them, and how to manage them.

Classic Project Management

• Long-Term Schedules - Projects span several months, with a final delivery date set well in advance. The impact of missing a timeline tends to be massive, and a slippage in schedules requires serious management attention.
• Delayed Feedback - The first feedback comes on "Release Day," and the events on that day tend to be overwhelming due to the sheer volume and severity of problems that went undiscovered during the project.
• Hidden Issues - Problems remain undiscovered until late in the process, making them costly and difficult to address.

And now let us contrast that with a more modern approach.

Modern Delivery Approaches:

• Rapid Cycles - Large projects are divided into short cycles, with intermediate evaluation points.
• Frequent Feedback - Developers receive timely feedback on completed work in small batches.
• High Transparency - Problems are identified and addressed quickly, promoting continuous improvement.

This leads to many follow-up questions: First, how do we even work in a way that we can collect feedback faster - and second, what do we do when we get "bad feedback?" Especially in organizations where Continuous Improvement is not systematized in project management, the question "what do we do with the feedback" can lead to a quagmire of followup concerns that can completely derail a team if not properly addressed.

The Impact of PICC

An organizations advancing from classic project management to a more modern delivery approach may have stakeholders fall for PICC and misinterpret the nature and frequency of what's going on:

• Buffer sizes - By slicing a large project into a sequential set of deliverables, the project gets more checkpoints, and each of them gains a small buffer. So a buffer overrun on one of them is not even an issue - the main timeline is not even in danger when a day of buffer has been consumed! However, a buffer overrun may lead managers to overreact who are used to a buffer overrun always requiring management intervention.
• Higher Expectations - With frequent deliverables, stakeholders have more time to focus on individual deliverables, so they will pay more attention to minor issues they would never have noticed in a project where it was normal that half the scope was unusable upon delivery.
• Perceived Underperformance - A successful product review will always elicit improvement potential, and the constant appearance and high volume of new issues can be misconstrued as underperformance by a management that's used to every report being a quality flaw.

Preventing Misconceptions Caused by PICC

To prevent the misconceptions caused by PICC and ensure that successful improvements are recognized as such, it is essential to create transparency and educate stakeholders of what's actually going on:

Define the Benchmark

Highlight Changes - Frequent evaluations in modern delivery make more issues visible - but also lead to quicker resolutions and thus, better outcomes.

Differentiate Categories - Clarify that the issues reported now are generally smaller and require lower fixing efforts, unlike the severe and late-discovered issues in classic project management that often led to minor issues not even getting addressed at all!

Create Transparency

Provide Objectivity - Agree on severity levels early, and categorize issues accordingly, illustrating, for example, that whereas before, people were simply accepting showstoppers, they are now arguing about button colors.

Analyse trends - Use trend analysis to show how severity classes and quantities shift over time, demonstrating that the measurement is subtly changing.

Manage Expectations

Frame Feedback - Highlight that the feedback is now on a different level than before, and that the purpose of that feedback has also changed.

Correlate Action - Show how feedback is now differently correlated with action, and that the time between highlighting an issue and getting a fix is improving.

Conclusion

Prevalence induced concept change (PICC) can significantly impact how stakeholders perceive the success of teams. Hence, understanding that PICC is happening is a key instrument in managing change and expectations effectively. Be aware of the situation, create objectivity and transparency, then manage expectations to move beyond category errors, misconceptions and perceived deterioration.

Performance matters!

Performance is one of the most important factors for an agile organization, even though the topic is often viewed with suspicion. Yet, a proper understanding of - and close attention to - performance is critical to success. Here's why:

On Stage

Let's say you go to a concert. You were thrilled with anticipation, you booked the tickets half a year in advance, made an Instagram story about all your preparation, and on the day of the event, a sleepy, un-enthusiastic singer shuffles on stage and sings without any emotion at all. What's your next post going to be? "This was a terrible performance! So disappointed!" Okay, now let's say we sanitize out the word "performance." That leaves your impression at "That was terrible. So disappointed." Well, that feedback won't help the band improve: What was bad? The location, the food, the music? If I was part of the band, I'd just disregard it, because nothing is ever perfect.

In the workplace

Of course, a stage performance isn't the same as workplace performance. Still, we work for people who have expectations on what we do, and to whom it matters whether we achieve something or not. That said, let me briefly define, 

Performance: the ability produce desirable outcomes.

Thus, inattention to performance sends a strong message, "your outcomes don't matter" - in extension, "you don't matter. There is no better way to demotivate people!

We should strive to build high- and hyper-performing teams, and create an environment where each individual is able to perform at their best. We need to constantly ask ourselves, "How can we perform better?" - and relentlessly fix any problem that stops us from performing better.

Aren't "performance measurements" detrimental?

Three remarks - 

1. Goodhart's Law (A measure that becomes a target ceases to be a good measure) 
2. Attribution error (Correlation doesn't equal causation) 
3. Weaponization (Everything is harmful when used as a weapon)

That is: what gets you the bad outcomes is a misdirected measurement system, not performance itself. Don't throw out the baby with the bathwater! 

How does performance matter?

The result of keen attention to performance is pride of craftsmanship and sense of accomplishment: going home after a challenging day of work, we are satisfied with our achievements, and we feel that our time was worth it.

Low performance, in contrast, means that we go home and wonder what we just wasted our time with. It leaves us demotivated, disoriented, burnt out.

And regardless of whether we give it a name, or not: the feelings will be there. We would like to have more sense of accomlishment. Hardly anyone looks forward to feelings of uselessness, worthlessness or pointlessness.

"Performance" is merely the label we attach to these feelings.

If you've ever worked on a hyper-performant team, you will remember that experience for the rest of your life. The experience will continue to boost your self-esteem, your desire to grow, and make you both more professional and a better person. Likewise, if you've ever worked on a low-performance team, you will also most likely remember the experience for the rest of your life - but most likely as a chapter you'd prefer to never repeat.

Performance is paramount.

Dealing with limiting beliefs

We often encounter that Limiting Beliefs are holding us back from achieving the goals we want to achieve, from doing what is right, from becoming who we want to be. So - if we know this, why aren't we changing our beliefs? Because, very often, our beliefs define who we are, and change is hard. But there is hope. What could we do?

Limiting Beliefs

Let's start by defining limiting beliefs - a belief confining us, or reducing our options in some way. We all hold limiting beliefs, and there are some of them that we shouldn't even change. So - when exactly are limiting beliefs an issue? A simple and quick answer: when we should be doing something that's hard or impossible because of a specific belief we subscribe to.

Let's use an example to illustrate our case:

Say, Tom is a manager and he believes that: "Developers can't test their own software." This belief is limiting, because it stops all beliefs, decisions and actions built on the idea that "developers do test their own software." 

The problem with limiting beliefs

As long as Tom holds this belief, he can't support the ideas of, for example, TDD or Continuous Delivery, because these are in conflict with his belief. And beliefs aren't like clothes - we can't change them at whim. Here's what we're dealing with:

Belief networks

Limiting beliefs don't simply stop one change, they are often part of a complex web of other beliefs that reinforce the limiting belief, and which would be incomplete, incoherent or even inconsistent if that limiting belief was changed - so we can't just replace one belief without examining its context: "Why do you hold this belief?" 

Supporting beliefs

In Tom's example, we might find other supporting beliefs - such as the Theory X idea, "Without being controlled, developers will try to sneak poor quality into Production, and then we have to deal with the mess."

Anchoring

Tom is probably a reasonable person, and his belief was most likely anchored by a past experience - there were major incidents when developers did cut corners, and these incidents forced Tom to adopt a policy of separating out development and test, and that ebbed the tides.

Negative hypothetical

Let's ask Tom, "What would happen without a separation of development and test?" - and he'd most likely refer back to his anchor experience, "We would have major incidents and wouldn't get any more work done because of continuous firefighting." - and it's hard to argue his case, because it's consistent with his experience.

Conjunction Fallacy

Let's ask Tom an inconspicious question to figure out what Tom thinks is more likely: "Which scenario do you think is more probable: that a developer creates a mess, or that a developer who tests their own code creates a mess?" - Tom will probably answer that it's the latter. This, however, is fallacious, because developers testing their own code are a subset of developers, a special case: if that was Tom's answer, he would (probably unknowingly) subscribe to the idea that developer tests increases the probability of poor results!

Confirmation Bias

Now, let's assume that we manage to convince Tom to make an experiment and let developers take control of quality - we're all human, and we all make mistakes. Tom will feel that the first mistake developers make confirms his belief, "See - we can't. I told you so." 

Selection Bias

Of course, not everything an autonomous developer will deliver is going to be 100% completely broken, but Tom will discount or dismiss this, because "what matters is the mess they created and that we didn't prevent that from happening." - Tom will most likely ignore all the defects and incidents that he currently has to deal with despite having a separate Test Department because these aren't affirming his current belief.

Changing limiting beliefs

Given all these issues, we might assume that changing beliefs is impossible.

And indeed, it's impossible to change another person's beliefs. As a coach, we can't and shouldn't even try to do this: it's intrusive, manipulative and most likely not even successful. Instead, what we can do is: support the individual holding a limiting belief in going beyond the limits of their current beliefs.

Here's a process pattern we could use to help Tom get beyond his limiting belief:

1 - Write down the limiting belief

When you spot a critical limiting belief in coaching, write it down. Agree with the coachee that this is indeed the limiting belief they're holding.

2 - Ascertain truth

Truth is a highly subjective thing, it depends on beliefs, experiences and perception. What we want here is not "The truth," but what the coachee themselves asserts to be true: "Do you believe this is certrainly true?" - "What makes you so sure it's true?" - "Could there be cases where this isn't true?"

This isn't about starting an argument, it's about getting the person to reflect on why they're subscribing to this limiting belief.

3 - Clarify the emotional impact

Let's ask Tom, "What does holding this belief do to you?" - and he may answer: "I know what I need to do, that gives me confidence." - but likewise: "I am upset that we can't trust developers on their quality."

We hold onto beliefs both because and despite how they affect us. There's always good and bad, and we often overlook the downsides. Most likely, Tom has never considered that he's carrying around some emotional baggage due to his belief. Until Tom comes to realize that this belief is actually limiting him, and also negatively affecting him, he has no motivation to change it.

4 - Clarify consequences

 Next, we'd like to know from Tom where the limiting belief will put him in the long term: "When we look back, 10 years from now - where will you be if you keep this belief?"

We would like Tom to explore the paths he can't go down because of his limiting belief - for example, "We still won't have a fully automated Continuous Deployment - and I will be held responsible for this." Tom needs to see that his current belief is going to cause him significant discomfort in the future.

5 - Surface the Cost of Not Changing

We're creatures of habit, and not changing is the default. We first and foremost see the cost of change, because that's immediate and discomforting. And we ignore the cost of not changing, so our default would be that we have no reason to change anything.

Tom must see the costs of persevering in his current beliefs, so we ask: "What's the cost - to you - in 10 years, if you don't change this belief?" - a mindful Tom might realize that he'll get passed up for career opportunities, or might even get replaced by someone who will bring new impulses. The more vivid Tom can paint the upcoming pain, the more determined he will be in wanting to change.

And that's the key: As long as Tom himself has no reason to change his belief, he won't. But we can't tell him what his reasons should be. Tom has to see them by himself, and in a way that is consistent with his other beliefs.

6 - Paint a brighter future

Tom may now be depressed, because in his current belief system, he's doomed: there's no hope. So let's change Tom's reality. Let's ask him, "If you change this belief, what would you be and do?" - Tom might be skeptical, but will tell us some ideas on his mind, "I'd give devs permission to test their own code." - "I wouldn't enforce strict controls on developers." - "I wouldn't be known as the only person in this company insisting on stage-gating." 

We can then follow this up with, "How would you feel if this could be you?" - if we get positive responses like, "Less stressed, more appreciated" - we're moving in the right direction. If we get negative responses like, "Stupid, Unprofessional" - then there's another, deeper rooted limiting belief and we have to backtrack.

7 - Redefine the belief by its opposite

Let's ask Tom, "What's the opposite of this belief?" - and Tom would answer, "Developers can test their own code." Tom needs to write this down on a card, and keep it with him all the time.

8 - Reinforce the new belief

Every day, Tom should read this card and look for evidence that this opposite belief is true. For example, Tom can find out which people hold this opposite belief, and how it works for them. 

At a minimum, Tom should just take a minute and sit back in calm, take out the card and read it to himself - and then repeat this new belief to another person.

As coach, we can challenge Tom to repeat the new belief back to us frequently, and to provide small stories and anecdotes about what he has said and done based on this different belief.

9 - Reflection

After one month, reflect with Tom what difference thinking and acting based on this opposite belief has made, and how often he lapsed back into thinking and acting based on his limiting belief. Under ideal circumstances, Tom will have success stories based on his new belief - these are a great basis for reflecting whether this new belief can serve him better than his former, limiting belief.

Even if Tom sees no difference, he already has evidence that his original belief may not be true.

If Tom is still struggling, he may need more time to be convinced. 

Closing remarks

Even with a formal process for belief change, we're not guaranteed to rewire or reeducate others. We respect and enjoy freedom of thought and differences in belief, and the best we can do is highlight consequences, reinforce and provide feedback.

If we see that people choose to cling to old beliefs and habits despite all our attempts at supporting them, we have to ask at a meta level what the difficulties are, and whether our support is even desired. We're not in the business of messing with other people's heads - we're in the business of supporting them in being more successful at achieving what they want, and in coming to realize what that actually is.

Microhabits - small action, big impact

 Let's talk about #microhabits - the small things that don't seem to make a difference at all in the short term, which are setting you on a long-term trajectory.

What are microhabits?

Microhabits are actions that take nearly no time and seem to have a very limited scope, and seem to not be worth mentioning, yet they set you on a compounding trajectory. Many years after adopting a microhabit, people adopting it are worlds apart from others around them.

Here are some examples of software development microhabits:

• Appropriately naming stuff
• Fixing typos
• Refactoring
• Making sure the code is easily testable
• Adding important unit tests
• Generally keeping code readable and workable
• Creating a working build at leasts a few times a day

No excuses

I often hear, "This was an emergency," or "This was just a demo," or "There was time pressure." These are supposedly justifications for not doing the things above. In the working world, there will always be some stress, deadline or emergency lurking behind the next corner. Everything else is cockaigne.

Here's the thing, though: Microhabits become "second nature" and it's more effort to break a habit than to pursue it, so we can't argue that pressure is a reason to do something slower, more complex and less routine than what we'd normally do.

People with good coding microhabits will pursue their habit and keep their code high quality regardless of circumstance. Simply because it's a habit. An important realization about habits: they'll never form if you constantly interrupt them - so consistency is key.

Form the right microhabits habits today!

Which actions, when done consistently over many years, will result in a codebase you'd love to work with? Adopt these, and keep doing them consistently.

And which would result in a codebase you'd loathe? Stop these, and avoid them consistently!

If you want to do a facilitated Retrospective on the topic, you can use this simple template:

Time to discard the "T-Shaping" model!

 A common concept in the "Agile" community is that of T-Shaping. Regardless in which form or fashion it is promoted, the narrative is basically this: People have certain skills, and if they are one-trick ponies or are too generalist, they need to form a so-called "T-Shape." Nonsense!

The concept of the T-Shape

A specialist is a person with a very narrow skillset (making that person an "I"-Shape) while a generalist has a broad skillset (making that person a "dash"-Shape). 

A broad set of skills plus one deep expertise is a "T", multiple deep expertises are "Pi." And then, no model couldn't be "improved" by adding complexity, so we get variations like "M" Shapes, i.e. non-generalists with multiple expertises, and "E" shapes who aren't only experts, who also have "experience, exploration and execution." - although that's clearly buzzword bingo terrain, because what kind of an expert doesn't also have these?

Even I have blogged about T-Shaping, for example, here.

With the model, we were moving the burden onto people: "You must form a T/Pi/E-Shape." Thats nonsense, because it's not like people wouldn't do that on their own volition. In fact, most people who find that they can't use their skills at work will spend their time acquiring off-work skills, such as, for example, learning an instrument: everyone is Pi-Shaped, the only question is if it helps the company.

And now, I announce the time to ditch this model in favor of another model that already predates the Agile Manifesto - "Psychological Flow", by Mihály Csíkszentmihályi.

Psychological Flow

Let's take a look at the model Csíkszentmihályi proposes: He uses the dimensions of "Challenge Level" and "Skill". The very assumption that people have "one" or even a very limited number of skills is already absurd. Consider, for example: breathing. Do you know anyone who doesn't have this skill? Depending on what would qualify as a "skill," people are experts in thousands of them.

Instead of thinking about skills as discrete variables with a discrete set of values (e.g., "none", "basic", "advanced", "expert" ...) - we could think of "skill" as a continuum of different, integrated topics on a continuum spectrum.

Most importantly, the psychological flow proposes a second dimension: the level of challenge, in relation to the skill. For example, asking a Chess Grandmaster to state how a pawn moves is like a relaxation exercise. On the other hand, someone who never cared about Chess won't even take an interest in this question, "why should I care?"

If you'd ask a senior project manager to take care of large, critical programme, that brings out excitement and a sense of, "I am the right person for this job, and I can do it." Their brain would immediately sort through potential approaches and how to make it a success.

A college fresher, on the other hand, might be anxious about where to start and what to do.

That's the basic concept.

Notice that neither the "challenge level" nor the "skill level" are measured on an absolute scale - they can be considered from the perspective of the person who is doing the work: Is this work "low challenge" or "high challenge," does it require "low skills" or "high skills?"

How is Flow related to T-Shapes?

Well, it is - and it isn't. Instead of asserting that a person has a certain skillset required to do the job, we reframe the skilling challenge:

1. Is a task adequate to a person's skill level?
1. We should not under-challenge people, lest they bore out.
2. We should not over-challenge people, lest they become become worried or anxious.
2. How do we ensure that people receive challenges which allow them to use high skill?
1. High challenge, medium-skill tasks get people to become interested in what they do and that's how they grow.
2. High challenge, high skill tasks bring the best out of people.

The challenge, hence, is to identify meaningful, highly challenging work which is at least within grasp of people: medium skills get people excited, high skills get people to perform at their best.

Failure in "T-Shaping" isn't on the individual - it's team management not ensuring people have sufficient challenge to grow and show their performance.

(note based on feedback: in a self-managed team, "team management" isn't top-down - it's what teams decide to do)

T-Shaping ignores Flow

The T-Shaping model makes an implicit assumption: that all the work in the expertise domain is of interest to a person, and that it's a good use of their skills. This isn't always the case. Part of the work may make a very advanced person fall asleep, while being quite challenging for someone new to the domain. Hence, the best way to distribute work in a team isn't based on a certain "T-Shape," but to ensure that people reach a flow state - that is:

A team as a whole performs best not when people exercise a certain "T", but when the work provides everyone with sufficient, yet not overwhelming, challenge.

We shouldn't upskill with the goal of acquiring an abstract "T-Shape" - that's a weird framing already. 

Instead, we should distribute work in a team so that everyone is excited to do what they do, while ensuring nobody is overchallenged and anxious or underchallenged and bored.

Whether the result is something like a "T-Shape," doesn't even matter - because the primary result is a highly qualified team whose members are comfortable taking on slightly bigger challenges every day. 

Let's forget the T-Shape.

Let's refocus on the question, 

"How can we distribute work within our team, so that everyone gets to spend the highest amount of time possible in a flow state?"

The economy of incentives

People working in bigger companies often do things which don't really seem to make sense when looking at the big picture. And yet, they're often pretty reasonable in their choices. They are intuitively following basic psychological and economical principles. Let's explore.

The economy of needs, wants and incentives

Let's start out at the detail level of the individual. Each person has needs:

The need pyramid

Maslow's hierarchies of Needs, sometimes also called "Maslow's pyramid" is built on the theory that every human being has needs, and these needs follow a hierarchical order. This picture is already a simplification, more comprehensive models are abundant on the Internet. 

While each person has the same types of needs and the pyramid is the same, the level at which these needs are considered "satisfied" widely differ. 

One person might feel basically satisfied with a bowl of rice and a few cups of water, whereas another person requires a more special diet to  sustain. These are the basic needs, which must be met to ensure survival. People whose basic needs aren't met will not have a mind to think about other things, their primary concern will always be meeting these needs.

Once people are satisfied at the basis, they care for psychological needs - family, social ties, being accepted and valued.

With such a firm foundation starts the restless search for meaning in life - developing one's personality,  being creative, pursuing a cause. At this level, people look for transcendency.

Dan Pink mentions this in his book, "Drive" - without fully realizing that it's not just that the money must be off the table, but all basic and psychological needs. People who feel threatened for their physiological well-being or social status aren't looking for transcendence, so in order to set up an organization where people go to look for a higher purpose, there's a lot of groundwork to be done in taking care of people first.

From "Need" to "Want"

Unmet needs cause dissatisfaction with the status quo. This is also true for the future, because people think ahead.

We build our needs pyramid from the bottom, and whenever a lower-levelled needs turns to an unmet status, everything on top of that need gets out of focus. A starving person doesn't care for appreciation (many artists can tell that story.) A bullied person won't feel the office aesthetics. And so on. So, when a person has an unmet need, they want something, and action is required to satisfy the need (although it could be a different actor to serve the person in need.)

There are a lot of intermediary Wants - for example, money can be used to meet all kinds of need. When a person is hungry, they want money to buy food. Or drink. Or to pay the rent. Once basic needs are satisfied, they might invest that money to buy a token of wealth that meets their need for social recognition. And so on.

Other intermediary Wants, such as a promotion, could be more complex: Is it about the job title for prestige, is it about the presumed job security, about the additional pay, is it to rise the ranks to improve status? Maybe all - maybe only some. 

Or maybe the idea that the Want satisfies the need is an illusion?

The key takeaway here is - if there's a need, there is a want. Ignoring the underlying need will render attempts to satisfying a Want ineffective.

Incentives

Incentives don't directly affect needs. They work because they trigger (both positive and negative) wants: things the individual wants, in order to meet needs - and things the individual wants to avoid, in order to not have needs unmet.

An incentive always stimulates at least one Want. 

Positive incentives

Positive incentives give people the ability to satisfy their needs if they conduct a certain action. The most common form of positive incentive is, "Do your job, get your paycheck." Even a simple "thumbs up" from a coworker can be an incentive to try and go the extra mile. 

The strength of an incentive depends much less on the nominal amount of incentivization - much rather, it depends on the level of unmet need. For example, you won't entice Donald Trump with a Thumbs Up, but the new team member who's not certain of their position in the team yet may be willing to go great lengths to finally get the lead developer to nod in agreement of something.

Negative incentives

Just like positive incentives, we can find ourselves subject to negative incentives.  For example, the negative incentive "skip dinner"  attached to overtime plays on our Want to not be hungry.

In society, we use negative incentives to deter certain behaviours, such as fines (which affect people differently, depending on their wealth.) 

Explicitly phrasing negative incentives helps people discover which courses of actions are desirable and which are undesirable.

Managers quickly forget that there are almost always some negative incentives attached to their words: Even asking for a trivial thing might leads to the person feeling their status in front of their peers is diminished - a negative incentive, which people try to avoid.

The incentive economy

An economy is defined by wealth - in this case, we define "wealth" as satisfied needs.

In the case of incentives, we're dealing with promises of future wealth, hence, a value proposition to the recipient of the incentive.

Passive incentives

"What could be a passive incentive?" - well, that's an incentive created by doing nothing. Taking an extreme example, when a police officer continues munching donuts while a robber demands cash from the store owner, that's an incentive for the robber to commit further crimes. We see much less extreme examples in everyday's business world as managers fail to acknowledge the successes and contribution of their teams, incentivizing individuals to either cut down on performance (if stress is affecting their basic needs) - or to start hunting for a better job.

The nefarious thing about passive incentives is that you literally don't need to do anything to trigger them.

Ineffective incentives

The next type of incentives we're looking at are ineffective incentives. A positive incentive which doesn't address a real Want is entirely ineffective - as are negative incentives which don't touch a relevant need. This is also the reason why a pay raise for a person who's already fully able to meet their basic and psychological needs is pretty ineffective, as Dan Pink in his work, "Drive" figured out.

The same is true for "fun activity at work" while people are worried about not being able to afford the rent: it affects a higher-levelled need while there are lower-levelled Wants.

We can try to manipulate people by suggesting that they do have a certain Want, a typical marketing strategy. Here we can quote Lincoln, "you can fool some of the people all of the time, and all of the people some of the time, but you can't fool all of the people all of the time." Eventually, people will realize that an incentive doesn't affect their needs, and they will ignore it. That is especially true for  things often called "non-monetary incentives."

Likewise, when a person finds alternative ways of satisfying their Needs, the Want disappears, and the incentive fizzles. For example, new joiners will stop trying to achieve the recognition of their boss when they feel that the recognition of their peers means a lot more. 

Hence, long-term incentives that have alternatives tend to be ineffective. 

Perverse incentives

The final category of incentives are perverse incentives - these are different from the other categories.

When we try to incentivize an action, we usually try to do that to get a benefit from what they do. The term, "perverse incentive" comes into play when people have the Want, but the intended incentivized action isn't actually what people to in order to meet their need, and so they go to do undesirable things. "Cobra Farming" is a notorious example of a perverse incentive.

The problem with perverse incentives is that they work extremely well - just not in the way that the incentive-giver intended. 

And there's another problem: Perverse incentives are extremely common in complex organizations where the relationship between cause and effect isn't clear.

Setting incentives without connecting to the recipient's reality often leads to perverted incentives.  

Top managers coming up with broad-brushed incentivization schemes for people at shop floor level often realize this only when it's already too late.

Summary

Bringing it all together - we have to understand the real needs and how they can be met. We must learn to go beyond merely talking about our Wants.

From there, we must learn how to take care of each other's needs in effective ways.

That allows us to become explicit on the incentives that let us build "Win-Win" scenarios.

The Magic of Agile

One problem with "Agile" is that it often gets used as an excuse to avoid addressing the real problems in a straightforward matter. People resort to "magical thinking" - hoping that "Agile" somehow does some magic that will make the problem go away. And here's what's happening:

Clarity

In anything we do, we tend to look for predictability: what are we supposed to do, and what will happen as a consequence of what we do?

The coin toss

Let's start with something really simple: tossing a coin. 

You toss it into the air, let it spin, and call "heads" or "tails", and 50% of the time, you're right, 50% you're wrong. Straightforward enough.

Would you believe me if I told you that "if you throw the coin properly, it will turn into a helicopter and fly away?" Probably not. You won't believe me, because you know exactly what a coin and what a helicopter is, and how to toss a coin. There are no Unknowns here, and as such, you wouldn't accept my claim.

But now, let me change the topic:

The Project

Your company has started a project: to toss coins and turn them into helicopters. "Insane", you say. "No," your consultant responds: "we are in the Complex domain - a problem that we don't understand requires an approach you are not yet aware of. Since you can't rely on a familiar approach, you need to use an Agile approach."

Whereas formerly, we would have said "This won't work", now we have "Agile", and the plausibility of success immediately increases!

We have done nothing, absolutely nothing, that would lead to a helicopter as a result, and likewise have done absolutely nothing that would actually help you create a helicopter. All we did was introduce "magic" into the process by reframing the Unknown: "we have no idea how that's supposed to work!" becomes: "Agile will create the result!"

Comfort

Since we know very well that we're not getting a helicopter with a coin toss, we are quite comfortable to state, "That doesn't work." Now, if someone showed us how a coin turns into a helicopter mid-air, we would say, "I see the helicopter, but don't know how that works," (we increased the certainty of the outcome, but not in the approach) - and those of us with a growth mindset would likely say, "I want to learn how to do that!"

If your manager has given you 2 weeks to do it, your nerves would tingle. 

And now your manager tells you that unless you do it, you will be fired? Most likely, you'd be quite willing to try any advice on turning coins into helicopters.

What has happened here?

The further you leave your comfort zone, your willingness to accept magic as part of your mental model increases. When facing an existential threat, you'll more than happily try things you'd call nonsense under normal conditions: the plausibility of the proposal hasn't increased at all, only your perception thereof!

And this quite frequently happens with "Agile Transformations":

Magical Agility

Of course, turning "coins into helicopters" is a joke. Nobody would take that seriously. But what if our challenge was to turn:

• Dissatisfied Customers into Happy Customers
• Poor Time-To-Market into Fast Delivery
• Cost Pressure into Huge Savings
• Tons of Defects into High Quality
• Unhappy Developers into a Highly Motivated Workforce

Someone says, "when you're Agile, you can achieve all these". and now you're all - "Okay, bring on the Pigs in Pokes, let's get this going!" - especially when your job is at stake!

And that's where you get into the realm of Agile Magic. And that's when you need to stop and think.

Let's not get into the nitty-gritty that even if you're agile, you'll still have these problems, just that you will be able to deal with them better, and let's focus on the big hitter:

When your organization has no experience with achieving these, then "Agile" isn't going to change a thing about that unless you start doing your homework!

De-mystifying "Agile"

There is no unknown component that can't be explained. Everything is transparent. We know very well how to relate cause and effect. And where we don't know, we can explore until we do.

Problem -> Approach -> Action -> Outcome. Preferably highly repeatable and reproducible. No silver bullets, no miracle pills.

Where we can't copy+paste a solution from one place to another, succeeding with agility becomes harder, not simpler: we require experimentation and a willingness to fail - and a pretty good understanding on whether failure will lead to growth or be fatal.

There's no Agile ceremony, ritual or incantation that will grant you a magical Great Leap Forward.
You must get to work and clean up the mess you're in. 

Learn what causes you to get the outcomes you currently get, and what you need to do in order to get the outcomes you want. As you learn, you'll catch a bloody nose quite frequently, so bring plenty band-aid. (figuratively speaking)

Mundane agility

Find your own way forward:

Experiment. Fail. Learn. Repeat.

That's all there is.

The only shortcut I can offer: You are probably not the first person who has encountered a problem. Thus, you can often skip or at least reduce the "Fail" part by learning from others before you move ahead.

There are many bodies of knowledge that allow you to accelerate your journey: Engineering Practice. Process Management. Product Management. Quality Management. Supply Chain Management. Team Building. Just to name a few. Make use of whatever knowledge you can get a hold of.

Inspect and adapt until you're clear why you are where you are, and where and how you want to go next. When you don't know, you'll need to figure it out. 

The more you practice this, the more comfortable you become doing it.

The desire to seek magical solutions evaporates.

There is no magic in "Agile.".

Psychometry: Science, pseudoscience and make-belief

Let's take a quick glance at psychometry. Personality tests abound, and they've even invaded organizations' HR departments as a means of determining who "fits" and who doesn't. This, I claim, is something we shouldn't use in agile organizations - as these models are dangerous.

tl;dr:
Be careful what you get yourself into with psychometry. Chances are you're falling for something that could cause a lot of damage. Educate yourself before getting started!

Appealing, yet scientifically dangerous: The "Four Color Personality Types"

A brief history of  Psychometry

I will take a look at the models which survived history and are still around and in use today.

MBTI

In 1917, Katharine Cook Briggs and Isabel Briggs-Myers published a model which we now know as "MBTI", Myers-Briggs Type Indicator. with 4 traits in 2 different shapes each - resulting in 16 personality types.

DISC

In 1928, William Marston was tasked by the US Military to figure out why people with the same training still had different behaviour. The model identifies four key characteristics - D,I,S and C. Oddly enough, while the original model had "Dominance, Inducement, Submission and Compliance", today people can't even seem to agree what the acronym actually abbreviates.
Today, we see terms like Influence, Steadfastness, Conscientuousness as alternate labels - which means that depending on which meaning you assign to a letter, your scores would have a totally different meaning!

The Big Five (OCEAN)

In 1984, psychologists took a renewed interest in psychometry and Goldberg e.a. proposed the "Big Five" factors, Openness, Conscientuousness, Extraversion, Agreeableness and Neuroticism.
OCEAN spawned a few models on their own:

Occupational Personality Questionnaire (OPQ)

Saville and Holdsworth launched this model in 1984, and it's still in use today. This model is specifically focused on selection, development, team building, succession planning and organizational change. It has seen updates and refinements since its inception.

NEO PI-R

Since 1978 Costa and McCrae have developed the "(Revised) NEO Personality Index" which subclassifies the Big Five into six subcategories each. One of the key criticisms of this model is that it only measures a subset of known personality traits and doesn't account for social desirability of traits.

HEXACO

As the Big Five caught global attention, researchers realized that different cultures paid attention to different personality aspects, the Big Five were revisited, specifically due to feedback from Asia. Factors like Humility, Honesty ("H") and Emotionality ("E") have a much higher impact on the social perception of an individual in some cultures than in others, and therefore upon how a person sees themselves, as well.

HEXACO led to the interesting insight that there is no universal standard of measuring personality, as the measure depends on the social environment of the measured individual.
Likewise, HEXACO studies revealed that social acceptability determined desirability of traits, and that even the formulation of questions could yield different results depending on social context.

Scientific perspective

Companies have a keen desire to use a scientific approach in determining "best fits" for a new team member, in order to maximize the success rates of placing a successful candidate.
As ongoing research in the field of psychometry reveals, there is no comprehensive personality model, and therefore, no comprehensive personality test.
A comprehensive personality model would require both a large spectrum of personality traits and the social background.

Model Correctness

For the time being, the only factors that have been found to be universally accepted across cultures are extraversion, agreeableness and conscientousness. Everything else is up to debate. From the other side of the coin, this means that any model without these three dimensions can not be adequate.

Even the validity of the universally accepted factors is up to dispute. For example, Dan Pink stated, "People are ambiverts, neither overly extrovert nor introvert", or in other terms: our environment and current mood determines the expression of our "Extraversion" dimension much more than our internal wiring.

It's also unclear at this time how many factors actually exist, so every model we have focuses on a limited subset, and therefore expresses a current bias.

Valid Modeling

Scientists create, refine and discard models all the time. The goal is to have the best possible model, that is, the simplest valid statement with the highest level of explanatory power. The more widely accepted a model is, the more fame will be accredited to the first person disproving said model, that is: the bigger the crowd of scientists interested in finding flaws.

Counter-evidence

The first question when creating a model would be: Is our model valid? The scientific approach would be to look for evidence that the model is indeed not valid, and the model is assumed to be valid as long as no such evidence can be produced. Note that this neither means our model is good nor that it will remain valid when further information becomes available.

Models which have counter-evidence should not be used.

Explanatory Power

The second question to ponder is: How much does our model explain? There are two common mistakes regarding explanatory power of a model:
The first is the category error, that is - to use the model to explain things which it isn't intended to explain, such as using a model that was designed to explain individual behaviours in an attempt to explain social interactions.
The second mistake would be to use the model outside its precision. For example, a model that already fails to address the cultural differences between Asia and Europe would be inadequate to compare the behaviours between a person from Asia and a European.

Preference goes to the simplest model with the highest level of explanatory power required to address a subject.

Reliable Measurement

To be considered "reliable", a scientifically valid measurement would need to be:

• Accurate, that is, it should generate outcomes that align with reality.
• Repeatable, that is, a test under the same preconditions should generate the same outcome.
• Reproducible, that is, testing the same target in different environments should generate the same outcome.

The lower any of these three attributes is, the less reliable a measurement would be. Reliability of a measurement system = Accuracy * Repeatability * Reproducibility, i.e. the predictive capability of data diminishes rapidly as these factors dwindle.

Measurement systems ("tests") with low reliability should be avoided or improved.

Pseudoscience

Models which lack supporting evidence, have already been debunked, which have low explanatory power or which are based on unreliable metrics are generally considered "pseudoscience".
Statements based on such models would be considered doubtful in the scientific community.

The reason why older models, first and foremost, MBTI and DISC, despite their high (and often re-trending) popularity would be considered pseudoscience, is that they lack explanatory power and reliable measurement.

While some models claim high repeatability, many people have expressed doubts whether personality tests are sufficiently accurate.
Some assessments might even claim that "you have a family profile and a job profile", essentially surrendering reproducibility, and therefore, scientific validity.

As mentioned before, even the very refined HEXACO model suffers from a lack of explanatory power, and depending on how a test is configured for a specific environment, this specific configuration might have little supporting evidence or even generate counter-evidence.

Therefore, it stands to debate how useful psychometry could be to make statements about a person's workplace behaviour.

Make-Belief

The key criticism in regards to most psychometry tests is that a personality report from these models is a kind of a Barnum statement - people who read their report suffer from a Forer effect: Reports generated by random data might be perceived equally accurate as reports made by conscious choice. People look for the attributes that feel describes them "fairly well" and overlook the passages that aren't suitable.

Tests based on MBTI and DISC profiling suffer specifically strong from this - either their statements are so vague that they could describe technically anybody, or people would feel that whatever outcome is attributed to them is not universally applicable, or doesn't suit them at all.

The "explanation" for this vagueness tends to be that factors are fluent and exist in different levels of manifestation, which basically makes a binary classification meaningless.

The effect on people

In a statement on one website, the claim was "The outcome of the test can affect your life", which is indeed true, especially when the test is being used for job selection and you didn't get hired because you didn't show up as what the hiring person was looking for.

Using the models

The only point I give to the models is that test results can be a decent conversation starter with your team, friends or family - although I'll put that point into abyeance, because likewise could be a relevant subject matter or even the weather.

Harmful application

This is where I get into the realm of "coaching". Some coaches peddle certain models as "strongly supported by science", which indeed aren't - and people who lack a scientific background will use these models as if they were.

Especially "The Four Colors", which are pomoted worldwide in management seminars and which are now also finding their way (in one form or another) into Agile Coaching pave the way for dangerous dynamics.

The worst application of the model I have seen are "helper cards" used by people to categorize the other people in the room during a conversation.

Promoting ignorance

There is no simple way to classify a person's behaviour within an sociotechnical system. Every model that claims to have an easy answer that utterly ignores environment is dangerous - because it focuses on the consequence while ignoring the trigger. Without educating people on the impact of environment on behaviour, psychometry becomes a distraction rather than a means of understanding!

Thinking inside the box

People are complex, very complex indeed. As a proverb from Cologne states, "Jede Jeck is anders", roughly translating to: "Every human being is different" - you just can't put people into boxes.
There's also a high probability that behaviours you observe or how you judge those behaviours are tainted by your personal bias. As long as you think of people in such boxes, you're very prone to miss important nuances.

Manipulation tactics

When I was taught DISC a decade ago, I learned that people with a strong "D" dimension respond positively to terms like "Fast" or "Effective", whereas they get put off by details. Same for other dimensions. As such, I have learned to use the DISC model as a means to use language to manipulate people to agree with me.
As helpful as such knowledge can be to make decisions, as deceptive it can be - because this sets up people for manipulation and exploitation. Is this where you want to go in coaching?

Missing the Big Picture

Psychometric models focus on the individuals, ignoring their role in their environment. Strangely enough, my first question when sitting in a DISC training was, "There's this person who's strong in all four dimensions. What's that?" During the training, I just swallowed the anwer, I didn't understand the consequences until years later: "This person is an adaptor. They display the strengths that the current situation requires."
Later, it hit me like a concrete block: People adapt to their environment. Their social role determines which strengths they will exhibit. And as their role changes, their visible profile changes as well.

As such, we can't measure a person at all, we just get a glimpse of where that person currently stands in society. Change that role, and their psychometry changes. And that role changes as circumstances change.

You can change a person's social environment to turn an inspiring leader into a tyrant.
You can change a person's belief system to turn a braggart into a humble person.
You can affect a person's incentives and turn a couch potato into a sportsman.

How much do you then think that a few dozen questions will tell you about what a person could be?

Building the wrong team

Some organizations try to build teams with a "suitable" mix of personalities and ignore that their psychometric data is a poor representation.
Psychometry can be flawed from three angles:

1. The test itself wasn't an accurate representation of the person's beliefs and behaviours.
2. The test outcomes were inaccurate to describe the person's beliefs and behaviours.
3. The test ignored the current social dynamics leading to a person's behaviours.

People's behaviours and dynamics depend on context. Hence, planning based on psychometry makes unsupported assertions about the future state of the team.

How ridiculous would it be to ensure that each team is built with one Red, two Green, two Blue and a Yellow - only later to discover that a Green adapted to that role and is otherwise Red, and that the Yellow was only Yellow back when they were hired?

Making concessions

In some cases, inappropriate use of profiling other people based on observations can be used to "excuse" negative behaviours and unhealthy group dynamics. For example, bullying might be considered the conseuquence of "expressing strong dominance", and the behaviour itself or the systemic enablers might continue unquestioned.
Likewise, people with "strong agreeableness" might accept immoral behaviours, when they should be encouraged to take a stand and fight for change.

Summary

This article explains why many approaches to Psychometry are scientifically invalid, why psychometric data should be treated with caution and why coaches should be utterly careful when meddling with psychometry in their work.

If you use or plan on using psychometry in coaching, be careful of the problems you are inviting.

Ten dysfunctional Scrum Master patterns

There's a lot of material out there on what a Scrum Master allegedly is and does, although many of the tips are indeed antipatterns that will keep the team from ever reaching top performance. So let's take a look at what a Scrum Master is NOT. Here are ten dysfunctions in the Scrum Master role - and better alternatives!

The nurturing parent

A recurring theme with Scrum Masters who think they're doing a good job while actually achieving the opposite is that they take the role of a parent for the development team. The term "Scrum Mom" has been coined as an antipattern, although the issue goes much further and deeper.

Brief detour into psychology
Let me refer the unaware reader to Eric Berne's book, "Games People Play" for the full mechanics of Parent-Child dynamics. For brevity sake:

Eric Berne suggests that people are always in one of three so-called "ego states" - Parent, Adult or Child. Transactions among adults or between parent and child are "stable". Others are "crossed" (i.e. broken / unstable). Consequently, by assuming a "parent" role, one pushes others into a "child" role and vice versa.
The more frequent this happens, the stronger a parenting Scrum Master will instill childish behaviour and attitude within the organization!

The blue transaction among adults is "stable".
The crossed brown transaction is unstable - the trigger doesn't match to the response!

The Pamperer

To paraphrase Atlassian, the Scrum Master may want to do any kind of thing that's required to get the team to hum - fixing hardware, changing room temperature, bringing coffee and whatnotever.
This brings us into the "I'm only trying to help" game described by Berne: Team members get used to absolving themselves of taking care of their own basic necessities.
This eventually brings the Scrum Master in a defensive position: They constantly have to guess what other people need, and if anything goes wrong, developers might turn against the Scrum Master with blame.

Adults find taking care of their basic needs part of their own identity, and will enjoy an environment where they can do this by themselves: It instills a sense of autonomy and control.
The Scrum Master should get NEAR to the team, help them become aware of their own needs and build an environment where people can meet their own need with little effort.

The Protector

A common misconception is that the Scrum Master should cotton-wrap the team in a cozy little bubble, safely protected from "the mean outside world" so that developers can focus on writing software. This creates two separate issues: First, developers lack the interactions and understanding to figure out what's going on around them. Second, it creates another unhealthy mechanic: Dependency. Developers become unable to cope with the surrounding organization, relying on the Scrum Master.
Again, the Scrum Master ends up fighting a losing battle: If they do a perfect job, everyone will push organizational issues on them - and if they make the slightest mistake, they will be blamed for inadequacy.

The Scrum Master's responsibility is to educate people - both within the team and around - which interactions are helpful and which aren't. Avoid the trap of buffering these interactions. Unhelpful interactions cause conflict, and defusing this conflict is part of the growth process. Learn conflict resolution techniques.

The Facilitator

Yet another common misconception is that the Scrum Master has to organize things for the team - such as, when meetings take place, who is invited and what the agenda is, then to facilitate the show. This is just a specific form of pampering - developers assume that the Scrum Master knows best (sly "Tangled" reference) about meetings.  Continuously organizing or facilitating meetings is not a Scrum Master responsibility, lest we fall into the "TAGAWI" game where meetings won't be held if not for the Scrum Master. Especially new Scrum Masters will not realize that they're falling for a game and thus are very likely to lose.

The Scrum Master's responsibility is educating developers initially why and how to conduct Scrum events like a Retrospective, so that they can learn the importance of these meetings and how to make them valuable. Instead of organizing meetings, the Scrum Master is well advised to let developers take this responsibility and help them sustain this practice.

The decision maker

In many organizations, a Scrum Master may make decisions either as a surrogate manager, a spokesperson or as representative of the team. While it's valid that the Scrum Master represents a decision that has already been made, the Scrum Master is not a decision maker!

The Surrogate Manager

When teams move to self-organization, they may occasionally feel lost, because decisions that were made by others for them now lie with the team. As such, they might look to the Scrum Master to fill this decision gap. It does provide a sense of safety and comfort to let others make decisions in times of turmoil - even if that decision is wrong, the responsibility rests elsewhere. Long story short, if the Scrum Master caves in, they fall for a parent role, stopping the team from becoming truly self-organized.

The Scrum Master might want to explore with the team "Why" the team wants the Scrum Master to make this decision and "What" will happen as an outcome. By facilitating the right discussions, the Scrum Master empowers the team to make their own decisions and live up to it - propelling self-organization!

The Spokesperson

Developers may also ask the Scrum Master to fetch a decision that rests elsewhere in the organization. Terrible Scrum Masters will assume that they can make a decision instead, which will put them into the worst possible position: if they get it right, they still usurped another person's position, if they get it wrong, everyone will blame them.
Bad Scrum Masters will run off diligently to find out from the decision maker. They just fell for a game: the team plays the "helpless child" and looks to the Scrum Master for a solution.

Rather than acting as an intermediary, the Scrum Master should build networks of people, connecting others directly. If needed, the Scrum Master may need to act as a facilitator in meetings so that a mutually acceptable solution can be worked out.

The representative

In a video by Atlassian, they suggest that the Scrum Master should represent the team in backlog refinement. While it's okay for the Scrum Master to represent a specific decision the team has already made, the Scrum Master lacks the understanding of content and technical background to communicate details on behalf of the team. As such, the Scrum Master is always guessing and still likely to make mistakes.
It's very misguided to believe that a non-technical person can decide on technical details, and the details are what makes or breaks the outcome. This sacrifices effectiveness in the name of "efficiency", turning teams into "delivery factories" (another parent-child dynamic).

When teams keep out of meetings which provide an opportunity to acquire essential information and provide essential feedback, there is probably a strong parent-child dynamic at work - either developers are being pressed into a "child mould", or they are themselves in child mode and press others (for example, management or the Product Owner) into a "parent mould".

The Scrum Master should carefully examine why this is happening - oftentimes due to fear or negative organizational culture.

The bouncer

I cringe whenever I hear that a Scrum Master should act as bouncer, shooing people away from the team. Why? Because people have needs. When others feel the need to interact with the team and get called off, this will most likely trigger resentment and other negative emotions which will eventually have a backlash. Acting as a bouncer, the Scrum Master creates two separate parent-child dynamics: Towards the team (sheltering) and towards the outsider (controlling communication).

The Scrum Master should get NEAR to the approaching person, then learn why this need exists and how it can be met. One-on-one interaction can build a more positive working environment and may lead to different solutions than what the approaching person originally intended.

It's incredibly important for the Scrum Master to help others, irrespective of whether within or outside the team, to find ways to meet their needs on an "Adult" level.

The Ambassador

Occasionally, the Scrum Master may be asked or feel tempted to represent the team towards outsiders, so that the team doesn't get interrupted. This makes the Scrum Master a filter of information and a translator, both of which can become incredibly dangerous.

What a Scrum Master may do is have first discussions to see if the interaction is indeed helpful for the team and the organization, and if this is the case, they should bring people together directly in the most effective way.

Further reading

I have hinted at the book "Games people play" by Eric Berne.

Other books in this context are:

• TA Today by Ian Stewart and Vann Joines.
• Transactional Analysis in Psychotherapy by Eric Berne.
• I'm OK, You're OK by Thomas Harris.

Note that the reading of these books will not make you a professional therapist or psychoanalyst, and I strongly encourage you to stay out of trying to do therapy or wielding this knowledge as a tool - although understanding these things gives you a much better understanding of what's going on. 
Do NOT, and I can't emphasize this enough, do not start calling out transactional dynamics within your team or use TA interventions loosely. You're going to leave a trail of devastation.
Much rather, I invite you to silently reflect on how you are contributing to the situation and what you yourself can do to improve.

Want trust? Deal with fear!

"Fear is a bad advisor!" - proverb.
Positive working environments require trust. Trust can be given and earned - it can't be forced or demanded. Team building workshops often focus around building trust. Are they dealing with the symptom of distrust, though?

Here is a causal loop diagram modeling the relationship between trust and fear:

Red lines = dampening effect, blue line = strengthening effect. "=" sign = time delay

There is a direct relationship between trust and fear: Fearful people don't trust. Trustful people don't fear. Then, how do you get from A to B? It's not as easy as extending trust, although that helps.

The vicious circles

In the model, we see three different vicious circles which need to be broken almost simultaneously before trust can be established. I also hint a way to break these vicious circles.

Blame Games

Starting on the top left, the most visible fear cycle is related to Blame. Nobody likes to be blamed. Being afraid of blame, people hide their mistakes. in consequence either finding someone else to blame ("But you said ..." - "X told me...") or, when caught, receiving blame. Positive management must end blaming people. Blame helps nobody. Identifying someone responsible should never be aimed at having someone to blame, it should always be aimed at finding a way to change things for the better.
As coach, I have even resorted to the rather ridiculous tactic of saying "Ok, it's my fault. Now, how can you make sure it doesn't happen again?" - of course, it's ridiculous that it's my fault. That's not what matters. What matters is that the discussion about fault ends and we start talking change.

Coverups

The next vicious circle is related to information hiding. It's much harder to spot, as one can't know what one could know but doesn't know because it's being kept secret.
It takes a lot of sleuth work to put missing pieces together and discover where people are covering up inportant information revealing what is really going on. Why do people do this? Often, they either don't trust what will happen when uncomfortable facts are revealed - in which case it's a trust issue, or they know what will happen and don't like that - in which case it's a fear issue.
People wouldn't be afraid if failure was not perceived as a stigma with negative repercussions. Establishing a positive failure culture, "Hooray for failure" can go a long way. Just make sure that this Hooray is then hooked up with real learning and change - otherwise, a team member's trust in the team can turn into an outsider's distrust in the work of the team.

Choking Control

The third vicious circle is related to controls. Be that meetings, reports, supervision or checklists. While every single of these isn't necessarily bad, in sum, they can devastate people's ability to think, act and change. One control may be no issue, a hundred controls make it impossible to change anything - and simultaneously, often create a self-contradictory system where at least one control is always broken. People are constantly afraid of breaching control and spend more time on meeting control requirements than on doing actual work which helps the organization.
Managers stop trusting their employees when controls are broken, and employees stop trusting their managers when broken controls don't lead to more effective ways of working, but more controls. At worst, managers also stop trusting their controls when these prove ineffective and load yet more controls to control the controls.
Creating transparency what is truly going on and which processes are actually enforced by these controls can go a long way in abolishing their destructive force and minimizing control to truly helpful levels.

Conclusion

"Don't fear" or "We can trust one another" are hollow slogans. These don't help anything. "Building trust" without understanding the vicious circles and loopback dynamics leading to the low levels of trust we often observe in organizations.
The main lever for raising trust isn't simply building trust, but alleviating the fears which constantly chop at any small flower of trust sprouting up.

As coaches, we must understand both the fear dynamics and the fears driving people. Only then can we build the trustful environment needed to succeed.