Managing People. Module 5 Managing Developing Teams

¶ … Managing People. Module 5 Managing developing teams Module 6 Managing Performance. Develop a -page scenario a work team familiar. Describe work team organisational context operates. Include appendix.

Managing and developing teams and managing for performance when creating a new corporate software training manual Team scenario The Bruce Tuckman model of team development Managing people: Managing and developing teams and managing for performance when creating a new corporate software training manual In my past place of employment (which will be known as company X), the members of the IT staff and members of other departments were forced to collaborate on a joint effort to create a corporate manual to explain the company's new computer operating system to all employees.

Proper safety Internet 'hygiene;' dealing with the operating system on a daily basis, and orienting workers to the various new applications were all to be described. In other words, effective communication was needed between staff members to create a comprehensive manual and to ensure that the transition to the new system was seamless. Transitions are always painful, but conflicts between the worldviews of the staff members on the team made developing the manual extremely different.

There was a clash between the worldview of the technical IT staff and mangers from HR and other departments who were more 'people-oriented.' Eventually, the project did arrive at a successful conclusion, but unfortunately there was a great deal of conflict that could have ultimately been avoided, had a more coherent goal and objective been established at the outset. A more firm sense of a goal combined with effective leadership at the beginning of the formation of the group would have been preferable.

The conflict is described below in the context of one of the most popular modalities of team development, the Bruce Tuckman model of forming, storming, norming, and performing. Team scenario At company X, a new software system had been instituted. This required the formation of a work team comprised of technical staff from the IT department, HR staff who had in-depth knowledge of the types of personnel who would be using the new system, and technical writers from the IT department.

While the composition of the work team for this particular position certainly 'made sense,' different staff members had not worked together very much, because of the relatively enclosed structure of the organization. This proved to be extremely challenging at first, and the group members were in continual friction, partially because there were two group leaders from different divisions with equal power over the development of the project.

More effective ice-breaking techniques would have been useful at the beginning, as well as the development of a clearly-articulated common goal and vision statement. However, despite these initial obstacles, the barriers were eventually overcome and a final, high-quality product was produced that was useful for all organizational members. The group conflict actually proved to be illustrative not of particular individual personality problems of various group members, but of larger organizational problems.

There was a distinct lack of unity between all organizational divisions which had previously proved to be problematic and these underlying issues were exacerbated by the creation of the work team with a joint goal. Instead of a sense of higher organizational priorities, the priority was given instead to team membership in factions and to certain group members who provoked conflict, although over time a bridge was built between the different organizational members.

The Bruce Tuckman model of team development and the progress of the team according to the theory Any person talking about the importance of teamwork in modern organizations must deal with the Bruce Tuckman model of forming, storming, norming, and performing (and in some versions of the model, adjourning). Tuckman developed his model to describe the sometimes-rocky transition workers experience when they must operate in the context of work teams.

At the onset of the development of most teams, the team is not really functioning as a 'team' but more as a group of disconnected individuals. They must gradually get to know one another during the forming stage, trying out different roles and exploring different group orientations. The group leader is relied upon for guidance. During the forming phase, there is "high dependence on leader for guidance and direction. [There is] Little agreement on team aims other than received from leader. Individual roles and responsibilities are unclear" (Chapman 2013).

In an ideal situation the group leader or leaders are "prepared to answer lots of questions about the team's purpose, objectives and external relationships" (Chapman 2013). However, the leaders themselves at company X were unclear about the general direction of the project and as a result; the standard operating procedures were often ignored.

Meetings often devolved into talking about the project rather than actually doing the project and despite all team members being part of the same email work "chain,' often there was a stony silence outside of the scheduled meetings even online. (Fortunately, meetings were scheduled on a relatively frequent basis, to ensure that channels of communication remained open to some degree). During the forming stages of the above-mentioned team, unfortunately there was no clear leadership at the onset of the project.

HR and the IT department had a joint responsibility to produce a high-quality training manual, and neither department was given priority. At the beginning, this seemed to be a sensible decision, given that the information conveyed had to be clear yet also technically adept. However, the IT staff had little knowledge of the human-focused language of HR, while HR had very little technical knowledge.

