Josiah, the VP of engineering, called his directors meeting to order. “First on our agenda is my plan for the reorganization of our department,” he said.
The directors looked at each other, puzzled.
“I’ve noticed that several of the project teams are having trouble working together, so I’ve decided that we need a reorganization back to functional teams.”
After a couple of seconds of shocked silence, Dave, the QA director said, “Oh, no, don’t even think about going there. Don’t take a step backward like that. If you do, I don’t know what we will do with our test and measurement effort.”
Cheryl, the development director, said, “Right, our development is finally making forward progress with test-driven development (TDD) and with continuous integration. Don’t even think about making siloed teams. The teams have conflict. They are working it out. Leave them alone. What problems are you trying to solve? Why are you thinking about doing this?”
Josiah replied, “Wait a minute. I saw some significant discussions last week. I thought those discussions looked a lot like arguments. I thought Charlie and Sharon were going to actually fight it out. And I thought Tranh and Dan were going to beat each other up in the parking lot when I saw them discussing the design of that feature earlier this week. If we break up the developers and testers into functional groups, they won’t fight as often, right?
Cheryl looked at Dave. “You want to take this?”
“Yes, thank you,” Dave said. “Josiah, the testers and developers are finally learning how to work together. And now that the business analysts are on the teams too, and the teams have acceptance criteria for the stories, everyone is involved from the beginning. This is new for the teams. They have never worked this way before. You need to expect growing pains. People are frustrated.
“Let them work it out. We, the managers, are working with the teams, coaching people individually, providing feedback, helping them create a safe environment in which to work. If you come in and mess with the system, we will have to start all over again.
“We’ll still have the same project teams. But with functional teams, people will have to run around to find each other. That will make their lives much more difficult.
“These people are adults. All of us in this room have made ourselves available to our people. We all have one-on-ones. We have facilitated communities of practice. We have been helping people with their feedback skills and their coaching skills. Do not try to solve other people’s problems for them. Let them solve their problems themselves. We are monitoring their issues, and if we need to, we will step in. Got it?
“Now, what’s next on your list?”
Managers Want to be Helpful
Everyone wants to be helpful, and that includes managers, middle managers, and senior managers. But the more managers interfere with a team’s growth, the less a team learns how to perform. When a team is learning how to perform differently—in this case, transitioning to agile—management needs to expect a transition time where people experience a variety of changes in performance and emotion. This is okay. Managers need to support the change rather than changing things again.
Solving problems for the team does not help. If you look at what the directors say they did, they created a supportive environment for the teams. They created a safe atmosphere in which the teams could work. The fact that Josiah even saw disagreements tells me that they succeeded in this. The directors conducted one-on-ones and provided feedback and coaching so that people didn’t run off open-loop with no feedback. People knew where they stood with each other and with the team. That is management help.
Solve Problems at the Level at Which They Were Created
If you want to empower people or teams, you want to make sure that the people with the problem solve the problem. If those people struggle with a problem for too long, then it’s time to ask if they need help. But one of the guidelines for managers is “Let the people with the problem solve the problem.”
This is tricky. Why? Because many people who become managers are excellent problem solvers in some domain—just not necessarily the management domain. When I became a manager, I had been an excellent problem solver in the project management domain. Maybe when you became a manager you had been an excellent problem solver in the development domain. Those domain problem-solving skills do not always translate into people management.
However, one of the ways managers can help is with problem-solving skills. Sometimes, teams or the people with the problem are so immersed in the problem that they have trouble seeing solutions.
Managers Can Help Unstick Problem Solving
Remember the Albert Einstein quote “Problems cannot be solved by the same level of thinking that created them”? If people are stuck in the same thinking, that’s where a manager can help. Managers can help because they can “go meta” and see the situation from the outside. Managers are not the only people who can do this, but sometimes managers are ideally placed to be able to see the problems.
One of the ways I like to help people or teams get unstuck is to generate options using the Rule of Three: What are three potential reasonable options to solve this problem? One solution is a trap; two solutions is a dilemma; and three solutions opens up possibilities, breaks logjam thinking, and provides us choices.
Aside from the Rule of Three, managers can ask, “What would it look like if you did know how to solve this problem?” Yes, that’s a funny kind of question, but it sometimes works.
As a third option, ask, “What kind of help do you need from me?” It could be that the team has not thought of you as a resource for help. The team might need a facilitator. Or a whiteboard. Or a person to bounce ideas off. Or something else. You, the manager, might be just what the team needs.
Let the Team Solve Its Own Problems
It’s so tempting to get in the middle and inflict help on a team. After all, the manager has the organizational power to do so. But that doesn’t make it right.
Facilitate the team’s problem solving. Provide the team what it needs. And then stay out of the team’s way. Every time I have done this, the team has developed a much better solution than I had considered—every single time.
Managers do not have to solve a team’s problems. They can provide feedback, coaching, a meta-perspective, facilitation, or a problem-solving environment. But they rarely need to do so. Before you solve a problem for a team, ask yourself, “Am I doing this for me or for the team?” Then you’ll know what to do.
© 2013 Johanna Rothman. This column was originally published on Stickyminds.com. Want to read the next myth? Read Myth 18: I Can Move People Like Chess Pieces.Tags: agile management, engineering management, management myth, software management