Theory versus Reality: Team Building and All of the Required Skills – #301 – November 2022

I’m starting with a look at teams and team building in companies. Effective teams are considered an important part of businesses yet business practices seemed designed to hobble the people who are working together. Specifically, I want to look at the assumptions people make when using these business practices. Based on my observation and anecdotal evidence, when people don’t understand the assumptions of a business practice, they may apply those practices to problems that don’t fit them well.

In this article I provide a relatively short summary of project management best practices for building a team. I follow up with assumptions that are built into this model of building a team. Finally, I explore some what ifs of team building if the process was modified to correct for issues within the assumptions. I will include a couple of references at the end for those who are interested in additional information about building teams.

Team Building

The concept of teams and team building is part of project management practices. The purpose of team building is to change a group of individuals into a unit that can work together to achieve a goal or goals. There are five stages of team building that most groups go through as they learn to work together. They are:

1. Forming – The initial phase when the team is formed and the goals are defined. Roles are set and the team members start to get to know each other
2.  Storming – During this stage the team members work through their different viewpoints and ideas for solving the problem(s). Disagreement is common and roles may shift as team members work through the difficulties
3. Norming – At this stage the team members have worked out rules for working together. Roles and responsibilities are firmed up and the team starts making progress towards the goal.
4. Performing – The team members work well together, everyone is clear on their responsibilities and the goal. The team performs activities, such as meetings or status checks, that keep everyone informed and productive. This is the most productive part of the team.
5. Adjourning – In this stage the team has achieved their goal and they prepare to disband. In some cases they may not have solved the problems, in either event the team members will be moving to other projects.

Teams are different from groups because they are not united by a common skill sets. Team members each have different skills that are used to reach a goal that involves more than one expertise. Each member of the team contributes to some part of achieving the goal but no one person has all of the skills required to achieve the goal. In groups, each member has similar skills and backgrounds. An example of a group is a plumbers union or teachers at a school. Each group might have different issues but the issues all require a similar set of skills to solve.  This commonality makes it easier to work together but it limits the goals the group can achieve. . However, this limits what the group can do. For example, building a school requires skills in architecture, construction, contractor management, and facility planning. A group of plumbers could handle the installation of pipes, water fountains and toilets but would not have the skills to lay the foundation. A team is assembled that has representatives for each skill set and the team works together to build the school.

When assembling the team, the selections are usually based on choosing people with a set of skills for achieving the project goals. For example, for a software project to develop a database and an interface for the data, it would require software development skills of database design and administration,  and user interface development. In addition,  testing the software and publishing it for delivery are also required. In order to develop the software by a specific date and for a specific budget,  a manager or lead is needed to track progress and make decisions on how to move the project forward. Depending on the size of the software project, there might be one team or multiple teams assembled for development. The focus on assigning or hiring people for the project would be based on the technical skills for each part of the project.

A project manager would be assigned to the project and would manage the schedule, assign responsibilities and monitor the status. They would also interface with other managers and coordinate getting resources, such as computers and software tools, for the team members.  The team members would work on tasks and provide deliverables at periodic intervals to show progress. Eventually the project would complete and the team members would move to another team for another project.

Based on this high level view of a team, I’d like to examine some assumptions that are used in assembling teams for a project.

Assumptions

After reading a section in a project management book about teams, here are some unspoken assumptions that I feel are in play.

1. The assembly of a team of people is based on rules similar to designing and manufacturing items. A set of requirements for the final goal is identified, and technical specifications are written to select members of the team.
2. In many cases expertise in technical skills is the primary focus. Some requirement for social skills may be listed, in generic or ill-defined terms.
3. In project management, discussion of how to manage the social interaction occurs after the assembly of the team
4. The only person that is expected to focus on social skills and interactions is the project manager
5. The social and management skills of the manager will be able to identify and correct all social issues within the team
6. If two people have the same technical skills, similar experience and same level of expertise,  they are interchangeable and it doesn’t matter who is selected for the team
7. When assembling a team, an unspoken rule is that the people in place at the company will select new people based on how well they get along with them during the interview process.

