Cisco Blogs

The Dirty Secret of Team Collaboration: Teams

Cisco Spark is one of a growing set of tools that embrace the idea of team collaboration. These are tools that provide persistent workspaces for teams to work together. They provide persistent chat and messaging, file and photo sharing, and sometimes – real-time tools, such as voice and video conferencing meetings.

Let me let you in on a big problem that all of these tools need to tackle – the fact that the notion of a team is kind of fuzzy and the reality is most users are actually in a lot of them.

For a really small company or a small group of users, this may not be that complicated. But, when you consider how a knowledge worker does their job at a larger company, it starts to get really tough. Looking at myself personally – I’m clearly in a team, which is all of the Cisco Collaboration Technology Group (CTG). I’m also in a team corresponding to my direct reports. I’m in the team of developers working on Spark. I’m also in a team working on content creation for Cisco Live next month. I’m in the CTG leadership team. I’m in the team of engineers working on our conference control infrastructure in Spark. And so on. For each of these teams, I’d love to be able to have a way to find and discover discussions (a.k.a. rooms in Cisco Spark) pertaining to that specific team. At the same time, I need a solution that allows me to be on a bunch of teams, and for those teams to grow and shrink very fluidly.

To date, team collaboration apps have not solved this problem well for bigger companies – or even smaller ones with many teams. Slack, which is centered on the team concept, works if you are in one or two teams. But more than that and it becomes cumbersome since you need to completely switch app contexts to look at stuff in each team. It’s kind of like having a separate email account for every single team you’re in and, worse still, having to go through each inbox one at a time to read all your stuff. Who wants to do that?? We knew something better was needed to take team collaboration mainstream.

For over a year now, we’ve been developing an amazing new teams concept within Cisco Spark, maturing it and evolving it to make sure it works great. I’m pleased to say that today, this feature is graduating to production for all Cisco Spark users, both free and paid.

Cisco Spark teams is really simple. A team is a group of people working together. Anyone can create a team and then add users to it. A team can have any number of rooms, which are topic-specific rooms used by that team. Anyone in a team can create these “team rooms.” As a team member, I can easily see all the team rooms I’m not in, check them out, and join or leave them at will. That makes Cisco Spark a great experience for new users joining the app for the first time, or joining a new team. The moment a new user launches the app, they immediately discover their teammates and relevant discussions. A new user hits the ground running with the people, topics, and content they need to succeed at their jobs. This addresses three of the biggest requests we’ve had from users using Cisco Spark:

  • “How do I find rooms to get added to?”
  • “How do I find people to talk to?”
  • “I need a way to organize my rooms.”

All three are handily addressed by this new, simple mechanism. The best part is, Cisco Spark scales extremely well to a large number of teams, which is critical for usage of a tool like this in a big company. Even if you are in 50 teams, there is a single consolidated recents list that shows you the new stuff in all team rooms, 1-1 chats, and private group chats. In other words – one “inbox” and not fifty. We’ve been using and testing teams within Cisco and the results have been astounding: 32% of all group messaging traffic across the tens of thousands of Cisco employees using Cisco Spark is now taking place within team rooms.

We think we’ve taken a huge leap forward in solving the industry problem on scaling team collaboration tools to big business. We’re excited to see teams get used across our user base and will be iterating and improving it every day as we closely monitor the metrics.

Explore the new teams for yourself by downloading Cisco Spark.

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.


  1. How about some integration with Cisco collaboration products like the DX80? Doesn't seem to be either a native app or anything in the play store to have Spark run on any collaboration endpoint.

  2. Interesting update - I am keen to see how the Team functionality pans out with respect to previous productivity issues with products like Slack. This is an interesting article and keen to read the Spark Team's response:

    • Steven, have you read Jonathan's blog post that references that Article?

  3. Thanks Jonathan! Nicely written. We are ramping up our own company with spark and I plan to use your notes to help folks better understand team based workflow and the importance of Spark. Thanks again! Alex

  4. Jonathan, thanks for the update and for adding the new functionality into Spark Production. I also checked out your previous blogs where you articulated use cases between Spark and email. People do use Spark in the beginning but when the room/s are no longer active, email becomes pervasive once again and Spark then becomes a distant memory. Keen to find out your thoughts on how Spark remains active. How do we change organizational behavior for users to use Spark and email where it makes sense. Does it become effective when the directive comes from SLT in the form of a mandate? I personally believe usage and adoption training with the employees may be the answer.

    • Nitin, even I have been trying to find an answer to keep "Spark" kind app active. SLT level push may have some initial impact, to really drive it, push has to be consistent. Apart from that if Spark app is integrated with email, with just partial message being visible on email client & get full message user has to login, it should do some more steering in behaviour change. Add to it an adoption plan similar to the UC adoption and some techniques from behaviour change science should help.

    • @Nitin - the best successes we've seen were a combination of a top-down push from IT, combined with a sufficient rollout to achieve network effect, with a targeted set of use cases. We've also seen success with APIs, having rooms and content auto-created around use cases.