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.
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