DesignWIKI

Fil Salustri's Design Site

Site Tools


design:teamwork

Teamwork

In modern engineering, if you cannot work in teams, then you cannot design.

The problem

The amount of expertise and information necessary to execute a typical design in modern engineering is far more than only one person can know. Also, the time-lines for bringing products to market is such that one person can no longer do all the work themselves. Even so-called starchitects have dozens of assistants. Thus, it is necessary for design engineers to work in teams. In a recent survey of 33 engineering companies across North America, teamwork was identified as one of the top three skills needed by graduating engineers [Var95].

However, in academic settings, a poorly formed team can unnecessarily and unfairly lower students' grades. We resolve this conflict by carefully forming teams, providing as much support to teams as necessary (something that isn't available in real life), and assessing projects in ways that can distinguish the contributions of individuals.

Why team-based projects?

The goal of the semester-long design project is to expose students to a semi-realistic design situation involving an open-ended design problem that must be solved by working together.

When you enter the workforce, your employer will not ask you who your favourite co-workers are, and you will not be allowed to work with your friends. You will be told who to work with, and your future with the company will depend significantly on your ability to get along with your colleagues and behave professionally. In order to give you some experience in this, you will be put into teams by the instructors.

Once a design team has been established, it will not be changed as a result of friction or other personality problems among its members. The members themselves will have to find ways to resolve their difficulties, just as would happen in real life.

Of course, your instructors and teaching assistants will be available to help overcome such problems – something that is rarely possible in real life.

Finally, the people skills you develop by interacting with your classmates will better enable you to handle various other social interactions outside your profession. Teamwork is more of a life skill than just an engineering skill.

Creating teams

Design teams will be formed early in the semester by the instructors.

You may either be instructed to take a personality type indicator, or to self-organize into teams. Details of how to do this will be provided by your instructor.

“Personality tests” are quite common in industry. They are not tests in the conventional sense – no one can fail a personality test. Rather, these tests identify the basic personality characteristics of an individual. Having those characteristics in hand allow managers to build teams composed of complementary members.

Because these kinds of tests have been shown to lead to teams that work better together, they are often used in courses that include team-based projects.

How teams mature

“Collaboration is a conscious, learned behaviour.” [AGK92] One would reasonably expect, then, that collaboration takes time to develop, and that any change to the members of a team will require some re-learning.

Whenever a newly formed team works together, there will be a “settling in” period during which each member will become accustomed to the work habits of the others and become comfortable with the team as a whole. Here are some notes designed to help assure you that teams mature over time, and that this is not only normal but also expected and accounted for by your instructors.

“The efficiency of collaborative teamwork depends on the team ability to exchange knowledge for continual learning and to develop shared mental models.” [FKL09] This means that more than anything else, you have to be willing to accept your teammates as your equals, no matter what, and to reach a point where you really, deeply agree on the knowledge and information you're using for your design work.

“Successful engineering teams may find their greatest challenges occurring during the early stages of their existence.” [NZ98] This means you need to be attentive to the differences between you and your teammates, and recognize that these are almost always temporary. Still, if you want your team to “gel,” you will need to work together and see past the differences.

Stages of a team's growth

You may feel strange when you first meet with your team. This is perfectly natural. In fact, there are generally four stages through which any team passes before really fitting together. It helps to know what those stages are, so that you know there's a light at the end of the tunnel.

  1. Formative Stage: You may feel anticipation, confusion, anxiety, impatience, fear, and lack of confidence; after all, this is a new situation. Relax: this will pass. If in doubt, read about team remediation.
  2. Challenging Stage: You may feel resistant, rebellious, defensive, frustrated, angry, suspicious, and overconfident. This is a reaction to Stage 1 – the pendulum has swung to the other extreme. Resist the temptation to believe things will never improve. They will.
  3. Acceptance Stage: You may feel an increasing tendency to identify yourself with the team, cooperation, enthusiasm, relief, and you may feel your confidence begin to grow. You are starting to work well together, but you must remain vigilant of problems that may come in the future.
  4. Collaborative Stage: You may feel satisfaction, more energetic and motivated, a close affinity to the team, realistic confidence in your teammates abilities, a sense of fulfilment, trust, and self-confidence. No matter what happens now, your team will be able to work it through.

Many teams in real life conditions never survive Stage 2. The instructors are available to make sure you can overcome any hurdles that come your way.

Characteristics of a Good Team

A good team is one in which:

  • every team member contributes equally and to the fullest extent of their abilities;
  • individual successes are recognized as successes of the team as a whole;
  • each team member uses personal skills that complement those of the other team members;
  • vigorous but disciplined debate goes on about the work to be done; and
  • balance the need for a cohesive team environment with the challenges and conflicts that naturally occur in engineering.

