Team learning: More than group thinking

Team learning is the second of Peter Senge’s group-centric disciplines outlined in his book The Fifth Discipline, and it’s the final discipline we will cover in this series of articles. From the perspective of the nimble project manager, team learning has absolutely nothing to do with training. Team learning in this context focuses instead on the transmission of both tacit and explicit knowledge throughout the group as well as the creation of an environment in which focused creativity can flourish.

• The ability to think insightfully about complex issues
• The ability to take innovative, coordinated action
• The ability to create a network that will allow other teams to take action as well

Thinking about complex issues
Senge defines a good systems thinker in an organizational setting as “…someone who can see four levels operating simultaneously: events, patterns of behavior, systems, and mental models.”

One of the key elements of team learning is a willingness to deeply explore a problem. We can develop this skill individually using personal mastery, but something unique happens when we bring our willingness to explore a problem into a group situation. According to Senge, a group’s collective IQ is much higher than the IQ in an individual if the group can coalesce and begin to use each other as a springboard for understanding and resolving the problem at hand. We’ve all been in meetings where everyone is engaged and excited, and the ideas just seem to build seamlessly on one another. When this happens, the solution the group has developed is above and beyond the work that any team member could have done individually.

As an aid to helping teams think through complex problems, Senge has developed a list of challenging assumptions:

• Today’s problems come from yesterday’s “solutions.”
• The harder you push, the harder the system pushes back.
• Behavior grows better before it grows worse.
• The easy way out usually leads back in.
• The cure can be worse than the disease.
• Faster is slower.
• Cause and effect are not closely related in time and space.
• Small changes can produce big results—but the areas of highest leverage are often the least obvious.

The primary goal of nimble project management is to do those things that actually help us deliver the best product for the customer in an acceptable timeframe and for an acceptable cost. If you’re pondering how this list of assumptions (many of which sound like Zen koans) is going to help you manage your project, let me offer what I hope is a reasonable answer. I have always operated on the principle that if you want people to be able to achieve peak performance as a group at critical points in the project (i.e., when you need a minor miracle or two), they need time to hone their skills in a noncritical situation.

How you accomplish this objective will be unique to you and your team. When I was managing a finance department 20 years ago, we started out by doing exercises from Edward De Bono’s book on lateral thinking at one staff meeting a month. Today I most commonly begin the process by taking something like Senge’s list and using it as a basis for a group exercise in a kick-off meeting. I also use the list (or something like it) to go along with two other techniques:

• The project coffee pot
• A virtual think tank

The project coffee pot
The “project coffee pot” is a catch-all term for setting up a space and practice of congregating informally in order to allow the team to work the kinks out of their relationships. How you go about establishing this space will have a great deal to do with your personal style or the styles of your team leads and managers (if one of them will be taking the lead on setting this up). It will also have to be tailored to fit into the shared vision of the company culture.

While I’ve practiced this technique for years in one form or another, I recently was privileged to see it done by a master. The QA manager at one company I know had developed a practice of bringing in bagels every Monday morning for the development group. The rule was that you had to answer the question-of-the-day (usually about problems you’d confronted in the past) for the edification of everyone in the room, in exchange for your bagel. These Monday morning exchanges were remarkable for revealing people’s more obvious mental models, their personal visions, and often skills and interests none of us knew they had.

It’s important at this point to return to a brief mention of the first discipline of personal mastery. What I’ve found is that it helps to know who you are and how you approach personal interactions prior to trying to set up something like the project coffee pot. For example, as much as I admired and appreciated the approach the QA manager took to creating an informal opportunity for team interactions, I know that one of the reasons it worked so well for him was that it was tailor-made for a personality type that was amiable (social styles) and feeling (Myers-Briggs). A development manager I worked with on another project tailored his approach to his style (which was expressive, thinking) by keeping a list of “project assumptions” and posting it by the coffee pot. The list was designed to help us see what we must secretly believe, based on our behavior (our “in-use” mental models rather than our espoused mental models). The list eventually grew to over 50 assumptions and included such things as:

• The vendor is always right.
• The preferred time to test is in production.
• The project will cure world hunger.

Obviously no one really believed these things, but the list kept us on our toes and made communication easier. For example, most proposed scope changes were effectively eliminated by asking the simple question of the requestor: “Are you curing world hunger?” In this case, the team had learned to recognize the difference between a good idea and a necessary idea, and they had collectively agreed to discipline themselves to focus solely on the necessary ideas.

A virtual think tank
The technique of setting up the virtual think tank is one that is especially appropriate to a complex project that is trying to solve a problem that “hasn’t been solved before.” The premise behind the think tank is that flashes of brilliance come when they come, so the think tank serves as a place to record them and have others ponder them as time allows. Threaded discussions and blogger sites are all wonderful examples of this strategy in practice. The key factor in setting up the think tank is that it needs an advocate on the project who can also be a significant participant. From the perspective of the nimble project manager, the think tank is a concept that transcends a single project. Once team members have become familiar with the concept, the think tank can transcend the project and become a “community” resource, which makes the next project much easier.

