Regarding Microsoft Teams, having the right balance between agility, visibility and efficiency is not necessarily easy. 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 try to touch base on some examples we can see happening in August 2022. 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 with us in this discussion. So, stay tuned, grab a good cup of coffee, and let’s go!
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? Some release train engineers might appreciate the value of having clear & 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 subscriptions, settings & automation).
- Q/A: my preference here would go for the giant monster team in opposition to scattered ones where you will end up losing things.
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 access to some 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 team per project and add the program manager to all groups.
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 in a position 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 and could be a dupe internally.
- Q/A: I would use this for medium to large-size companies with moderators to ensure the knowledge circulates.
Scenario four: the channel support model per product
If you are not married with tools, you might want to use Teams to offer support with some excellent customized support. You could also use some connectors to reduce the number of transactional emails. 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 get 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.
Scenario five: the internal VS external model
Some units might want to keep a fence between what is internal and external. If you could add channels to scenario one above, you could create two teams. The first one will be solely focused on the development and internal discussions. The second will be open to the clients and support.
- Pros: Make sure you 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 approached some use-cases you have encountered or need to implement on your side. This only constitutes one point of view at this stage of the discussion that I would love to see completed with comments in the below section.
On my side, I will always go for “transparency & visibility”.
Therefore I will often choose big MS teams.
The main takeaway of this exercise on my side 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 most probably looking for.
Let me know your thoughts on this, the ways you implemented things on your side, or if you have any questions.
Thank you!