Certain kinds of behaviour are expected, professional, and extremely productive during collaborative work meetings. These include:

  • have specific and clear goals, milestones, and deadlines;
  • learn from one another;
  • everyone understands what is expected of each team member;
  • try to remain relaxed and in good cheer;
  • leadership is shared; e.g., elect a different chairperson for each meeting you have;
  • always consider several substantially different alternatives before making a decision;
  • prefer asking open-ended questions (e.g. “What do you think about…?”, “How could we do this…?”, “Why is … important?”);
  • treat each other with respect, especially when you disagree;
  • value differing opinions – this is where new ideas can come from;
  • when problems arise, try to deal with people directly and not behind their backs;
  • start and end meetings on time, and stick to the agenda;
  • create and review checklists of topics that need to be covered and criteria that need to be met
  • specifically ask for participation from any team member who has not contributed during a previous meeting
  • leave time during meetings to summarize what each person has said and ensure that feedback is given on each suggestion
  • establish specific work roles whenever possible, and make sure people know what is expected of them from one meeting to the next
  • work each item of the agenda until it has been thoroughly handled;
  • always have a last agenda item for “new issues”;
  • focus on problems, not people;
  • if you don't like an idea, offer an alternative;
  • if you're not sure you understand something, rephrase or paraphrase what was said and seek confirmation;
  • solicit input and participation from each other;
  • everyone has an obligation to participate;
  • try to reach consensus on important decisions; and last but not least
  • try to have fun.

Successful teams also depend on features of the “organization” (i.e., your instructors and teaching assistants). These include [NZ98]:

  • having a clearly defined task or problem provided by the organization;
  • have the ability to alter or modify the problem as the team progresses; and,
  • have adequate organizational support (i.e., staffing, resources, and sponsorship) and time to complete its task.

Still, this is a university, not business or industry. There are limits to what can be provided to your team in an educational setting. Your instructors will do whatever they can, within the scope of good teaching and learning practice, but be aware that they cannot do everything you may need them to do.

On the importance of communications

A real-life design team is composed of a wide variety of experts. Each one brings a specific and unique perspective to the problem. Every perspective is valuable; but sometimes, perspectives can clash, as can be seen in the image below.

Miscommunication can ruin a good design.

Remember: your team mates mean well; they are doing their best to communicate meaningfully with you. Your job is to meet them half-way and remember that their perspective may be the key to solving the design problem at hand.

Another important aspect of communication is to keep a design journal.

Team remediation

Sometimes, teams just don't work right. If your team is having difficulties getting along, or if some team members aren't participating, or if you are falling behind in your schedule, read about team remediation. Do any of the issues raised there apply to your team? Sit down with your team, and discuss all the various topics below, and look for possible solutions. Every member of the team will benefit if the team as a whole functions better.

Also, bring your problems to the attention of your instructor as early as possible. Do not leave these problems to the end of the semester; by then, nothing can be done to make up for lost time and effort.

What if someone leaves a team?

Sometimes, a student will drop the course and leave their teams short a person. This is inevitable. The question is, what should the remaining members of the team do? Here's a list:

  • The team can use any work the missing student did.
  • The team does NOT need to make up for the student's absence.
  • No remaining team member ought to take on more work to make up for the student's absence.
  • They ought to note in their report (in the Discussion and Conclusions) which week the student went missing.
  • Thus, the team can keep/use the missing student's research, but can drop their SUC and Persona, and any other project element that is done “per team member”.
  • They might need to adjust the personas to make up for the missing one.
  • The grading system at the end of the semester will take into account any missing students.
  • Their WDF for the milestone to which the missing student contributed must include the missing student and their contributions.

If in doubt, students must contact the instructors for further guidance.

Three kinds of teamwork

Many people talk about collaboration these days, as if it were a silver bullet for a successful design project. It isn't. There are times when collaboration is very helpful, but there are other times when collaboration can actually harm a project. That's because there are three kinds of teamwork, which are distinguished by characteristics of the team itself and by the nature of the project. Depending on circumstance, only one of the three types of teamwork is most likely to work best.

Coordination

badteamwork.jpg Just working together (as in the image to the left) may not be a good thing in the long run. While this is clearly coordinated work, one must wonder if it's true collaboration - especially for the poor schmuck installing the air conditioner. (Nonetheless, please note the correct use of a free-body diagram.)

When a team works by coordination, each team member has a clearly defined role (e.g. one person deals with mechanical issues, another deals with electrical issues, and so on), and there is well-defined management/leadership directing the team's activities. This is a very efficient way to run a team, but not very effective. That is, if the design project is clearly understood (e.g., the team has significant experience working together and knows well the kind of product being developed), then coordinated teamwork will get the job done most efficiently. However, if the design project is not well understood, or if the team lacks experience, or if the design problem is poorly defined (which happens more often than you might think), then coordinated teamwork will not work well because it cannot adapt to the dynamic nature of the situation.

In course projects, it is unlikely that the conditions for successful coordinated teamwork will occur except perhaps at the very end of a project, after the team has worked together for some time, and the instructor or teaching assistant is providing leadership. In most cases, however, coordinated teamwork is inappropriate in scholastically-oriented projects.

Cooperation