Taking innovative action
Most project teams have an innate bias toward action, but as we discussed in our review of corporate cultures, the implicit shared vision in which the team operates can have a significant influence on what happens with the result of all that insightful thinking we’ve been trying to stimulate.

From the perspective of the nimble project manager, it is vitally important to understand what people believe they have permission to do. Within the narrow focus of a project-based task, most teams will seem willing to accept that, if they developed the solution, then it must be within cultural norms. Any difficulty in taking action seems to occur when teams solve what they think are bigger problems that might run counter to “the way things have always been done.”

In a power/achievement culture, project teams will feel comfortable implementing something completely new if they feel they’ve been given permission by the power structure (in these cases, the power flows from the executive sponsor to the PM to the team). In a power/rule culture, all action on something that is truly innovative will be deferred pending official written approval from some committee to go forward. 

The classic example of the treatment of innovation in a power/rule culture is the story an IBM controller shared with me. For five years, he had presented a proposal to change the costing method at one of the IBM assembly plants, and for five years the management committee had sent him back to do more research and present his finding at the next annual meeting. In this type of culture, the intent isn’t necessary to discourage innovation; the intent is to control it and blunt its disruptive effects.

In a collaborative/achievement culture, the team will implement the innovation on a trial basis and then sell it outward, if they can prove to themselves that it works. In a collaborative/rule culture, a truly innovative idea will tend to be shelved 90 percent of the time. It’s not that the culture won’t allow innovation. A good idea might be implemented on a trial basis. The problem enters in when it comes to spreading it to the next unit; gaining consensus is difficult, and being out of the norm by adopting an innovation is culturally difficult as well.

As nimble project managers, supporting our teams in their belief that they are empowered to take action is a significant part of our job. The key factor is that the permission and the reinforcement should be both continuous and timely—which, of course, isn’t a problem for us, since as nimble project managers we practice management by walking around (MBWA), and our favorite answer is, “Good idea; now go make it happen.”

Creating a network
The third element Senge talks about is the ability of the team to sell its learning outward to other teams. Everyone on the team will have one of three roles in helping accomplish this goal.

• Organizers: These people are process oriented and know to the depths of their souls that you can’t share what you can’t communicate clearly. They’re usually not hard to identify on a project since they are usually working as business analysts or as QA.
• Acceptors: These make up the majority of your team, and their role in any innovative solution is to help create it, accept it, and then convey their acceptance to others when asked. 
• Linkers or networkers: These are actually two different roles, but since there tends to be only one or the other on most projects, I’ll lump them together. Briefly, the linker takes the piece of knowledge the team has discovered and forms another group around that knowledge (i.e., like a community of practice), whereas the networker simply conveys the message, “We’ve learned something useful—come take a look.” 

Once the organizer has articulated the learning and the acceptors have all agreed that’s what the group created, getting the word out to others isn’t very hard for the nimble project manager, especially since most of us are either linkers or networkers ourselves. I’ve done brown-bag lunches, set up Web sites, started discussion groups, and presented some of the more innovative project ideas I’ve learned from my teams at conferences worldwide. I’ve also seen peers who were good networkers get the word out to anyone they think might be interested, in that effortless, low-key sort of way they all seem to have.

Team learning is probably one of Senge’s most complex areas, but even looking at the three elements we’ve focused on here should give us some tangible suggestions on how to empower our team to create the innovative solutions to today’s complex problems.

The five disciplines
In this series of articles, we’ve reviewed all five of Senge’s disciplines in varying degrees of depth. We’ve reviewed how the concept of personal mastery can help us understand what we do well, what we can do better, and what things about our personalities are fixed and have to be accepted as is. With mental models, we’ve explored the concept that we are what we think—that how we manage our project and how we approach people and problems is a logical extension of our deeply held views of the world. We then explored the concept of systems thinking, which is the fifth discipline and the unifying concept on which the other disciplines rest. Systems thinking tells us that everything is connected and that by solving one problem, we will most likely have a ripple effect throughout the entire system with eventual solutions as a result. We then explored Senge’s two group-centric disciplines: shared vision and team learning. Shared vision is something we strive to create on our projects, but it is also an underlying environmental factor on all our projects in the form of company culture. Finally we have briefly discussed in this article the discipline of team learning, stressing empowering groups to explore all the ramifications of a problem and to come to actionable solutions that will help both their projects and the organization as a whole.

From the point of view of nimble project management, I’ve found that Senge’s five disciplines seem to round out any formal project management discipline. For me, it’s a simple habit to get into to ask myself at various points throughout the project if I’ve taken into account each of the five disciplines. Have I done enough to encourage personal mastery in team members? Are we assuming anything we shouldn’t be because we’ve limited ourselves to our existing mental models? Are we all sharing the same vision? Have we looked at our problems from a systems thinking perspective in order to be sure we’re solving the real problem rather than just the obvious problem? And finally, has the team been empowered to operate at its fullest potential and to share its knowledge as a group with others? In my own experience, the answer to these questions often turns out to be more important than whether or not I’ve written up a formal risk plan, and infinitely more important than updating the status lines on my Gantt chart. 

Nimble project management is about doing what matters and what works. For me at least, Senge’s five disciplines have offered a quick mnemonic to help me stay focused on the real things that matter and not just on the crises of the day.