I have been on many teams over the years. Sometimes these teams are given a broad problem to solve. These are the best kinds of teams. They allow you to partner with other people to look for root causes and innovate solutions. But most often teams are given a solution to execute. These kinds of teams are generally less fun. The interesting part has already been done, supposedly, and our work is merely to create a project plan and execute it.
The difference between the two is that one team is solving a problem and the other is executing a task. One team is innovating, looking for root causes, exploring possibilities, and relying on one another’s expertise to solve a difficult and important problem. The other team is trying to figure out how to divvy up relatively mundane work so they can get on with other parts of their job that they find more interesting. One team is generating relationships and trust, and the other is trying to figure out how to end the meeting early. Which team would you rather be on?
Teams are not merely activity-doers. Rather, they are best thought of as problem-solvers. However, this distinction is often lost on those who create and vector the effort of teams. And when we lose sight of this distinction, we lose a huge part of what teams can bring to our organizations.
Why do we even create teams? The short answer that most people will give as to why we team is so we can get the stuff done that we can’t do by ourselves. It is tough to build a house by yourself. It takes a long time and a lot of skill. But one of the most important aspects of teaming is that teams can provide you with solutions and innovations you hadn’t thought of before. Instead of thinking about the creation of teams as a way to get something done, it is a better idea to think of them as a way to solve problems and develop solutions. This is a powerful distinction and one that is often lost. If we think about it in this way, it influences how we build and manage our teams.
An example of this was an afternoon meeting I once had with Tim, an engineering leader whose department was having trouble developing its people. The lack of development meant he couldn’t assign people to different jobs because they had limited expertise across domains. It also meant they couldn’t rise through the organization to take on other positions. Tim was a quintessential engineering department leader — overworked and with way too much on his plate. It was hard to tell whether his rumpled sweater and tousled hair spoke to lack of care about his appearance or if he just didn’t have the time to care. He was a decent enough fellow though, and in the midst of too many change requests and too few engineers with too little time, he still wanted to figure out a way to develop his people. We talked for a while about how he might accomplish this.
Formal training was costly and there was already too little time. “How about simply using the work you already have as development?” I asked. “Think about who needs to do the work rather than who can do the work.”
He pondered this for a moment. “That’s a good thought,” he mused. “Maybe I’ll get a few people together and have them come up with a formal succession plan and some kind of developmental rotation.”
“That’s good,” I said, “but maybe you could build a team and let them know the problem you are trying to solve. And then let them figure out how to solve it? They may come up with something even better.”
Tim nodded. “Sure, why not,” he said with a wry grin. “I can barely figure out our budget at this point. Maybe they’ll have some good ideas.”
Tim did just this. After some time, the team presented him with their engineering development program. The program was a system whereby engineers could earn development points by engaging in any of a large selection of development activities. Each development activity was weighted in terms of its development value. As engineers earned development points, they climbed in readiness to move to other positions and roles. Each person was tracked in a spreadsheet where all could see the activities everyone was engaged in and the points they had earned. A friendly competition of sorts developed, with engineers getting recognition for earning the most points in a quarter and a year. You can imagine how the technical acumen of the department climbed and its bench strength grew as engineers engaged in a flurry of development.
The point of this story is that Tim had a problem and a solution in mind. He could have simply directed the team to create his solution. And he probably would have been relatively happy with that outcome. But by giving the team a problem and allowing them to develop the solution, the team created something greater and more effective than anything that he would have come up with. They created something that he did not anticipate.
The second piece of this to consider is how the team itself responded. When teams are given an important problem and the autonomy to collectively solve it, they have the opportunity to develop the ancillary benefits that teaming gives us — trust, community, fealty, commitment and engagement. These attributes live on long after the team is disbanded and give rise to further communication, collaboration and engagement.
This story is instructive, and its lesson is fundamental to why we create teams. Optimally, we create teams to solve problems, not to simply do stuff. Those are two different things. When we create teams to solve important problems, give them the autonomy to do so, effectively sponsor them and provide them the resources to succeed, we harvest ideas and benefits that we didn’t anticipate. This is exactly why we create teams and why we should be purposeful about how we create them. Teaming, when done well, is a much bigger deal than simply giving a group a task. Teaming is creating the circumstances for innovation, ideas and solutions. There is magic in this.
When we limit our teams to just doing stuff, we rob them of the innovative capacity that teams are capable of generating. We diminish the synergies of experience and perspective that teams can manifest as they seek out root causes and develop novel and value-added solutions to those problems. We diminish the possibility of high levels of trust, engagement and community that great teams can develop. Individual leaders who just task teams with something to do don’t have all the answers, and it is arrogant to believe that they do. We must think of our teams as problem-solvers and not as activity-doers. Design teams with this in mind, and actually empower them to solve your most pressing problems. You will have better teams and better outcomes when you do.
