Friday, 16 October 2020

Reporting from Slack Frontiers


This was my first time attending Slack’s annual event, and of course the 2020 edition was the first virtual version of the event. This was the best virtual event I have attended so far this year but a long way. It was both a superb experience and a great source of insight. Let us look at each in turn.

The Event


I have been saying all year that virtual events lack buzz and are generally very dull, no matter how good the speakers and interesting the sessions. Having been involved in theatre and dance productions for years I know that it’s often the small things that make a difference, and while traditional theatres are all about opulent looking buildings, even a scruffy temporary venue can be given a really exciting atmosphere. This does not translate to skeuomorphic on-line virtual buildings. It translates to more visceral things such as music, count downs, easy to use discussion areas and easy ways to identify who the guests are as well as more private, more privileged areas for people such as the analysts or major customers.


Slack Frontiers was the first event to get this stuff right. It also had a number of other sensible items, such it running for two mornings rather than a single, exhausting day, and using that to run in three times zones to provide global coverage. As well as video sessions there were live round tables where delegate could join and debate that ran faultlessly, as well as live humans on Slack, although by the end of the two days of global coverage they must have been worn out but well satisfied with their efforts.


Another interesting advantage of using recorded videos was that you could turn on captions and watch two sessions simultaneously, jumping into different points as and when they became directly relevant. There was gamification too, logging points for joining sessions, downloading materials and the like. There was even a high-score table with people competing for various levels of bits of swag. I qualified for a pair of brightly colored Slack socks.


Slack is where the work happens

When you work from anywhere, as I have done for a long time, what does workplace mean? Is it my home office, coffee shop, or before the pandemic, airports, and hotel lobbies? Or should we think about it in more technical terms? I am increasingly of the view that we should be looking at what we might call worktops, borrowing a British term for the kitchen counters on which you prepare food.


Laptops and tablets have displaced desktop computers for mobile workers, so using desktop as an analogy is as anachronistic as “dialling” a telephone. Normally the software tools we use sit on the operating system desktop, and the users must go to them, switching context as they do. What we are now seeing with Slack, Teams and other collaboration tools is an inversion. The workflows and activities move inside the collaboration tool.


In some ways this is similar to the notion of container that we had for a while in the world of enterprise mobile apps. It brings advantages for security and ease of use. But these containers did not form a valid destination on their own, while Slack is a key work destination. Slack presented some impressive stats on how Slack accelerates work across the whole business: 13% faster sales cycles, 16% faster marketing campaign execution, and 24% faster HR and engineering where it all started.


These make Slack a comfortable and popular destination in the first place, with users engaging with it automatically while they are working. Slack now provide a range of tools that allow other enterprise applications to be brought into the Slack environment so there is no loss of context, in fact quite the reverse because many work items are trigger on communication anyway.


And triggers are a fundamental aspect of how Slack is providing an event-driven worktop that has the potential to transform and enhance how many people do their jobs. From a programming point of view there are several ways of firing these triggers. At the simplest level you can use the built-in Workflow Builder to automate tasks without any technical understanding whatsoever. As an experiment for a client project I made a few simple workflows in an afternoon. One sent a message to users freshly joined to a channel – it offered a link to video content describing the team culture. Another, most subtle one, is based on reactions. People who responded to messages with a weeping emoji are asked it they are having mental health issues, and if they are offered a choice of a chat, some learning material or coaching.


While these are, obvious, quite trivial from a programming point of view, the mechanism is hugely powerful. However this is nothing compared to the webhook capabilities of Slack apps and the socket-based real-time messaging API. The former allows developers to activate workflows within Slack channels directly. The latter provides what we might call serious integration possibilities, bringing enterprise apps right into the colorful and collaborative Slack experience.

And of course all this is backed up by analytics that allow insight into team behavior and performance, as well as optimizing workflows. This is designed to ensure that when organizations do bring their enterprise apps together into a single, unified interface that IT has tools that they have been painfully missing: understanding where the sharp edges are, the tools nobody uses, and the hot stuff where investment needs to be directed for best return.


All this drives Slack’s aspiration to become a “business operating system.” This great objective sets some very high standards for real-time operating, integration, case management and security all combined with employee experience. Slack also has the advantage of being independent of other platforms making it ideal for companies that have a legacy of M&A or departmental purchases that have left a patchwork of productivity suites. Whatever your circumstances, the idea of bringing the work, tools and content to the user is a huge advantage over making the user hunt about for them. This approach should be informing all CIO strategies.

No comments:

Post a Comment