Skip to main content

From a Blame Culture to Fearless Trust

As a manager, you understand the second principle of Radical Management: your role is changing from being a controller of people to an enabler of teams. In my coaching work, I've met many managers who, even though they understand this principle, they get really uncomfortable with relinquishing control.
If I trust my team, how do I prevent them from abusing this trust? How do know I will I get results?
This is a perfectly normal question at the beginning of a transition, especially in large organizations. What is trust? How can you trust your people? And how do create a climate that encourages trust?

Without trust, people have to protect themselves from betrayal and attack. Work is a dreary grind, in which people are constant fear of punishment, and the workplace resembles a Dilbert cartoon with slightly more lifelike renderings of the people involved. In fact, if Dilbert is a favorite subject for decorating people's offices or the coffee corner, then you probably have a problem with trust and fear in your organization.

A company living a trust culture can be a wonder to behold! Happy, motivated staff working effectively with each other, with stakeholders, with managers and even with customers to produce great outcomes! Is your company like this? Stop and imagine for a moment what it would be like...!

Trust means a lot of things to different people. Let's look at the different kinds of trust in an organizational context:
  1. Blind Trust: Don't worry, be happy! It will all work out in the end.
  2. Commitment Trust: I say I will do something and you can have confidence that I will do it.
  3. Confidence Trust: You can tell me something in confidence and can be sure I will not betray that confidence.
  4. Alliance Trust. You and I commit to a course of action and we both have confidence each will stay the course, even in the face of political resistance.
  5. Fearless-Trust: I can admit weakness without fear of attack.

Blind Trust
Blind trust is what every manager is afraid of, and rightfully so, especially when s/he will be held accountable for the results.

It's a common fear that Radical Managers must engage in blind trust. Let's look at how Scrum addresses this issue:
  1. A Team commits to a achieve a "sprint goal" within a defined time box of one month or less. The goal was requested by a special management role, the Product Owner. Only items representing potential value for the customer or user are normally defined in the sprint goal.
  2. At the end of the time box, Product Owner and Team review the results.
  3. The product owner may not change the sprint goal until the time box has expired.
If the team achieves the goal, everyone is happy. If not, it is a learning experience for all concerned. In the future, the team may commit to less (overly) ambitious goals and/or the team will seek to eliminate impediments which limit its capacity.

Radical Management calls this process Dynamic Linking. I prefer the expression Direct Linking because people seem to grasp the essential idea more quickly: The people doing the work have a direct line of site to the beneficiaries of their work. The results are visible in form that the customer can understand after a short period of time. After a learning phase, when the team learns what it can really do in one month, the team should be able deliver what it promises, month after month. The manager can now focus on managing outcomes, not inputs, outputs or coffee-breaks.

Commitment Trust

When I ask groups of managers and team members what trust is, their answers often refer to Commitment Trust. This is more or less the main dictionary definition of trust. Managers want employees to do what they say they will (e.g. show up for work, deliver on commitments on time, etc.) and management's control function is to ensure that they do so.

Commitment trust is closely related to delegation and accountability. As manager, what can you can you delegate and to whom? How much do you need to be involved in creating, validating, verifying the results?

Jurgen Appelo has created an excellent tool for visualizing and discussing delegation as part of his Management 3.0 Training: Delegation Poker. (BTW - I am a Management 3.0 Licensed Trainer). He identified 7 levels of delegation ranging from
  • Level 1 — Manager decides and communicates his decision, to 
  • Level 7 — Manager delegates and does not even inquire about the results). 
So given a task, you can identify how much competence you wish to delegate. You can reflect on how and whether you want to develop your staff so they develop the ability and/or earn the reputation necessary for higher levels of delegation. And you can put display a delegation matrix on the wall, making the policy visible, transparent, and easy to adapt when needed.

BTW — A Scrum product owner works at about Level 6: Manager delegates and inquires about the results.

Confidence Trust 
When I talk to individual employees, I am often confronted with Confidence Trust. For instance, "You didn't hear this from me, but...." There is an issue, but s/he is not allowed to mention it in public for fear of the consequences.

There will always be a need for discretion. Particularly discussing about individuals and personal problems requires sensitivity. However if people in your organization rely frequently on confidence trust when discussing what should be factual issues, this is a sign that a culture of fear is preventing a free flow of information in operationally or strategically important areas.

Alliance Trust

Every successful manager understands the importance of Alliance Trust. It's often the only way to get things done in an organization. Build alliances to help each other advance. Build consensus to ensure decisions