I feel these are unspoken assumptions that are taken for granted when a team is assembled. The biggest assumption, that selecting people with the right technical skills will ensure completion of the project is the biggest problem area in my experience. Social skills are considered in imprecise terms “must be effective in communication” or “works well with others”. The phrases are vague because they don’t specify where and how social skills are needed. In some instances, technical members of the team will communicate with each other. At other times, the technical people will communicate with a customer. Each instance requires a different skill set in communication for project success.

Another problem I see with all of these assumptions is how they view people. They view people in a way that is analogous to selecting parts to assemble something, such as a dishwasher or a car.  However, this selection only takes into account simple traits, such as expertise in software coding or engineering and ignores traits that are harder for most people to quantify, such as ability to work in a group, communicate clearly with others, take direction and compromise with others on the team. However, I suspect most people intuitively understand that these elements should be taken into account in order to increase the chance of success for the team. Unfortunately, when selecting members for a team, I suspect most people look for people who are similar to them in background, social interactions and other methods of unspoken communication. These methods can lead to less diverse teams and less exposure to innovative solutions resulting in projects that achieve a result that is not as optimal as it could have been.

I’ve developed an analogy of assembling a team as compared to assembling an item. For example, when assembling a car, there are two types of requirements used. The first set of requirements is technical and focuses on a listing of the types of parts, such as wheels, a car body, an engine and transmission, steering wheel, and other car parts.  The second part specifies on how the parts are related to each other. The specifications focus on the tolerances required for the steering wheel to attach to the axle and the wheels, the attachment of the engine to the transmission and how all of these systems connect together. Without the list of parts and the specifications, it would require trial and error to assemble a working car.

For teams, the focus is on the technical skills, the parts needed for a project and a lack of focus on the specifications, how the technical skills will work together to achieve the goal. In my opinion, the social skills are taken for granted and communication problems are considered part of the team assembly. This is reflected in the stage of team building called Storming, when friction is in the open between team members.

In spite of this, many teams do work together and I believe it is because of the unrecognized strength of social skills of members of the team. When an experienced project managers is leading a project, they intuitively include social skill evaluation as part of the assembly of the team.  However, there are many times when a less experienced project managers isn’t aware of the importance of social skills in the team. I’m also familiar with technical people who are promoted to a management position based on their technical skills. The ability to technical perform work does not always translate into skills for managing people effectively and efficiently.

When a project completes, whether successful or not, the team is usually split up. Or worse, during a project the team members are placed on another team that is having difficulties. In the end, without heroic effort, both teams do not perform as well as they could. This seems like taking the wheels off a car to put them on a semi-truck because it has flat tires. Then attempting to make the car go by borrowing tires from a go cart. In both cases the tires are the right parts but they don’t meet the specifications for the vehicles they are used in.

So what if social connections were considered when assembling a team, how could that occur? And once a team is built, a team that functions well and the members communicate together well, what if the team was left together? How would changing the assumptions affect team functionality?

What If

As mentioned before, the focus on the requirements for team members is the technical skills they have. The team is also assembled for a short term purpose and it is likely that the members will be moved to other positions once the project is completed. The first what if to examine is how to include social skills as part of the requirements for the team.

In some basic research for this article, I found two mentions of social skills for teams. I read my first mention of this in the book “Peopleware: Productive Projects and Teams”. The authors start by describing how projects and teams are typically managed. They are managed to reduce error, maximize productivity, standardize procedures and reduce or eliminate experimentation. There is also the assumption that there is no setup cost in creating the team and that everything will just work once the team is assembled. The authors gathered research and studies and found this approach is based on the setup and operation of a manufacturing line.  When used in creative projects, these methods tend to limit creativity. The end result is that people are treated as replaceable parts based on an incomplete specification. When the extra step of examining the social skills and other factors occurs, very effective teams are built for solving creative problems such as software development.

