Like how bad design seems more noticeable than the good, the most negative aspects of group work oftentimes seem to be remembered the most vividly. Many have experienced the situation where a member of a group didn’t pull their weight, leaving someone else to cover for them; many have also been in groups where no member seemed to work at the same pace, making the whole effort a confusing and unpleasant slog. But at the same time, it seems that every professional workplace looks for teamwork as a sought-after quality, despite its tendencies to go wrong as we may anecdotally remember. Why?
Perhaps most obviously, group work can break projects that would otherwise be inapproachable into manageable chunks. This is most apparent for large and technical projects—no one expects one person to build a bridge by themselves, for instance—but even in relatively small and simple efforts, an effective group can make success where one person might struggle. Even if a project could be done by one person, good groups allow work to be spread efficiently and effectively, generally creating better products than those done in isolation. After all, good group members may be able to handle aspects of a project that confuse or frustrate the other members, or they may catch mistakes in a component that is otherwise correct. Indeed, good group work provides enough benefits that a distributed version of it pervasively exists as open source, which is embedded in efforts ranging from Wikipedia to the Linux operating system to the algorithms of most modern encryption schemes.
It makes sense, then, that an effective team would be made of people who can address the weaknesses or unfamiliarities of the other people in their group—although this does not mean that people looking to form groups should just look for members that can cover their weaknesses. Rather, it means looking at what one knows they’re not good at and also what one knows they are good at, all before finding people who they can both rely on for help and also use their own skills to support in the process of creating a successful product. For instance, during my high-tech writing course, I knew that I was not particularly extroverted nor especially skilled with document design, despite both being necessary components of what my team eventually would have to produce, and so it was necessary for someone else in my group to be familiar with these things. I knew also that I was more familiar with the technical aspects of writing than many of my peers, so I made sure to announce that I could cover for other people’s weaknesses with this particular skill.
As already stated, this sort of group work only becomes more important in the professional world. Many projects in the business world place designers and technical workers in the same room, each worker treated as a valuable component of a project because each has skills that the other may not. Even among the more specific classes of workers, there may be more intricate skills—while this is probably more apparent among technical workers, like how one computer specialist may manage the frontend structure of an application while another may manage the coding of the backend server, this differentiation can still be visible among writers, such as the divide between those who may write technical documentation and those who may write analyses for user experience.
However, and despite being somewhat self-explanatory, it is also important to note that groups do not work if there is no cohesion among the members at all. People need to agree on the purpose of the project, as well as how goals need to be achieved. If there are differences between these things—if some people see the project as less important or less exciting than some of the others—then the group may fall victim to the scenarios that form the negative memories as discussed above. The goal, then, is to find people who share an ideology about an agreed effort, but who do not necessarily share the same skills. This may be easier said than done, of course, as there may be structural obstacles to this ideal formation: consider that some workers may hold more sway over others because of their position, rather than their competency or knowledge. However, when done right, groups can make the impossible possible.
Perhaps most obviously, group work can break projects that would otherwise be inapproachable into manageable chunks. This is most apparent for large and technical projects—no one expects one person to build a bridge by themselves, for instance—but even in relatively small and simple efforts, an effective group can make success where one person might struggle. Even if a project could be done by one person, good groups allow work to be spread efficiently and effectively, generally creating better products than those done in isolation. After all, good group members may be able to handle aspects of a project that confuse or frustrate the other members, or they may catch mistakes in a component that is otherwise correct. Indeed, good group work provides enough benefits that a distributed version of it pervasively exists as open source, which is embedded in efforts ranging from Wikipedia to the Linux operating system to the algorithms of most modern encryption schemes.
It makes sense, then, that an effective team would be made of people who can address the weaknesses or unfamiliarities of the other people in their group—although this does not mean that people looking to form groups should just look for members that can cover their weaknesses. Rather, it means looking at what one knows they’re not good at and also what one knows they are good at, all before finding people who they can both rely on for help and also use their own skills to support in the process of creating a successful product. For instance, during my high-tech writing course, I knew that I was not particularly extroverted nor especially skilled with document design, despite both being necessary components of what my team eventually would have to produce, and so it was necessary for someone else in my group to be familiar with these things. I knew also that I was more familiar with the technical aspects of writing than many of my peers, so I made sure to announce that I could cover for other people’s weaknesses with this particular skill.
As already stated, this sort of group work only becomes more important in the professional world. Many projects in the business world place designers and technical workers in the same room, each worker treated as a valuable component of a project because each has skills that the other may not. Even among the more specific classes of workers, there may be more intricate skills—while this is probably more apparent among technical workers, like how one computer specialist may manage the frontend structure of an application while another may manage the coding of the backend server, this differentiation can still be visible among writers, such as the divide between those who may write technical documentation and those who may write analyses for user experience.
However, and despite being somewhat self-explanatory, it is also important to note that groups do not work if there is no cohesion among the members at all. People need to agree on the purpose of the project, as well as how goals need to be achieved. If there are differences between these things—if some people see the project as less important or less exciting than some of the others—then the group may fall victim to the scenarios that form the negative memories as discussed above. The goal, then, is to find people who share an ideology about an agreed effort, but who do not necessarily share the same skills. This may be easier said than done, of course, as there may be structural obstacles to this ideal formation: consider that some workers may hold more sway over others because of their position, rather than their competency or knowledge. However, when done right, groups can make the impossible possible.
Comments
Post a Comment