There was a lack of clarity in terms of whether this document was primarily to be a technical work or if it was to be user-friendly in a more conventional sense. The second phase of the Tuckman model is that of storming. Even the most well-regulated and well-managed teams will have a certain degree of built-in friction. During this phase: "decisions don't come easily within [the] group.

Team members vie for position as they attempt to establish themselves in relation to other team members and the leader, who might receive challenges from team members" (Chapman 2013). The 'storming' phase is not necessarily a bad thing, since an overly harmonious group with a very unified worldview may not be in conflict, but ultimately this group will not be creative and productive. "Conflict within a group can allow dissatisfied members to voice their complaints. And, the group may restructure itself to deal with internal dissension and dissatisfaction.

However, conflict within a group often leads to internal tension and disruption. Member's attention may be diverted from the goals of the group to focus on the conflict" (Smith n.d.). This had been the case in the past when IT staff members alone developed training manuals as an enclosed unit -- there was a great deal of agreement and cohesion amongst members of the group, but the final manuals were often unwieldy and overly technical for laypersons to understand.

The challenge of the 'storming' phase is to use it so it brings light was well as heat to the group discussion. During the storming phase, even under the best of circumstances, "clarity of purpose increases but plenty of uncertainties persist. Cliques and factions form and there may be power struggles. The team needs to be focused on its goals to avoid becoming distracted by relationships and emotional issues" (Chapman 2013). A critical component of the 'storming' phase is the need to find equilibrium and to learn how to compromise.

There is often a low level of trust and people place their personal agendas ahead of the needs of the greater good of the group. During this phase, the different members of the team were extremely reluctant to cede points to the other side, and there was a tendency to frame issues in terms of 'right' and 'wrong' versus the pros and cons of making different decisions. On our particular work team, the storming period was quite prolonged, although the conflicts were less personal in nature than ideological.

The IT staff was very proud of the 'creation' and development of its new operating system and wanted it to be very clearly described in the corporate manual. However, HR found IT needlessly obsessed with what it regarded as minutiae rather than something valuable for all persons in the organization to be familiar with on a daily basis. The leader of the HR component of the team often was visibly exasperated with the head of the IT department, and this created a kind of bipolar factionalism between the two sides.

There was no single, calm, steadying leader pointing out the ultimate goal was to produce a high-quality manual not simply to engage in a turf war. However, productive possibilities are possible during the 'storming' phase. Eventually, the two major leaders of the different departments were able to come to a certain level of rapprochement.

The notion of leaders 'coaching' team members was helpful, given that when it became clear that none of the members of the team were getting along, team leaders eventually had to develop 'rules of engagement,' such as no blanket statements (team members could not say things like 'that is silly') and there was a new rule: everyone needed to say something positive about an idea as well as something negative.

These new rules for the work team enabled the leaders to fortunately press the 'reset' button and a clear team vision statement and goal was written out, along with the objectives and the deliverables of the project. There was some continued 'storming' in terms of the prioritization of specific values and ideas over others, but the general goal of creating a feasible and readable layperson's manual was finally at the forefront of the team's agenda.

One problem which exacerbated the conflict between IT and HR is that both departments had not worked together very much in the past. Rather than a coherent, united workplace, this place of employment had a relatively diffused organizational style.

IT often operated in a bubble, on its own, without having to deal with the real, persistent challenges of dealing with 'real people.' Avoidance was the usually strategy undertaken when members did not wish to have to deal with confusion or complaints, and there was a general sense of contempt that ordinary workers did not understand the beauty and true nature of the computer system. "Avoidance is a coping strategy when people are uncomfortable and want to distance themselves from others" (MacAdam 2004).

Similarly, HR staff tended to get annoyed at IT for making things too complicated when people complained or took too long to train. The vital role computers played in the organization was forgotten, except when something went wrong. Thus, one of the unexpected benefits of the construction of the work team to create the new manual was a sense of mutual dependency on one another that had not been previously acknowledged before.

This enabled the work team to eventually transition into the next, more productive phase of the Tuckman model, the norming phase. During this phase: "agreement and consensus largely forms among the team, who respond well to facilitation by leader. Roles and responsibilities are clear and accepted. Big decisions are made by group agreement. Smaller decisions may be delegated to individuals or small teams within group" (Chapman 2013). Above all, there was a true sense of commitment to a higher purpose and genuine interest in the final product (Chapman 2013).

