The chat overload is just beginning

There have been several articles recently where people push back on the hype surrounding the rapid growth of Slack as a team chat tool, and Stowe Boyd has written a good response to these articles, which we could broadly characterise as expressing real-time-chat-fatigue.

This is a great issue to be talking about, firstly because it shows that the goal of social technology within the workplace is not simply to maximise engagement, but rather to support work activities without getting in the way. Secondly, we need to acknowledge that the reason this issue has come into focus is because of the crazy explosion in chat use — in other words, it is thanks to Slack’s rapid rise in popularity that we are hitting the social limits of the role chat can play, which means we have the chance to learn some useful lessons more quickly than we otherwise might.

Although this valuable debate is currently between early adopting power users, I think it is worth considering the wider questions around how the real-time team chat model embodied by Slack might feed in to wider changes in organisational design and operations in larger companies as well as startups.

Some history of chat and activity streams

Over the past ten to twelve years, my teams have varied in size from a few people to around fifty, and at that scale we have found real-time chat to be an integral mode of operation, alongside semi-synchronous (email, messaging, etc) and non-syncrhonous (in our case, the wiki is where work gets done and written up) — see Davide Casali’s great intro to the three speeds of collaboration here. We started with Skype chat rooms for projects and team chats, and that worked very well. Later, we moved on to Socialcast and later to HipChat and finally to Slack.

Originally, we thought of this mode as just ‘chat’ to help solve problems or reach decisions more quickly than by passing the email parcel or calling a meeting for everything. But even back then, we could see the real purpose of these tools was not just chat, but also an activity stream into which various updates and events could be shared in a social, sense-making context. We even built a few systems that used the APIs of various social tools to pull their updates into a shared stream where people could receive notifications and discuss actions arising. Weaving together updates and notifications within the fabric of team chat spaces seemed like a no-brainer at the time, but habitual use of real-time chat within most companies was too low then for it to catch on beyond IT and more advanced social media teams, rather than, say, the factory floor, where its value could be huge.

One activity stream product from that period, Tibbr, explicitly had this goal, but it was too expensive and too enterprisey to catch on. Socialcast then fell by the wayside as Yammer, probably the worst of the three, won the sales battle before being acquired by Microsoft, which slowed down (or arguably ended) innovation in the product and the category. But for me, it was the emergence of HipChat, founded in 2010 and acquired by Atlassian in 2012, that marked the beginning of the current phase of work chat tools. We used HipChat when setting up Postshift, and although there is not much to choose on paper between the two tools, we switched to Slack soon after and never looked back. What HipChat and Slack got right was the focus on API integrations so that chat spaces can become integrated activity streams and begin to look more like ChatOps than just chat.

Enter #Slack…

Slack’s meteoric adoption is unusual for a workplace product, and looks set to transform the role of chat tools in teams, but it is not unusual at all in the consumer space and when seen in the light of two key trends, suggests that the mode (if not the tool itself) is here to stay. The first trend is the sheer scale of chat / messaging adoption in China and the way that tools like WeChat have become powerful integrated front-end platforms for commerce and other forms of social interaction. The second trend is the shift in teenage tool use away from platforms like Twitter and Facebook towards more intimate group chat tools with more audience control and less permanence. Taken together, these trends and the rise of Slack point to a key future role for chat and messaging in the workplace.

But what of the key objections raised by Jason Fried and others who are ‘breaking up with Slack’ as summarised by Stowe?

…work chat is tiring, obsessive, interruptive, and leads to focusing people’s attention on the near-term, while fracturing our concentration on what’s really important

Understanding the downsides of chat and how to use it in a better way comes down to structure, culture and behavioural norms.

Structure: how to scale lots of little team chats

In terms of structure, having been part of Slack groups ranging in size from 2 to 2,000 people, I have learned that Slack only really works at the team level of 2–25 people (give or take). It is possible to derive value from larger channels, for example as activity streams mostly for notifications, but not as conversational or collaborative spaces.

I am sure traditional IT folks would have a fit at the idea of thousands of small chat spaces, each with its own settings and integrations, etc, but in a future where the unit of delivery is the team, the team should own its chat and collaboration context. In fact, one of the earliest proven examples of this approach is what has been dubbed ChatOps, where IT teams are using Slack or HipChat to integrate updates and pings from various systems and then use real-time chat to discuss problems and fixes. We have already seen tools such as IFTTT, Zapier and Cloudwork bringing together standalone services to form complex ecosystems, and adding chat integration can help teams support a whole collection of services more easily in one place.

