This post was featured at eWeek.

Creating a Microsoft Teams Structure

A Microsoft Teams structure allows organizations to create containers for work. Those work containers can be as arbitrary as an organization allows.

Controlling the architecture of a Teams implementation falls to policy and practice rather than technology. Ahead of a Teams implementation, organizations should plan in parallel for how people will use Teams (see Ten Tips for Effective Microsoft Teams Deployment), along with an architecture for their Teams and channels structure.

Teams acts as containers for work, and within those containers, work breaks down into channels.

For those familiar with Slack, channels will not require much of a conceptual leap. For those who use SharePoint, however, the idea of channels may be new, and channels may not prove intuitive. Think of channels as sub-levels of a Team, each with their own file structure and focused conversations. All Team members can access all channels.

All teams start with a “General channel.”  This channel should serve the purpose of:

• Managing the Team and understanding the evolution of its charter.
• Information and tutorials about the Team for new members
• General Team announcements

In teams with many channels, favoriting a channel makes it easier for members to navigate to the channels they find more useful (or required).

As pointed out in Management by Design, Serious Insights sees policies as codified practice and practice as non-codified (or note yet codified) policy. Teams implementations typically include both:

Policy: a general architecture for the creation of Teams along with guidelines for use

Practice: covering the adaptive use of Teams in an attempt to balance between unruly and inflexible.

Each organization needs to choose the structure of Teams sites. As with all technology governed by policies and practices, the choices should not only be communicated widely, but regularly tested for conformance, and collaborated toward compliance.

For the typical organization, consider the following hierarchy as a good starting point for the policy-based architecture.

A prototypical Teams structure

Employee Engagement: A general employee engagement Team focuses on key elements that might be served by an enterprise employee portal. For those who have an employee portal, or who adopted another tool like Facebook for Work, this Team would be redundant. For those just getting started, or who are looking to Teams as an overall replacement for other environments, this Team will prove a cornerstone. If this Team works, the other Teams will more likely work as well.

There is one Team titled “Employee Engagement.” The four elements listed under Employee Engagement represent channels, not separate teams. Each reflects an aspect of employee engagement without being a big enough topic for a dedicated team. If the team is more of a repository than an active collaborative space, it should be a channel rather than a team.

Teams presents an issue for large organizations. Team implementation limit membership to 2,500, relegating the Employee Engagement team to medium and smaller-sized organizations.

The diagram also illustrates how departments, communities, projects, products, and processes might look. Again, the top-level item is a Team, while the items below, are channels.

Each top-level team will have its own charter and membership. Here are some examples:

• Department Teams: intended to focus on managing the team and the function. These teams cover team building, skills and competencies, roles and responsibilities. Membership is open because the various teams should learn from each other and not duplicate work. Onboarding, for instance, would be better served by providing a link to a departmental document within a team rather than as an e-mail, a link or a file that duplicates content. Work that requires confidentiality or secrecy calls for a separate team with controlled membership. All teams, however, should have a public-facing site as well, and that should ideally be consolidated in a master Team so charters, team members, shared work and other items can easily be discovered.
• Communities: Offer places for communities to self-manage, as well as evolve their internal advisories in the case of communities of practice. Communities of practice might include design engineers managing engineering practices for the organization. This team would be limited to design engineers. Communities of purpose, interest and passion should be open and self-selecting (public and discoverable). Communities of Circumstance would be focused on specific topics and would likely warrant their own Team due to their unique membership. Home-based Workers would be a good example of a community of circumstance.
• Projects: Any activity that requires a virtual, cross-functional team. Some organizations may want to break projects into larger chunks before creating channels. Customer-facing project versus Internal Projects would be one example. Firms organized around projects may find that organizing their Teams around customers with channels for managing projects would make more sense.
• Products: As with projects, individual product collaboration takes place in channels. Larger organizations, however, may find that they need more depth and detail, and the ability to manage membership by product line. In those cases, products, or suites of products may segregate work within separate Teams.
• Processes: focuses on larger internal processes like customer support, sales or innovation. In the case of Sales, the Community of Practice for sales may look like an overlap with the Sales Process. The Sales Community of Practice should focus, however, on how to be a good salesperson, whereas the Sales Process channel should focus on how to make the internal sales process efficient, and how to effectively use sale support tools. Process as a parent for all processes makes the most sense in organizations with a cross-functional process team. Cross-functional processes inside of large organizations probably need their own team or at a minimum, a Team to group related process channels. A good example would be product engineering in aerospace or automotive which spans the entire organization. This Team might also include auxiliary processes covering component engineering and systems, such as transmissions or antennas as components, and electrical or drivetrains as systems.

