A few months ago my team (Azure Artifacts) decided to go all in on Microsoft Teams. Until then our (little-t) team was driven primarily by e-mail and a loose collection of (shock) Slack channels.

Our broader Azure DevOps team had already setup a (big-T) "Team" for our 800+ person organization. We had dabbled ourselves in the past and had created other Teams as well but we decided to close them down and join the larger Team to make it easier to collaborate with our sibling teams.

To understand whether Teams has been successful for us you first need to understand a little bit about our team structure and some of the communication problems that we were trying to solve.

Problem #1: E-mail overload

This may not be true for everyone on our team, but I was certainly suffering from e-mail overload. Before joining Microsoft I was pretty much able to keep my Inbox under control. It was so normal for me to have zero e-mails that needed an action from me that I would get anxious when that wasn't the case. At Microsoft that went out the window - I would rarely experience "inbox zero".

One of the things that I was hoping to achieve was to move some of my e-mail volume over to Team channels. What's significant about this is that I'm not just moving the traffic somewhere else - I'm moving to somewhere that someone else might be able to provide an answer without me having to engage.

When you think about it - it makes sense, within Microsoft a lot of e-mail volume is just routing e-mails to the right people, as far as inner team communication is concerned Teams has removed a whole category of e-mail work.

Problem #2: Cross team collaboration

Under the Azure Artifacts banner there are actually four smaller teams. Each team is responsible for its own set of services but there are of course integration points between them.

Some of the teams were close together in our building here on campus but one of them was further away, and even though it was just down the hall that distance made all the difference when it came to cross team collaboration. We were evaluating moving team rooms to make the collaboration easier but we had to put that on hold whilst a larger building shuffle was being planned.

Teams isn't a cure all for real face to face collaboration but its better than e-mail and leads to a more casual back and forth. Incomplete thoughts can be more easily shared and cultivated as a group.

Where Teams really came in useful was synchronizing state across teams that were working on some shared features. Universal Packages is a good example that required collaboration across 3 of the 4 teams under Azure Artifacts.

Channel strategy

One of the pro-tips that I would give is that you need to come up with a strategy for how you are going to manage your channels. If I add up all the people that work on Azure Artifacts we are getting up to around 35-40 people. Its not practical to have that many people in a single channel using it as a day-to-day replacement for e-mail.

For our team we settled on a strategy of having one channel per "sub" team and then a few different channels for certain types of conversations (don't go overboard on these). For example we had a channel for "Planning" which I'll write about a bit more later. In addition to these permanent channels we created what we expect to be temporary channels around features which need more cross team collaboration (like Universal Packages that I mentioned above).

Our channels, some of our channels are redacted - because ssssh! :)

Problem #3: Openness and transparency

As a group of leaders on our product/service we had received feedback from our engineers that they felt a bit disconnected from the planning process and as a result when we started pushing to execute a strategy it seemed kinda sudden. It wasn't a great experience on the "receiving side".

Of course behind the scenes we had generally talked it all out amongst a smaller group of people and were comfortable with the decisions we had made. As someone on the "sending side" we were sometimes surprised by the feedback we got from our own team - "what do you mean that you don't think doing X is a good idea?".

Of all the problems that we were driving to solve I would say that this is the one where we've come the furthest, but also still have the furthest to go.

Previously I mentioned the "Planning" channel that we had. Our approach for trying to be more open was to seed conversations on this channel much earlier in the product development life-cycle. Rather than holding back sharing plans until they were more of a sure thing we throw them up and see what feedback we get. If people aren't interested in this embryonic chatter they don't need to follow the channel - but they can if they want to.

This has a few benefits. The biggest is probably that by just exposing our ideas to more people we can identify more critical flaws, things to be addressed and potential opportunities.

One of the opportunities that it presents is the ability to avoid duplicating work across teams. There is a trap there also because it can be very seductive to pitch your new idea as the solution to everything and it ends up being so big that it scares everyone away (or worse you actually do it and the team is consumed for 12 months). The flip side is also true where a team says that they are going to "do X" but never end up doing it - at Microsoft we've got a phrase for this - cookie licking.

