Is Collaboration the Right Way to Work?

Do you manage a team or a group? How can you tell the difference, and is it important to differentiate the two? In this column, Esther Derby explains that identifying your associates as one or the other is paramount to how they should be managed.

As a manager, your job is to organize people and work for success. That includes work design—figuring out whether you have a group or a team and creating an environment where people can do their best work. I don't know about you, but work design wasn't part of my training as a technical person, and it's not explicitly included in many business and management programs.

The default belief seems to be "teams and collaboration are good," and in my previous column I wrote about the benefits of collaboration. But is collaboration always possible? Is it even the right thing to do in every situation?

In this article, I'll show different levels of collaboration and lay out the questions that managers need to answer to decide whether they have a group or a team.

Josh and Julie work in a tech support area. The primary responsibility of the unit is to configure, tune, and support servers. The workflow is controlled by a ticket system, in which the requestor submits an order with basic requirements and most of the work is handled first in, first out. Of course, there are exceptions when there's extra lead time to order a special server or establish the configuration for a new product, but those orders are the not the rule.

And though different people excel in different areas and each brings unique talents, most server installs in their company require a core set of skills.

Josh, Julie, and their coworkers have a connection. They share professional skills, hold each other in high regard, and let each other know what they are working on. They help each other when asked, but they don't really collaborate. The workflow in their department isn't conducive to collaboration, nor does the work require it. They may call themselves a team, but they aren't engaged in teamwork, and that's just fine. There's nothing wrong with being a workgroup if that's what the work needs.

Deb and Doug report to the same manager and run test labs for two different products. Because their respective products are on different release schedules, there are times when the equipment in each lab isn't fully booked. They cooperate with each other by loaning resources when it's possible and makes sense to do so. Deb and Doug are working together to meet organizational goals, but they aren't a team.

Frank and Frannie work in a product development group. Each has responsibility for a distinct product aimed at a different consumer group. They meet on a regular basis to keep each other abreast of release schedules. They consult with each other about market trends as they prioritize features. It is necessary to coordinate, but given the product mix in their company, it's not necessary for Frank, Frannie, and the rest of the group to collaborate with each other to achieve their goals. No team here.Conglomeration
Ellen and Eddy work on a large project—over one hundred people. Their manager calls it a project team, but they wouldn't recognize each other if they passed in the hall. Their project is too big to truly be a team, though there are subgroups within the larger project that function as collaborative teams. Groups larger than twelve or so almost always break down in to subgroups—which may or may not be teams.

Abby, Alec, and their four teammates work on a software development team. They have overlapping skills, all of which are necessary to build the product. They jointly commit to a goal and work very closely to deliver working software in two-week iterations. They also share mutual accountability. If they don't work together, they won't succeed. They are a team.

So, as a manager, how do you determine how to organize people to accomplish goals?

  1. Consider the work goals. Are people committing to a leader to achieve individual goals, or are group members mutually committing to each other and sharing accountability?
  1. Examine the skills needed to do the work. Does all of the work require the same (or similar) set of skills, or does the work require a broad range of skills?
  2. Analyze the work. Does it consist mainly of projects that one person can complete from start to end (e.g., individual products)?  Or does the work of several people need to integrate to create a coherent whole (e.g., collective products)?

If you answered yes to the second question in each pair, the work is probably best suited for a team. On the other hand, there's nothing wrong with workgroups that aren't teams. If you answered yes to the first question in each pair, the work is probably best suited for a workgroup. Your management job is to determine which will best meet the needs of the work. Then, create the environment that best suites the needs of the group or team.

Building a team doesn't happen by accident, and your job as a manager of a team will be different from the manager of a workgroup. I'll talk more about that in a future column.

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.