Microsoft Teams : 5 scenarios to help you choose between many small teams or bigger ones

Regarding Microsoft Teams, having the right balance between agility, visibility and efficiency take work. More importantly, we all work for different companies where the goals, the culture, and the ways of working might be completely different. You will have guessed by now that the answer to the above-formulated question is: it depends.

In this article, we will talk about examples we can see happening in 2023. Of course, those scenarios are not necessarily the golden rules of your working practices, but they will constitute at least a great starting point to engage in this discussion. So, stay tuned, grab a good cup of coffee, and let’s go!

1 — Scenario one: the product

If you are developing a product internally and want to manage open communications, you might want to create channels for every need. You could have, for instance, analytics, front-end, back-end, release, or support-oriented channels. So, yes, you could end up with a lot of channels. But is this a problem if you take the time to deactivate all notifications and focus on the added value? For example, some release train engineers might appreciate the importance of having complete visibility on the following program increment to ensure that all pods are in sync. Additionally, you could apply the proper settings between channels, keeping in mind that your newly created team could have up to 230 channels (including 30 private channels).

• Pros: keeping collaborators synchronized with transparency.
• Cons: the noise (could be managed between settings & automation).
• Q/A: My preference here is to go for the giant monster team in opposition to scattered ones where you will lose things.

2 — Scenario two: the digital factory

Let’s imagine that you have in your company a massive digital factory. You might want to provide collaborators only some access to projects-specific Teams. Whether they follow waterfall or modern scrum practices, those squads might not necessarily be interested in localization project A when they are currently working on localization project B (typical TMI). One piece of advice: applying some Microsoft military-grade automation strategy to the creation of those Ms.Teams units will save you time (example: Ms. Forms / Azure Logic App)

• Pros: keeping collaborators focused and less spam.
• Cons: too many teams to manage at the org level for users.
• Q/A: My preference here would be to use one Ms.Teams per project and add the program manager to all groups.

3 — Scenario three: the topic

This scenario is one of my favorite use cases as it offers a faster, more casual alternative internally to Yammer. Let’s imagine you want to create a synergy around “Automation” in your company. You could create a public team with channels for each automation product available at your company (Power Automate, Automation Anywhere, Robocorp, UI Path, etc.). Doing so will allow beginners to ask product-specific questions about which product to choose and, more importantly, learn. Historical SMEs will be able to support on the fly, and program managers will be able to evaluate adoption trends without too much governance. This might be the perfect trade-off if you believe your collaborators do not need a framework with more robust program governance.

• Pros: keeping things simple & casual for topics.
• Cons: this might overlap future Microsoft products.
• Q/A: I would use this for medium to large-size companies with moderators to ensure the knowledge circulates.

4 — Scenario four: the channel support model per product

If you are not married with tools, use Microsoft Teams to offer some customized support. In this scenario, you could automatically create a public support channel in each MS Teams product to increase the visibility of incidents and reduce the mean time to recovery. This model assumes that there is no differentiator between the “build” and the “run” teams or that you will onboard the run in each Ms. Teams product.

• Pros: keeping things cheap and simple and reducing the MTTR.
• Inconvenient: SLAs follow up and Run team onboarding.
• Q/A: this model would opt for small teams by default.

5 — Scenario five: the internal VS external model

Some units might want to keep a fence between what is internal and external. For example, if you add channels to scenario one above, you could create two teams. The first one will be solely focused on development (internal discussions). The second will be open to the clients and support.

• Pros: Segregate the discussions and establish ways of working.
• Cons: risks that internal users mix their pencils at some point.
• Q&A: No need to create a big team, as things will be managed at the client level here.

Out of those five scenarios, we might have approached some use cases you have encountered or need to implement. Those examples only constitute one point of view at this stage of the discussion, which I would love to see completed with comments in the below section (feel free). On my side, I will always go for “transparency & visibility”. Therefore I will often choose big MS teams.

The main takeaway of this exercise is that I now firmly believe some of the above scenarios highlight an opportunity at Microsoft to offer an intermediary program cluster between “Projects Ms. Teams” and the “Organization level”. This would help users quickly jump from one program to another and locate the right project they are looking for.

Let me know your thoughts on this, the ways you implemented things on your side, or if you have any questions. Please note that I initially posted this on the Microsoft Tech Community.

If you still need to do it, feel free to subscribe to my profile to be updated on future articles. You can find me on Linkedin and Twitter too. Let me know your thoughts, and feel free to join the conversation below. Don’t forget to hit the 👏 Thank you!

Dimitri Pletschette 🚀 LinkedIn | Medium | Twitter | Microsoft | Mastodon