Once the common goals were established by the leaders and the leaders were able to see themselves as united in their management of the team, rather than at odds, the group was able to follow. Eventually, team members were more willing to open up outside of meetings, and the email 'list' began to have more productive dialogue rather than stony silence. In retrospect, 'icebreaking' activities would have been very helpful during the early stages of team development, to more completely set the stage for the norming phase.

'Icebreaking' does not have to be complex or challenging. For example, one popular ice-breaking activity is to instruct team members to find ten things that all of them have in common outside of work (from favorite foods, to owning pets, to television programs they like to watch). The group can 'brainstorm' this activity collectively, eliminating everything but the ones which they all share (Heathfield 2013). As well as getting the group talking to one another, this reinforces the concept that workers share more in common than they might think.

Other, more formal icebreaking activities include taking personality tests such as the Carl Jung's and Isabel Briggs Myers' typology which rates test-takers based upon characteristics such as the degree to which they are introverts or extroverts, are judgers vs. perceivers, feeling or thinking-oriented, or are sensory or intuitive in nature.

The members of the group can then discuss their results collectively to understand their differences: as well as appreciating similarities understanding the different personality and worldview orientations of team members can be extremely valuable, because it enables group members to understand such conflicts are not rooted in personal dislike, but rather different backgrounds and approaching problems. For this work team, such an exercise would have been particularly useful, given that the primary conflict was based upon the different worldviews of IT vs.

HR Using such soul-searching personality inventories would also have been useful given it would have created greater self-conscious about the informal as well as the formal roles of all the team members. Of course, all team members had formal roles which they were supposed to play, such as the IT personnel in charge of specific components of the manual, technical writers in charge of creating and refining the prose and members of HR who were supposed to talk about the different needs of various types of classes of personnel.

But work teams often exhibit 'role-playing' in a different sense, in which certain group members consciously or unconsciously assume roles that may hamper or facilitate the development of the work team. "One of the most useful insights for doing this is to realize that 'leadership' is not a simple property of one person ('the leader'), but rather it is a rich and diverse series of roles that are frequently shared by many people within a healthy group" (Roles in groups, 2013, Strategies for Cultural Change, 9).

For example, one member of the IT staff was very dominant (a 'dominator) in demanding that specific components be included, resulting in a focus more on the 'trees rather than the forest' in terms of the project needs; similarly another member, this time a person from HR, functioned in a 'blocking' role, continually challenging the suggested inclusions of the IT staff as unnecessary (Roles in groups, 2013, Strategies for Cultural Change, 9).

It can be difficult for group leaders to thwart the dominance of unproductive personalities: in this instance, a common sense of frustration combined with the reframing of the purpose of the group reduced the power of these individuals in the group's dynamic. Finally, after much heartache, the team was able to enter the Tuckman 'performing' stage, which cumulated in the production of a final, useful document that could be used by all members of the organization.

This stage is characterized by a full, general appreciation for the potential of all group members to make a contribution. "The team is more strategically aware; the team knows clearly why it is doing what it is doing….There is a focus on over-achieving goals…The team has a high degree of autonomy" (Chapman 2013). Success eventually built upon success, and as the final manual began to take shape, the commitment of the group shifted from conflict to pride in the final product (Chapman 2013).

The group members had a fuller understanding of the fact that they are a group and the components of the group are larger than the sum of the whole. There is also a final stage to the Chapman model, that of adjourning, which details how the group eventually must engage in 'adjourning,' or closing. Although the project itself was brought to completion and the team eventually folded, the lessons learned suggested that there needed to be more dialogue between different divisions of the organization.

In the modern workplace, IT plays a vital role in every dimension of the company, and it cannot be separated entirely without being involved in the day-to-day operations of how workers function in the 'real world' of the modern office. On the other hand, workers in non-technical functions cannot afford to be ignorant of IT. Larger organizational problems were brought to the forefront, in other words, as a result of this exercise.

Recommendations Regular team 'diagnostics' should have been created to evaluate team performance at various junctures, most critically including the 'forming,' not simply in terms of the creation of timely project deliverables. At the beginning, every team member should be aware of the project's expectations and be asked to.