But can real-time small-team chat scale to tens or hundreds of thousands of people? When considering the rise of small teams, we often return to the idea of fractal scaling, where a team of (say) 12 people scales up to a business unit of 12² teams (roughly Dunbar’s number scale) and then again to 12³ to a business unit scale (and possibly 12⁴ for a major unit or division in a large organisation). For each team, the majority of their chat comms is relevant only to their immediate colleagues, but one idea from Holacracy might suggest how to tie them together: the notion of the lead link between circles. If each team shares key decisions and notifications into a public #channel that their peers and the level above and below them subscribe to, then it should be possible to generate sufficient ambient awareness between teams without the need to invade each other’s chat space with too many people trying to collaborate. We should not obsess about integration or worry about people not seeing everything — just enough integration and just enough ambient awareness is the goal. This is very close, I think, to the basic working model outlined by General Stanley McChrystal and David Silverman in Team of Teams: close, real-time collaboration within the team, sharing via ambassadors and links to other teams to form a responsive networked operations model.

Perhaps this is also a use case for AIs? Humans struggle to parse conversational content from too many people, but machines do not. Maybe people can focus on their own sense-making, sharing and chat, whilst AIs act as water carriers in the background, dropping notifications into other teams where asked to do so, or where they think it is important.

A lot of the debate about chat overload seems to have missed the fact that ChatOps is evolving towards a mixed human-machine space, where notifications and event triggers are piped into activity streams where people can see them and discuss their implications. In such a world, we can probably cope with greater volumes of notifications if the channel setup is designed in the right way and we do not ask everybody to track and read everything.

If we foresee a future that involves a common organisational platform / OS that can support a plethora of small semi-autonomous teams, as described by this piece from the Deloitte Human Capital Trends Report 2016, then a network of Slack-like spaces — perhaps augmented by some kind of common backbone or platform to aid discovery and integration — looks like a good fit.

Culture and behavioural norms

In terms of culture, the centre of gravity for most organisations today remains the management hierarchy, and so the idea that individual teams should run their own technology tools and collaborate in their own spaces rather than use the (usually terrible) IT-mandated platform remains problematic. But there are also wider cultural issues at play, such as the fact that young people used to using chat and messaging apps are much more comfortable with fluid group memberships and real-time sharing. Until companies are more comfortable with a distributed culture of work, they will not be able to take advantage of the agility and fluidity that Slack-like ChatOps can bring.

In terms of behavioural norms, we learned a lot about the way streams work through the early days of blogging, RSS and then Twitter. This took us from the old world of ’email as a letter’ where it is assumed people read everything they receive to a world of ‘dipping into streams’ and ‘important information will find me.’ Slack takes this a stage further in terms of requiring comfort with fluidity and getting over FOMO.

Let’s also be honest and admit that a lot of corporate time-wasting is facilitated by asynchronous modes of interaction, exemplified by the political use of email. Yes, chat can be interruptive and attention-absorbing, but if it serves to reduce email overload and also means there are less places to hide whilst pretending to work, it will do a great service to business. How many absurd multi-day bureaucratic interactions over email could be completed in a few minutes over chat? I am guessing quite a few.

Most teams we see using Slack will quickly develop their own behavioural norms. The bots and GIFs quickly become annoying outside of social chat or fun channels, and so they tend to be used sparingly after a while. People also tend to lose the need to respond with “Thanks!” to show they have seen a response, which is partly why reaction emojis were such a neat idea. A key criticism of Sam Hulick (one of those ‘breaking up with Slack’) is the problem of interruption and continuous partial attention, and this is one area where there might be a need for smarter features than just ‘do not disturb’, for example something like Twitter’s ‘whilst you were away’ summary. But on the whole, we see teams developing norms for indicating that they are heads down focusing on a task, just as we saw the visual cue of headphones as an indicator of focus in open plan offices.

There are plenty of other questions raised by ChatOps tools that we will need to understand and solve, such as (for example) audit trails. If I sign off on a colleague’s project by attaching a thumbs-up below their post, might we see lawyers using my emoji reaction in Slack as proof of complicity or command authority in a scandal or crisis? Quite possibly. In legal discovery, we might need some smart AI tools just to piece together the various conversations and agreements that take place on many distributed Slack spaces and channels. These topics will challenge or stretch existing governance models in many ways, but that should not be a reason for companies to hold back from exploring how we use chat and conversational interfaces to make our organisations more agile and responsive.

Brief Conclusions

1. ChatOps and activity streams are an important part of a connected company’s infrastructure.
2. We need better AI and other tech to help deal with chat overload.
3. Tools like Slack could be very well-suited to supporting networks of small teams.
4. We are just getting started with chat and messaging in the workplace, so there is much still to learn.
5. Early adopters declare things ‘over’ before second wave adopters have even used them. Let’s wait and see what happens at scale.

Originally published at shiftbase.net on March 9, 2016.