There is much more to empowering a team than simply stating “You’re empowered.” Consider the three Ws of empowerment: “what,” “when,” and “why” when creating boundaries that define which decisions are the team’s and which need management approval. Without that clarity, there’s a risk of becoming a yo-yo manager–one who talks about empowerment, and then yanks the leash. And that destroys trust, as this story illustrates. You can avoid Bob’s fate by following Sue’s advice.

Bob Empowers His Team

“I want you to be empowered,” Bob told his team at the team meeting. But several weeks later, Bob expressed his disappointment to his colleague Sue. “My team members have a victim mentality,” he said. “They’re too passive. They wait for the team lead to tell them what to do. And the team lead checks everything with me. I want these people to show some initiative!”

Sue cocked her head. “What have you seen that makes you say that?”

“You remember the middleware bug we had last month?”

Sue nodded.

…And Then Un-empowers Them

“Well, the team came up with a solution that was all wrong,” Bob said. “It’s a good thing I caught it before they forged ahead. If I hadn’t wandered into the team room and seen the diagrams on the whiteboard, I never would have known about it.”

Sue raised an eyebrow.

“I called the team into a huddle and explained why that idea wouldn’t work. Then I had a meeting with the team lead. I really dressed him down. He should be leading them–not letting them make stupid mistakes.”

Sue’s other eyebrow went up.

“I want the team to dig in and solve problems–really be empowered,” Bob said. “So last week at the team meeting, I asked everyone to offer at least one idea about how we can meet the deadline for our next release without dropping any features.

“One of the team members actually said it was impossible. Another suggested we could implement a partial solution that included some manual work in the customer care department. When I told her that she hadn’t examined all the issues with her approach, she backed down! How can we come up with creative solutions if we can’t argue our ideas?

“Now they just sit there. It’s like they are afraid to make any decisions at all.”

Sue Asks a Question

Sue held up her hand to stop him.

“Bob,” Sue said, as gently as she could, “do you think you might be sending mixed messages?”

Bob looked puzzled. “What do you mean?”

“I wonder how your team members felt when you overrode their technical design.”

“I saved them from a big mistake,” Bob said. “I’d think they’d be grateful.”

Sue shrugged. “Maybe. And I bet they also felt like you told them the decision was theirs to make, and when they didn’t do what you wanted, you took the decision back.”

“But what they were planning was wrong!” Bob exclaimed.

Sue nodded. “Their solution might not have been very efficient. But it might have been more effective in helping team members learn how to think through the issues together. They are new to this and still need to learn through experience.

Sue Reminds Bob about Bounded Autonomy

“Do you remember when you were learning how to drive?” Sue asked.

“Sure. My dad took me to a big, open parking lot and gave me instructions: Ease up on the clutch, press the gas pedal gently. After I mastered the clutch, he took me out on a quiet road.”

“And after you received your license, did he let you drive anywhere, anytime, with no restrictions? Were you completely empowered to drive any where, any time?” Sue asked.

“Of course not. At first I was allowed to drive to school alone, and later I was allowed to drive after dark. It was months before my dad let me drive with my friends in the car. At the time I hated it, but looking back, he was helping me build my skills before he turned me loose.”

Bob Sees His Mistake

“Exactly,” Sue said. “And that’s what you didn’t do with your team. In essence you told your team members they could drive anywhere. Then, at the first small mistake, you pulled their license and showed you didn’t trust them.”

“Oh,” Bob said. “I never thought about it that way. You mean I’ve actually brought about exactly what I didn’t want? I’m making the team more passive instead of more empowered?”

“The key to empowerment is to tell team members what the boundaries are before they cross one by accident,” Sue said.

“Otherwise, they’ll feel jerked around,” Bob said.

Sue Explains Constraints

“Exactly,” Sue said. “If you really want to empower your team members, you need to consider their skills and how much you trust them. Find the boundaries where you feel comfortable with the risks and give them free rein within that area. That’s probably not the empty parking lot where your dad started your driving lessons, and it’s probably not the freeway during rush hour, either.”

“I have to work harder at this empowerment thing than I thought,” Bob said.

“There’s more to it than declaring, ‘You’re empowered,'” Sue agreed. “I think about the three Ws of empowerment: what, when, and why.

“What delineates the decisions and the standards that apply when making those decisions.

“When defines boundary conditions. For example, my test team can make decisions about test approaches. However, when they want to try a testing approach that requires a new tool that costs over $10K or replaces a functioning test framework, then they come to me with a recommendation.

“Why sets the context. I find that when people see how their decisions fit into the big picture and may affect customers and the bottom line, they make better decisions.”

“I can’t just go in and tell them what the boundaries are now,” Bob said. “They won’t believe me.”

“You’re right, Bob. First, you need to rebuild trust, and the best way I know to start that process is to admit you’ve made a mistake. Then you can work through which decisions belong to the team, which you share, and which need to stay with you.”

Bob gave Sue a pained look.

Bob Clarifies the Boundaries of Empowerment

The very next day, Bob called a team meeting. “I’ve made a big mistake,” he said. “I asked you to make decisions and offer ideas, and then I stepped in and took over. That was wrong of me. I was worried about looking bad, and in the end, my actions made us all look bad.”

Several team members looked down at the table. The team lead squirmed in his chair.

“Are you willing to try again?” Bob asked. “I have some ideas on how we can all be clear on which decisions are yours and which decisions are mine.”

Tentatively, the team agreed. Together, Bob and his team created a grid that listed decisions and boundaries.

Bob realized that he wasn’t ready to let go of every decision. He specified some areas where he would make the decision based on the team members’ input and some cases where he wanted to review their decision before they implemented it. He was surprised to see that team members were grateful that they wouldn’t have to carry the weight of all the decisions.

Bob asked the team to remind him if he started stepping over the boundaries he’d set.

It took some time for the team to trust him again, but eventually the team saw that Bob really meant what he said. Bob realized that the team was gaining skill and perspective in making decisions. They weren’t always the decisions Bob would have made, but he had to admit the team’s ideas and choices worked out reasonably well–most of the time. And when the decisions didn’t work out as hoped, the entire team held a decision retrospective to learn from its mistakes.

Several months later, Bob went out to lunch with Sue. “The team is making better decisions and seems to have more ownership of its work,” he said. “Once we agreed on the boundaries, the team stepped up. Empowerment really can work,” Bob said. “But it works best when the what, when, and why are clear to everyone involved.”

---

This article originally appeared in Better Software magazine.