Leadership Tip #11: Substitute the Word Trust for Empower

We talk a lot about empowered or self-organizing teams in the agile community. However, I don't see too many self-organizing or empowered teams at my clients. Not because my clients are stupid—far from it. Everyone does the best job they know how to do. However, every manager's micromanagement pervades all levels. Instead of talking about empowerment, let's discuss how we trust teams and people to do their best job.

We can start with some of the most basic items of trust at the team level: the team's board.

Can Your Team Change Its Board?

When Mark Kilby and I wrote From Chaos to Successful Distributed Agile Teams, we said the easiest way to create a system that worked for the team was for the team to create its own board.

Imagine our surprise as we learned that many teams had to use a “standard” board. Management—not the teams—often chose a Scrum board with three columns.

That board will work for you if you have little interrupting work, enough hours of overlap, and the team is good at predicting what they can do in a couple of weeks of time. In our experience, too few teams can do any of that (regardless of their location).

Why do managers persist in demanding teams use a “standard” board, or use “standard” metrics, such as velocity?

Because the teams are not empowered. Managers don't trust the teams to do their work. (And managers don't realize inspect-and-adapt is a necessary part of an agile culture.)

The board problem is the same problem as “Everyone must use agile,” even if an agile approach is wrong for your team.

Can Your Team Choose Its Approach to the Work?

Teams have many approaches (see the lifecycle series) from which to choose. I've said before:

  • The more deterministic your work is, the less you need an agile approach. (See the 6th part in the lifecycle series.)
  • Agile Approaches Require Management Cultural Change. An agile approach does not affect just the project—the approach changes the entire organization.  (Which is why we see so much deadly “agile” in name only.)

If your team can't choose its board or its project approach, you don't have empowered teams.

Which Policies and Procedures Govern Which Decisions?

Several years ago, I worked with a client who said, “If you want to get reimbursed for your travel, you must only take taxis.”

I reminded them that fixed-price limos often cost less than taxis. No, they had none of it. Then, the person I spoke with said, “We would really appreciate you setting an example while you're here.”

Okay. I thought I'd try.

The first morning of a two-day workshop, the taxi picked me up, put all my stuff in the trunk, and then the door closed locking his keys in the taxi—and all my stuff.  I was over an hour late to the workshop.

That was the last taxi I took while at that client. The waste of my time and theirs overwhelmed all the potential cost savings. (And they reimbursed me anyway.)

Why did they have this policy? At some time in the past, someone abused the limo policy. Everyone continued to pay for it.

This taxi policy was just as useful as these policies I see:

  • Change theater: When a change control board full of managers who no longer know what's in the code or tests decide what to release and when.
  • Deployment theater: When the deployment team tests what the product teams created and sends the product back to the teams because the deployment team doesn't understand.

I'm sure you have more examples. Anything you think of as bureaucracy? Those are policies and procedures that have outlived their usefulness.

It's time to change who gets to decide what.

Who Decides What in Your Organization?

If you want to empower your teams—trust them—they need the autonomy to make most of their decisions without a manager.

Here are decisions you can trust the team with now:

  • How to approach their work. Their lifecycle or agile approach, any estimation/forecasting, their technical practices. You might not like their answers. However, they need the practice to make better decisions. Start now.
  • The tooling they need and how they want to use those tools. If you worry about the cost of tools, explain that you don't know and you need their help. Even if you feel you must impose a tool on the team, give them administrative permissions so they can use it the way they want to.
  • Who they want on their team. If your team does not decide who to hire, you're not leveraging all their knowledge. (See Hiring Geeks That Fit.)
  • When they need training.

Once they realize you're serious about trusting them, they might want more practice on almost everything.

The more managers decide for everyone, the less the managers trust anyone. That's why trust is the path to empowerment.

The “Secret” to Trust

If I had to choose a “secret” to trust the people you lead and serve, it's this:

How little management can you do?

(See Apply “How Little” Thinking to Agile Management Control.)

That's it. Reduce your micromanagement and management actions. Work on the system, not the work itself.

This tip is mostly from Practical Ways to Lead an Innovative Organization.

This is a part of the series of intermittent leadership tips.

2 Replies to “Leadership Tip #11: Substitute the Word Trust for Empower”

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.