Team development – from a group of individuals to team synergy
| Jan Dolezal
We can best imagine what team development is based on our own experience. Whether we are working on a project or product development or a similar activity, we often work with other people. Usually, such a grouping is called a team. But there is no team as a team, and no team is formed by snapping a finger or writing people on a paper titled “Team X”.
Surely you have already experienced the situation when you find yourself in a new team. Even when you found yourself in the first grade of elementary school. Or the first year of high school or college, the first time at work, etc. Some people you may have known better from the past, some just from sight, others not at all. The environment was also new, as were the ways of working and the desired results. The first few hours, days, or weeks were probably quite demanding before everything “somehow sat down.” After a while, everything ran into a certain rhythm, new things became a habit and overall you just got used to it. But was it good or bad? How did you feel? How effective was it? Sometimes better, sometimes worse, right? What were the main differences? Probably in what stage of team development you have reached.
Team development according to Tuckman
As early as 1965, Bruce Tuckman described the developmental phases of a team, which take place in a controlled or spontaneous manner in de facto all environments where a group of people has to achieve a result.
Some time has passed since then and the overall concept of management has shifted. However, Tuckman’s basic findings remain fully valid and applicable. So what are the stages of team development?
- Forming – gathering the team and pointig the direction
- Storming – storms, conflicts
- Norming – stabilization, habit
- Performing – performance
- Adjouring – dissolution, termination of activity
Let’s look at these phases in the light of 2020 and concepts such as Motivation 3.0, Management 3.0, Teal organization, agile, etc. The role of manager (with any adjective or prefix) is moving more and more today from the “central brain of the team” who knows all about all and make all decisions, to the concept of “team carer”. To a gardener who takes care of the garden. He can lay it out at the base, water it and fertilize the places he wants to support, he spits out what he doesn’t think. But he doesn’t tell the flower to bloom, where he should sprout another petal, and he doesn’t check it with a stalk in his hand. It does not make sense. It therefore creates boundaries, determines the direction and corrects the spontaneous development of the system.
Who is responsible for team development?
The goal is to create as independent, committed and successful a team as possible. Who wouldn’t want that? But there aren’t many of them … why? Because usually no one controls the development of the team. In agile or SCRUM, the role of SCRUM Master is directly determined for this. That is, if it is performed correctly, which is also not a common case. In traditional methodologies and frameworks for project management, this topic is not addressed very strongly, unlike processes, documents and tools. Respectively, it is nowhere specified who is directly responsible for the development of the team. At least as far as PMI or PRINCE2 is concerned. IPMA goes a little further, but it is still more of a side issue. Responsibility for team development is thus somehow blurred between PM and line management. And so usually no one cares directly about it.
Let’s see how such phases can take place in some common corporation (orange according to Laloux’s taxonomy), which operates according to common schemes. And let’s focus on how we should behave as a team carer if we want to build an efficient and confident team.
The first phase, in which the team is not yet a team. Now it is a group of people who, say, found themselves at the first meeting for a new project. Someone just told them they were coming. They know someone, not others, and they don’t know much about the project except for the name and two sentences in the email. Or just gossip from the coffee machine.
Most people are not very active in such a meeting, they mainly want to listen to what is going on, how it should affect them and possibly “protect their own”. That is, on the one hand, so that no one touches their field of competence, on the other hand, so that no one wants something from them that does not belong in their eyes. Alternatively, they feel that someone is keeping them from other work and they ask themselves the question “What nonsense someone came up with this time?”
You can almost physically feel the barriers between those present.
What should we do in the forming phase?
Our task at this stage is primarily to inform, and thus command a bit. At this point, it is simply necessary to set a clear direction. Now it is necessary to explain the basic meaning and goal of the project, the vision of the product, etc. To teach people possible new concepts and tools for cooperation.
Forming – barriers between team members
TIP: Let’s not expect miracles. Listeners will certainly not remember everything and will not give weight to some things. It is therefore appropriate to somehow draw them into the action. It is very effective when you apply from the very beginning an approach leading to the growing self-organization and empowerment of the team being created. E.g. you can use Project Team Canvas at the introductory meeting and just moderate its use (after a short introductory explanation of the project focus and in cooperation with the sponsor / product owner). Or it is interesting to start using the Delegation board.
After the team has set the course and the basic rules of cooperation, it begins to really work together. You can imagine an analogy where forming corresponds to theoretical teaching in a driving school. Various intersections are projected and it is decided which car has priority and why. Storming corresponds to the first rides in operation. It’s very confusing and fast.
Now you’ll start to find out what you haven’t solved when setting up collaboration rules, what people haven’t understood or perceived. Carl comes up with the fact that Alice sends him those things in the wrong format, Alice argues that this is done by default and Lucy has not yet hit the common data storage.
This phase is full of tensions, conflicts and sometimes quarrels. It is very unpleasant for everyone involved. Unfortunately, if the development of the team is not controlled, for most projects it is also the final phase. Because in order to get out of it in a reasonable time, ie before the project deadline, you have to change your approach.
The hidden trap of storming
It is understandable and natural that you want the success of the entrusted project and that you therefore try your best to help. And when there is a problem somewhere, you try to solve it. But beware, the worst thing you can do now is judge the above-mentioned Carl and Alice and tell them what to do. Alternatively, go to Lucy and show her for the fourth time how to go to shared storage. Why is it the worst? Because all your activities affect the system (team). You teach team something. In this case, you solve all the problems and no one else has the problem. Except for you, who has all the problems.
Storming – people are starting to work together through barriers
You thus become an absolutely indispensable firefighter of all fires, you fly from devil to devil and if you were out for a while, did not check something or were not at work 10 to 12 hours a day, the project would collapse. And you probably don’t want that, do you?
How to handle storming properly?
So what to do? Facilitate! And stop solving all one on one (so Carl comes to see me that Alice is something, so I go to Alice and return the answer to Carl). It is much better to invite Carl and Alice together and get them to find a solution to their problem themselves. Because if I tell them what to do and it’s going to be wrong, they’re fine. They’re just doing what I told them. When it is their solution, they are its owners and it is their (mutual) responsibility that it works. This creates empowerment.
If Lucy can’t hit the shared storage, how will the team (in their own common interest) help her? What will anyone do for it?
With this approach, you can teach the team to take care of their problems and their members. Be able to help and support themself. Be independent. And your hands will be loosened a lot, because most fires will go out on their own. And you can focus on the progress of the project, the customer, other stakeholders and also, last but not least, the further development of the team.
If you manage to get into this phase of team development, it looks like you have won. Most of the conflicts were resolved, the edges were smoothed, everything settled down somehow. People no longer argue, collaboration works without you or the team having to deal with it. And the team members are fine. Therefore, they will not want to move on from this phase. Mostly, they will be worried about some other changes, because in their eyes they could lead back to falling into storming.
So, again, it is often the final stage for many teams, even stable ones. Even if you don’t control the development of the team, if you let “it” run spontaneously long enough, the edges will smooth out and conflicts will stop on their own. But that doesn’t mean they’ve been resolved.
Most people just give up after some (not too much) effort without further support, they close in a certain apathetic shell with the mindset “what would I overdo it, I work up to my salary” and simply do things consciously inefficiently. They are not here to change things. On the contrary. They have to do as they are told and done. Or they will simply go elsewhere if such an environment does not suit them. This is especially true of the more capable ones, which you certainly don’t want to lose.
Obviously, the above condition is not optimal, let alone effective. Unfortunately, it is very common. How to get out of it? First of all, it is necessary to manage the previous phases (forming and storming). In order for motivation to arise, people must understand and accept the meaning of the action and recognize their role in the effort (forming). Subsequently, they must fine-tune the rules of the game (storming). If you already have a team “settled” in apathetic norming, as a result of uncontrolled spontaneous development of the team, do not despair. To some extent, the good news is that any change, whether material or the addition or replacement of a team member, takes you back to the beginning in the dynamics of team development. So just make a change and you have the opportunity to do it right this time.
Norming – there are no longer barriers between team members
The wanted norming looks like things have settled down, but not as a result of giving up and surrendering apathy. The people in the team were simply able to set up the cooperation to suit them. Which is another very strong prerequisite for a motivated team. Is it really necessary for the work schedule table to be according to your Excel? What if the team just comes up with something? Is it such a problem? To motivate people, it is a huge shift on which to build.
Now you can change your style again and start coaching. Only now that the team is at the right level of development. They already know what to do, sailed through the cliffs of storming and learned to work together. They have enough experience. And they will also be more confident because they have done it themselves. Despite their concerns, they will be more willing to make changes and experiment. So now you can start asking in the style: “What takes you the longest time on this?”, “How could this be accelerated?”, “What can you do about it?”, “What do you suggest?”.
With these strong questions, you are able to get the team up to multiple times. To the performing phase.
Here you want the team. Collaboration is very effective, and even though some conflicts arise due to high pace and experimentation, the team can resolve them effectively on its own. Among other things, you have taught members to think not only about WHAT they do, but also HOW they do it. So, for example, after some small push, regular retrospectives will start.
The atmosphere in the team is full of energy, yet calm and pleasant. Conflicts are not personal, but in the interest of the team and improve results and performance.
As a team carer, there is only one task left for you at this stage – to try to keep the team in it. Thus, to monitor events and when it is found that the context has changed, degrades the process (eg retrospectives), there have been material changes in tasks for the team or some personnel changes, the team must be carried out again (albeit rapidly) through development phases.
Alternatively, you can now focus even more on the team’s relationship with the environment and possibly on the functioning of the organization as such.
The last phase is about mastering the end of team work, saying goodbye and moving to new challenges and tasks. It’s more about the possible psychological support of the members, because they were certainly very good in the performing team, almost like in the family, and they will be sad after that.
How long does team development take?
It certainly depends on the environment and context. However, it can also happen very quickly. E.g. when we play with different groups Pacific Railroad simulation, the above phases will take place in a single day. Although it is “only” a managerial game in a limited environment, it is nevertheless complex and the team dynamics are very evident in it.
In a real environment, in which the variability and complexity of the solved tasks is of course higher, the development of the team will probably be more a matter of days and weeks, however, even here it may not be months.
The problem is rather stability
It is important for the team development that all possible interactions take place very intensively and often. As mentioned above, the changes get the teams back to the first phase of forming, no matter what stage of the team’s development. So if a person is 30% in one team, 20% in the other, 40% in the third and 30% in the fourth, which is a very common arrangement in a normal company, then he can’t really get further than storming. It is constantly changing co-workers and context.
Alternatively, if no one is consciously managing development phases of the team, they take a long time. And most projects end before teams can get anywhere on their own. Which is perhaps the reason why PM methodologies do not pay much attention to this topic.
An effective team as the basis for success in the 21st century
In the agile world, a recommendation has emerged: Don’t bring people to work, bring work to the people. This means that it proves to be more effective when you create a strong and efficient team, to which you then give different tasks and projects, than to group new teams and work groups for each project or activity.
Such a stable team must, of course, be cross-functional and be able to cover a wider range of issues than just a very specialized workplace. Although this is also a possibility, it is nevertheless specific to certain contexts.
Therefore, many corporations and companies are currently researching various innovative organizational models, based on clusters of relatively small (5 to 12 people) cross-functional, self-organized and self-managed teams. Organizational structures are significantly flattening, and in some cases only two or three levels remain instead of the previous thirty-five. It is a total change of concept, when the organization was perceived more as a machine to the concept, when it is perceived as a living organism.
Utopia? Sci-fi? Maybe somewhere. Elsewhere, reality or the near future.
It is a big change
However, it is essential for the success of such transformations and changes to understand that this is not just a “hard” change in the organizational structure. That it’s not just the release of a new organizational chart. That it is primarily a change of culture, mindset. And this needs to be “worked out”, as well as the development of the team, which is the basic unit of such innovative organizational structures. Can you imagine that any structure based on a cluster of teams will work if these teams are in storming or apathetic norming?
It is necessary not only to form team, but also to take care of the development of the team in all phases. I will be happy to discuss this with you, for example, in the Team Leadership course.
He currently deals with agility in organizations, Management 3.0 and the development of simulation games serving as project management training, including Agile.
He previously held the position of project office manager and managed large international projects (Europe, South America).
He has experience mainly with projects from IT, mechanical engineering or electrical engineering. He has been actively involved in project management since 2001. He is certified by PMI PMP, IPMA B and CSPO – Certified SCRUM Product Owner and CSP-SM – Certified SCRUM Professional – SCRUM Master from SCRUM Alliance. Read more details here.