When a team works cooperatively, each team member has a clearly defined role, but there is no defined leader role. That is, leadership is equally shared and distributed among the team members. This kind of teamwork is not usually as efficient as coordinated teamwork because there is no “management structure,” but it is more effective than coordinated teamwork because the lack of management structure makes the team more adaptable to circumstance. If there is vagueness in the project definition, or if the team lacks experience, then cooperative teamwork is usually better suited to a get a successful outcome. In cooperative teamwork, the team as a whole allocates work to individuals based on their roles, and do not need specific direction from leaders to get things done. This requires team members that are willing and able to understand their teammates points of view, roles, and responsibilities.

In course projects, cooperative teamwork is useful in roughly the latter half of the project, when the team members have come to understand the design problem well, and have gotten to know their teammates reasonably well.

Collaboration

When a team works collaboratively, there is no leadership and there are no pre-defined roles for the team members. That is, not only is leadership shared by all the members, but any one person should feel free to contribute to any element of the project, without fear of “stepping on the toes” of his or her teammates. Collaborative teamwork is the least efficient but most effective form of teamwork, and it is best suited to situations when projects are poorly defined (which usually happens at the start of any project), or when the team is composed largely of novices to the kind of project being undertaken. In collaborative teamwork, roles might be allocated but can be changed at a moment's notice depending on the needs of the project.

In course projects, collaborative teamwork is ideal for the early parts of the project, when the team members are still getting to know each other, and when very little is really understood about the project itself.

Tips and tricks

Here's some general hints on keeping your team running well.

Do not fear chit-chat before/after meetings. It's well-known that work environments that permit casual conversation between workers leads to better productivity overall. Of course, you don't want to waste actual work time on idle chit-chat, but leave yourself time for that sort of thing before and after your meetings.

…individuals who talked to more co-workers were getting through calls faster, felt less stressed and had the same approval ratings as their peers. Informally talking out problems and solutions, it seemed, produced better results than following the employee handbook or obeying managers’ e-mailed instructions1).A. Greenberg, Mining Human Behavior At MIT, 2010

Teamwork Don't's

Teamwork Do's

Don't have a leader/manager. Leadership & management skills need training and experience that you don't have. Don't let one member “take over” the team.

Do share leadership responsibilities by task. For instance, the person intending to claim full responsibility2) for, say, requirements may well be expected to manage that part of the project. Base these decisions on team consensus.

Don't ignore a part of the project just because someone else said they'd do it.

Do be willing to check and comment on every part of the project.

Don't delete the work of others without complete and honest agreement by everyone. If there is resistance, move the work to an Appendix and note is as a failed attempt.

Do build on the work of others and enhance each other's work with your contributions.

Don't assign one person to do a task on which the whole rest of the report will rest. For instance, do not expect one person to develop all the FRs while another develops the constraints.

Do form ad-hoc subteams to handle heavy tasks with everyone's agreement and support. For instance, determine the PCs as a team, and then allocate developing the FRs and constraints for one PC to one team member.

What does this mean?

These observations about teamwork has implications for how students should work on team projects. Based on the descriptions above, it should be clear that typical design projects should start as collaborative works, but end as cooperative works. This means that teams need to regularly stop and assess where they are in the project. It is not as simple as working collaboratively for half the project, and cooperatively for the other half of the project. The team must reflect on their activities and decide based on circumstance whether it is time to switch from one kind of teamwork to another.

If the roles of a team's members are changed or realigned, members may experience anxiety, uncertainty, and frustration which, in turn, promotes a reverting to dysfunctional behaviours. [AGK92] This is one reason why we strongly prefer to establish teams as quickly as possible and keep them fixed for the duration of a project. Whether the project is occurring in “real life” or in a course, the burden of team dysfunction undermines achieving project goals.

However

The boundaries between responsibilities, roles, groups, etc. are often a function of boundary objects - things or systems or processes that enforce a separation between the entities that need to “work together.” Some examples include:

  • the conveyor system that move parts from one workstation to another create a boundary between the two workstations;
  • the organizational structure of a company creates boundary objects between workers at different levels of the hierarchy or in different departments of the company.

Boundary objects are usually assumed to be static and immutable, but they can be changed [FKL09]. For instance, email is a boundary object that can keep team members separated in time and space. While this separation may be beneficial in some cases, it can lead to lots of problems too. (For instance, too many emails in one's inbox, too many document versions attached to those emails, weaker depth of communication when done asynchronously,….)

However, one can change the boundary object and thus change the nature of the teamwork. Say one changed from using email to send MS Word documents to team mates, to using Google Docs. Google docs allows multiple users to simultaneously edit a single copy of a document. This supports a boundary in space, but allows teammates to work simultaneously, which tends to increase the richness and depth of the collaboration.

See Also

References

AGK92. a, b H.B. Alpert, L.D. Goldman, C.M. Kilroy and A.W. Pike 1992. 7 Gryzmish: toward an understanding of collaboration. The Nursing Clinics of North America, 27(1): 47-59. (link)
FKL09. a, b D. Forgues, L. Koskela, and A. Lejeune. 2009. Information technology as boundary object for transformational learning. J Information Tech in Construction, 14:48-58. (link)
NZ98. a, b R.H. Nowaczyk and T.A. Zang 1998. Factors related to successful engineering team design. AIAA-98-4941, p1-9.
design/teamwork.txt · Last modified: 2021.04.30 23:38 by Fil Salustri