Another researcher, Meredith Belbin, performed research on the ideal roles for a team. He identified nine roles that when they exist in a team will help ensure it functions well. The number of roles not require a minimum number of nine people for a team, a person can assume more than one role while performing the work. The roles are the ones required to think about the project, bring about action on the project and shape the project. The focus on the role descriptions is on the social skills and they can be applied to multiple projects.

In both cases, an overlooked role was identified. The role is an integrator, a person who works well with everyone and helps the rest of the team in completing their tasks. The person may not be strong in the technical skills required for the project but they know enough to understand where problems are occurring. They help out the other team members to reach their goals while also working on their part of the project. The problem is that because the technical skills may be viewed as weak, the person’s part of the project is not recognized. The person may be shifted from project to project because they don’t meet the technical requirements. In some cases they may be laid off. The team members and management may wonder why the team is not performing as well when the person is gone, not considering the other skills used in the project.

Here is my short list of roles I have observed for successful teams.

• Manager – Sets overall direction of the project, make decisions on direction when there are multiple technical options for moving forward. Acts as an interface for the team with the outside world (other teams/departments, upper management, customers)
• Technical lead – Sets the technical direction and monitors progress to meet requirements and specification for the project. Handles technical issues, raises issue to manager if there is potential conflict with budget, quality and time requirements. Performs technical work and sets example for work quality
• Technical workers – Performs the majority of the work, directed by technical lead with input from manager as needed
• Integrator – A generalist who supports other team members in completing their work by listening, reviewing and feedback on technical work. Usually part of the technical lead or manager role, may also be one of the technical workers.
• Subject Matter Expert – Very knowledgeable about the technical requirements and the end product. May not be a part of the daily activities, available to answer questions and resolve issues that occur with the technical work.

 After social skills are accounted for, there is another problem with teams. An effective group is built that functions well together in solving problems. Once they have learned how to work together, the team members are sent to other projects and the process of team building starts again.  To me this is like taking parts of a functioning car because they are needed elsewhere and adding back parts that don’t meet the requirements as well. Just like pulling a wheel from a car and replacing it with one from a bicycle won’t work that well, swapping people in and out is more likely to slow things down and cause issues. So what if an effective team was kept together to work on other projects? I have observed that technical skills are easier to learn than social skills. If a team gets along well they can probably learn new skills needed for a new project. The project would have some connection to their current skill set while offering the opportunity to learn new things.

This doesn’t mean that a team must retain the same makeup in the future. People do change over time and may be interested in changing to other types of work or projects. The difference is that only one or two people might change at a time instead of assembling a brand new team each time that has to learn how to operate together in the most efficient way possible. Just as the parts of a car might be swapped out for a different look or because they have worn out, people could also swap out of teams, bringing in a fresh perspective to invigorate the team with new ideas.

In all cases, recognizing the importance of social skills can be a step to improve the performance of a team. The recognition and support of a successful team for multiple projects could also benefit performance. Unfortunately, company cultures and management beliefs try to force all teams into simplistic models based on manufacturing models. This is easier in the short term because it is a simpler model to work with but it can hurt the long term prospects of innovation and new products for the future. If the assumptions used in assembling a team are never examined, the opportunities for improvement are reduced.

I’ve included two references for those who might be interested in other viewpoints on setting up teams.

Belbin, Dr. Meredith. The Nine Belbin Team Roles. n.d. Web Page. 11 November 2022. <https://www.belbin.com/about/belbin-team-roles>.
DeMarco, Tom and Timothy Lister. Peopleware: Productive Projects and Teams – 2nd Edition. New York: Dorset House Publishing Company, 1999.

Pictures by J.T. Harpster, prints of selected photos can be found at our Redbubble shop

Help support our work on Patreon, get access to short stories and news about Shell Creek Publishing.