IT support offers an interesting conundrum to a logical structure because its character reflects multiple facets of the hierarchy. IT support sits arguably as a process, but because of its broad need, it could be seen as part of Employee Engagement.  We suggest making IT Support its own Team for the following reasons:

• The Team has a unique charter
• The Team will likely be seen as a destination by its users
• The Team is open and discoverable by design
• As a location intended for frequent visitation, placing the Team at the top of the hierarchy makes it easier to find.
• IT Support is likely to grow to sufficient size and internal complexity that making it a channel would overly constrain future design options.

Teams requires organizations to conduct a categorization process and to maintain discipline within those categories.

IT Support employees (and contractors) might also benefit from a community of practice for their discipline.

Making choices with Teams

Teams requires organizations to conduct a categorization process and to maintain discipline within those categories. Most organizations will see transgression from policy and practice, at least occasionally. This is of course, no different than exercises around categorizing content. Not only does each organization evolve a unique view of its information relationships, but each person does as well.

Most people are challenged to explain why their paper files, operating system folders and e-mail folders don’t align. Organization takes place in the moment and rarely gets revisited unless it falls within a mission-critical area where people are responsible and accountable for maintaining discipline. Beyond that, it’s all up to the individual, his or her attention span, as well as his or her bandwidth within other priorities.

The prototypical nature of these recommendations needs to remain flexible so the Teams structure remains responsive to change. An overly structured site may lead to abandonment because people don’t feel like the structure meets their needs. An unruly structure results in the inability to find information or people. Organizations need to adopt transparent policies that bend without breaking. Most importantly, they need to actively advocate for a shared repository least the organization’s memory be scattered among too many silos.

Three questions to ask before creating a new team

These three questions will help guide the choice of creating a new team or perhaps just adding a channel to an existing team.

1. Does the new Team have a unique charter and/or membership?
2. Is there a collaboration space on another platform like Facebook for Work or Slack that already serves the charter/members associated with this Team?
3. Will the Team act as a broader parent for subtopics?

If any of these questions results in a “no” then the Team should not be created (or carefully considered before it is). For each of the questions, look to a remedy that eliminates duplication, eases collaboration, manages toward fewer teams and makes the content discoverable.

Challenges to Microsoft Teams from other tools

In Microsoft-leaning organizations, Microsoft’s own products are the biggest competitors to consistent use of Teams for collaboration. Sharing files from OneDrive via Exchange (or other mail platforms) offers peer-to-peer collaboration, without the overhead of thinking about a hierarchy of collaborative spaces. The problem, as always with peer-to-peer collaboration, like e-mail, is the inherent lack of transparency of conversations initiated between two or a few people. Then there is Yammer which offers more global conversations—conversations that might end up capturing information that would be better stored in Teams.

Other tools, from Slack to Salesforce, from Jira and Trello to Facebook for Work, challenge Teams as the source of information, fragmenting attention, often wasting time and usually burning budget due to duplication of function within the infrastructure.

What does Microsoft need to do to make it easier to migrate and combine Teams?

While files can move between teams, conversations and other elements cannot. It would be good for Microsoft to develop a Teams migration tool that supported the movement of not just content, but structures and conversations between Teams, for consolidation as well as disaggregation.