As I said, this is one of the problems that I'm feeling pretty good about, but would acknowledge that we have a long way to go as well.

Problem #4: Centralizing content

We are a group of software development teams. As you can imagine the vast majority of our "content" is stored within a version control system, work tracker or in some kind of artifact management tool. But we also produce a lot of documents in our day to day work from spreadsheets for budget projections, presentations for events and word documents for marketing copy.

Personally one of the nicer things I've found about Teams is the document collaboration experience. At the end of the day Teams integrates with SharePoint - and so we've had access to this technology for quite some time - but I've found Teams has made it easier for me to decide "where" to put my document on any given topic because there is generally a channel related to the content that I'm producing.

I don't think we set out to solve this problem as a team, but its one of the things that I think has naturally improved as a result of our use of Teams. Having a natural place to store content makes me more likely to share it with my team (which also contributes to solving problem #3 above).

Some lessons learned

This blog post is already turning into a bit of an essay but I don't want to sign off before sharing some of the lessons learned about teams.

Lessons Learned #1: Acknowledge the naysayers

If you read this blog post and race off and implement teams within your own org you are going to have naysayers. It is important to acknowledge that you are trying something new, also acknowledge the possibility that it may not work out at first, and that you may have to try a few different things - and possibly abandon it altogether if it isn't a fit for your team. Don't let the naysayers stop you trying new things though.

Lessons Learned #2: Right size your "Teams"

As I mentioned right up front, we share a "Team" with the rest of the Azure DevOps organization. Generally speaking I think that this has been helpful if only because it makes it really easy for me to @mention someone from across our business. On the flip side the number of channels in our "Team" has exploded and we have in fact reached the limit in the number of channels we can have. I suspect that this is a soft limit but perhaps we should take it as a hint :)

When this occurred we had a discussion with a few people across our org and learned what they had done to handle this. One of the common patterns that we heard was that each group (e.g. Azure Pipelines) would maintain a few front-door channels in the main Azure DevOps "Team" but had their own "Team" for more internal conversations. I think this is a pretty good model and I suspect when we find a moment we'll probably make that transition within Azure Artifacts as well.

Lessons Learned #3: Set expectations for responsiveness

One of the curses of modern life is that we have so many systems bleeping at us on a daily basis that the volume can be overwhelming. Our team raised the concern that we were just introducing another place for them to look - and I think that is a fair concern.

As a team you should come up with a set of expectations around how responsive people should be on Teams. I'm generally pretty active, others might only check it once or twice a day - and that's OK! Just set what the expectations are so no-one is confused and move on.

If I really need to get someones attention I can always stand up and walk over to their desk or ping them on IM. Fortunately Teams has reached parity with Skype for Business (Online) and at least at Microsoft we are moving forward with our plans to go into Teams-only mode. With Teams becoming our default IM client I think things will be less confusing.

One area that I think is going to be interesting for our whole company, and indeed all of Microsoft is how quickly Teams replaces Skype for Business for management of Live Site incidents. When an incident occurs a bridge is setup on Skype for Business and members of engineering teams across Microsoft join to help resolve the problem or just learn when the issue will be mitigated.

Recently I was involved in a security incident where we used Teams to collaborate as a team. From my perspective I thought that teams did a good job of keeping everyone informed and when we had to share documents it was quite natural. In fact we got some pretty good feedback from one of our centralized security response teams that it was one of the better and more consistent usages of Teams that they had seen. I think it helped that many of the folks collaborating on the incident were already well practiced at using Teams - which brings me to my last lesson learned.

Lessons Learned #4: Create more teams

So far I've written about how we work within a single "Team" which has a long life span. Recently I've had an epiphany that I should be creating more Teams for more ephemeral activities. You don't want to go overboard but if I am planning an event, or pulling together a presentation I'm going to start creating teams to capture those interactions instead of having it live in e-mail.

Final thoughts

Still with me? That's dedication! I think the final thought that I want to leave you with is that I think Teams has generally been positive for my team - not perfect by any stretch and we still have lots to learn about the "zen" of Microsoft Teams. I don't know whether it is a good fit for your organization but hopefully what I've shared above helps you figure that out.