Like with confidence trust, there will always be affinities between people and relationships that endure over time. But what decides key decisions in your organization? The positional power of the people involved or the power of the arguments brought to the discussion (especially in context of what's best for your customers)? And when a decision is taken, do the proponents of the road not taken commit to the decision? Or do they wait for the chance to say 'I told you so!'

One symptom of too much reliance on alliance trust is an inability to make decisions or set priorities.

This often manifests itself as constantly shifting priorities in the organization. One faction has the upper hand and gets a decision in their favor, but the losers don't give up. A dramatic event (real or imagined) causes a shift in the priorities and the decision changes. Running projects are canceled and 'resources' are reallocated. This is a nice way a saying that you have wasted a ton of money and a lot time on unfinished work which will never delight the customer or produce a return for the company.

Fearless Trust is like Fearless Change. Fearless change is not about a daredevil's approach to change. It is about change without fear, i.e. taking the fear out of change. A trust culture is about taking the fear (and politics!) of out of work, so people can focus on the real issues.

Only once have I coached a company that had an explicit policy of Fearless Trust, also known as a Trust Culture, before I started working with them. This was the easiest and most delightful transition I have ever had the pleasure to assist. People were willing to learn and try out new things. They were not afraid of the consequences of trying something which might not work out as planned (because they will not punished for trying) so the hurdles to trying out Scrum were very low. They also tripled their productivity almost instantly and made tremendous strides in improving customer delight from the first product release onwards.

The alternative to a trust culture is a blame culture, in which people are held responsible for mistakes. The most immediate symptom of blame culture is whenever anything goes wrong, the first order of business is identifying the guilty party. Those accused focus on deflecting the blame to someone else. The loser gets to fix the problem. I believe that most companies have a blame culture, because this is natural side effect of emphasizing individual performance over team performance.

Why should you foster a trust culture? Simple! In trust cultures people don't waste time and energy looking for guilty parties or defending themselves from attacks. People don't choose CYA strategies over doing what's best for the customer. People can commit to decisions - even those they did not agree with  - and hold each other accountable for delivering. (For a deeper understanding of trust cultures and the dysfunctions associated with blame cultures, check out The Five Dysfunctions of a Team, by Patrick Lencioni.

In my next article on trust, I want to look at how to create a trust culture in your company.

Are there other aspects of trust in an organization that I overlooked? And how have you experienced the flavors of trust in your company?


Anonymous said…
nice article and blog, thanks. I have a cognitive bias on this so I couldn't agree more on the trust issues! It is a delight to be able to say "I made a mistake", accept it, find acceptance and then just fix it. We're humans after all ('people over processes')

kind regards,
Rolf Vreijdenberger

Popular posts from this blog

Sample Definition of Done

Why does Scrum have a Definition of Done? Simple, everyone involved in the project needs to know and understand what Done means. Furthermore, Done should be really done, as in, 'there is nothing stopping us from earning value with this function, except maybe the go-ahead from the Product Owner. Consider the alternative:
Project Manager: Is this function done?
Developer: Yes
Project Manager: So we can ship it?
Developer: Well, No. It needs to be tested, and I need to write some documentation, but the code works, really. I tested it... (pause) ...on my machine. What's wrong with this exchange? To the developer and to the project manager, "done" means something rather different. To the developer in this case, done means: "I don't have to work on this piece of code any more (unless the tester tells me something is wrong)." The project leader is looking for a statement that the code is ready to ship.

At its most basic level, a definition of Done creates a sh…

Explaining Story Points to Management

During the February Scrum Breakfast in Zurich, the question arised, "How do I explain Story Points to Management?" A good question, and in all honesty, developers can be an even more critical audience than managers.

Traditional estimates attempt to answer the question, "how long will it take to develop X?" I could ask you a similar question, "How long does it take to get the nearest train station?

The answer, measured in time, depends on two things, the distance and the speed. Depending on whether I plan to go by car, by foot, by bicycle or (my personal favorite for short distances) trottinette, the answer can vary dramatically. So it is with software development. The productivity of a developer can vary dramatically, both as a function of innate ability and whether the task at hand plays to his strong points, so the time to produce a piece of software can vary dramatically. But the complexity of the problem doesn't depend on the person solving it, just …

Money for Nothing, Changes for Free

“Money for Nothing, Changes for Free” encourages both customers and suppliers to focus on value.

A key advantage of Scrum projects is that at least once per sprint you have something that could be shipped and no work in progress. You can change direction every sprint, and you can reevaluate whether the project is a good investment or if your money could be better spent elsewhere. Abrupt cancellation is risky for the supplier.

While the concept of an early-exit penalty is not new, Jeff Sutherland gave it a unique allure with his allusion to the Dire Straits hit.
Desired Benefit Incentivize both customers and suppliers to focus on functionality that provides genuine value.
Structure This works with Agile software projects because there is little or no work in progress. After each Sprint, functionality is either complete or not started. Work is basically on a Time and Materials basis with a cost target, often with the intention that the project should not use up the entire project budge…