Vito Chin

The (asynchronous and parallel) Now new world

Published: 01 January 2016

I am a fan of Slack. I think it's going to change the way my world works.

Here's why.

B.S.

Before Slack, much of the effort of people that work in offices (potential knowledge workers) had been about organising interactions, decisions and information.

To that end, we organise meetings, we email spreadsheets around, we drag little files into folders on our computer and we circulate minutes of meetings, amongst other pastimes of the nineties and the noughties.

A.S.

After Slack, we channel most of our energies towards creative work and things that matter (i.e. time to live a life unencumbered from the derivation of meaning from non-voluntary volumetric labour and information administration).

I have reasons to be optimistic.

In my opinion, a lot of the working culture we see in the past (up to the past few years) had been a result of the absence of tools to locate, retrieve, share and process information in a sophisticated way. The primitive tools that were available (such as paper and ink) resulted in a very linear way of dealing with large and complex information.

“江山易改本性难移” (Changing a mountain is easy, but moving a person’s character is difficult)

The original business promise of information technology was that it’ll transform business as we know it. In many ways it did, workers today communicate faster than ever before. Companies had been able to scale to unprecedented levels. Nary a day goes by in business without spending time on the computer.

However, the essential behaviour of companies are still largely similar. The organisation of work is still largely based essentially around the need to deal with the complexity of information and knowledge.

One of the most prominent mechanism was the division of labour.

Division of labour had long been associated with the economies' increase in total output, trade and the rise of capitalism. It had a tremendous influence in shaping the world. Early civilizations grew on the basis of the 1^st golden age of the division of labour.

The Industrial revolution heralded the 2^nd golden age of division of labour, through automation. When the decompositional idea in division of labour met with the innovative spirit of the inventors, the world witnessed a tremendous growth in productivity.

GDP per capita per Area from 1400 to 2003 by Ben Moore

This is the time where we can see how, if we peel off the physical layers involved in the production of material outputs of products and services, when we replace human labour with mechanical machines, fundamentally, the name of the game is in a business' creative productivity (and of course, the ability to execute risks on the basis of those creative outpouring).

It is of course obvious to everyone in today's economy that creativity is the key to a company's growth. Hence, buzzwords like focusing on core competency, outsourcing, etc.

Today's biggest companies had at least resolved (or in some ways absolved) factors of scale through automating the many parts in the division of labour. In some ways, many of these divided labour parts are just abstractions to a company. Production? There's contract manufacturing. Logistics? 3PLs. Computing infrastructure? Cloud. Mass e-mails? Sendgrid. The list goes on. Within the same company, we abstract too, by creating hierarchies and having representative interfaces.

It all seems well. Organizations at each layer, be it another department or another company that provides some form of supporting services, does well automating the hell out of its processes to the point where its core raison d'être becomes supremely robust. Except when its not.

To see why, let's have a look at the abstracted layers, the various divided labours, of a typical technologically savvy company of today:

As a snapshot, it looks fine. Over time, we see a few problems.

Firstly, as software developers know: abstractions leak (<- really, you should read this).

Often, we like to pretend that abstractions work as we expect them to. But according to Spolsky's Law of Leaky Abstraction:

"All non-trivial abstractions, to some degree, are leaky".

Joel Spolsky

This is even a problem for software, which is relatively mathematical. Human abstractions are definitely leakier.

Secondly, the entropy of any closed system always tend to increase

An abstracted layer (such as a functional department) often tend towards forming a closed system. By this, I don't mean they completely close themselves off any interaction with other departments. They do however, over time, start to define their scope of work and specialization. They build their contractual interfaces with other departments and guard the scope on the basis of those contractual interfaces. This is only natural on the basis of the definition of the abstraction.

Applying the 2^nd law of thermodynamics to understanding reality, John Boyd infers that entropy (disorder) increases as an abstracted layer (organizational unit) move towards becoming more of a closed system. The capacity and efficiency of the abstraction decreases as entropy increases.

Thirdly, hierarchy breeds complacency.

This is when abstractions treat attainment of a certain position in the hierarchy as success.

Lastly, and most importantly, we're missing out on valuable creative possibilities by exploring synergies and connectivities between abstraction layers or divisions of labour.

Many times, these problems are energy drainers that takes away the appetite and opportunity for companies to be productive creatively. The worse thing is for companies to settle on this vicious cycle of resolving issues with the couplings between the hierarchies of abstractions and for those that can symptomatically relieve the operational issues to rise in management power and strengthen the vicious cycle.

For companies entrapped in such vicious cycle, the investment made in resolving hierarchical problems will naturally lead to an intrinsic psychology to want to preserve the hard won status quo, sometimes by aversion towards change for fear of triggering another wave of draining hierarchical problems to resolve. This vicious cycle, embedded deeply in the hierarchical notions of the division of labour psyche, is the reason why many workers are still trapped organising interactions, decisions and information and find that to somehow be delusionally meaningful. It is easier to move mountains than to change organizational character, especially one that had been ingrained through years of conditioning.

Division of labour has an effective limit. It is a double-edged sword. The symptom can affect any company. Manifestations of the symptoms are very visible in business markets today, often with larger companies but companies of any size that'd allowed the trappings of the hierarchical divide to overtake its creative spirit can be victims too.

It doesn't have to be that way. Here's where real-time channels of interaction like Slack can help.

A base case for Slack

So far, we'd seen the problems that came along with the benefits of a hierarchical division of labour. Let's now have a look at what should be possible if we stop taking this age-old structural divide too seriously for its own sake. The guardians of the temples be damned!

Here's some interesting observations that stemmed from a team's adoption of Slack.

1. We got everybody onboard working on specific objectives / exploration

This is when we formed cross-functional teams. Nothing out of the ordinary here. But when team members are mostly accessible and responsive in real-time, everybody felt they became more productive. This is a direct opposite of having the dread of working with different people of different functions in a formal context, where you feel that each of these people you work with is a gatekeeper that'll slow things down, not out of intention but plainly from the tax of the boundary and the hierarchy alone. The air of camaraderie with Slack is just somehow much better, maybe because it hadn't been as formalised yet (Note: Something to be wary of when some well-meaning member start to introduce formal regulations here).

2. You'll tend to respond more often and quicker

Slack messages sits somewhere between e-mails and phone calls. Phone call (right after a direct face-to-face visit) implies urgency whereas e-mail less. Slack is a bit of a nice oddball. Messages imply urgency, because it is essentially a call to chat, but people had somehow developed this unspoken understanding that messages may not necessarily be looked at immediately. There are various implicit context of urgency that’s natural to the conversation itself (such as the @mention and the @channel mechanism). There are other features such as notification and Do Not Disturb that helps as well. The key though is that, from experience, I feel that people tend to be more responsive on Slack because it doesn’t seem like a time sucker to them. I think the features help, but the I think the psychological reasons why this is so (at least for our current state of development) is deeper than that.

3. We communicate whenever needed, but not more than we want to

You may think that getting messages frequently may result in a lot of distraction, but here’s how I look at it. Modern work is as much about communication as it is about the work itself. Communicating can sometimes be time consuming though, but I found a way to optimise the work-communication balance. I communicate in between periods of focused work, unless there’s something super urgent to tend to. I find that a small break to biologically refuel and communicate after periods of focus refreshing. There’s even a bonus. Because of all these micro-communication (which can be assembled into a long form discussion too, over-time) that happens, we could avoid having the traditional, formal meetings. I don’t think there’s a need to elabourate further on why many dislike meetings. See here (Guardian: Meetings: even more of a soul-sucking waste of time than you thought), here (Skool Of Life: Why Most Meetings are Huge Waste of Time), here (Psychology Today: Why Meetings Kill Productivity) and here (Atlassian: You waste a lot of time at work), and these are just Google’s first few :)

4. Multiple channels

Had you ever had a long chain of e-mail from multiple parties replying all to discuss a specific subject? What you really need in that situation is a channel. A channel implies something that is less perpetual than a mailing list, but definitely more elegant than a bunch of people replying all for a few times (I guess we all have that golden e-mail thread on an important subject ). In Slack, a channel is persistent, but doesn’t imply that it needs to be active going forward. It is a simple way to provide high-level context and have all the details within the channel itself.

5. Search, not browse

Remember the early days of the internet before Google and Web Crawler, where Yahoo’s relevance reigned with a Directory of the internet? While I do have lots of nostalgia for the Directory (having vaguely remember submitting my homepage for consideration in the directory, possibly, iirc), I am really tired of dealing with folders and directories after 20 years of dealing with the method. Sometimes, I think it interrupts with the flow of what I’d set out to do. At best, it is a chore to have to organise files. Often, I tell friends and colleagues that documents and folders are like graveyards for information. I get into mind conflict moments where I try to convince myself that sorting things with more directories help, it can even train me to think about the meta of what I am doing more, but I also seldom remember where I placed my knowledge and information with it buried deep in the directory hierarchy that doesn’t seem to match very well. Search helps. Spotlight and other forms of desktop search had made my office life much happier. With desktop search, the hierarchies are still there, but just the very high level ones. With teams, I think hierarchies of information is a luxury that should be afforded only to very stable information, and even that in a tool such as Confluence. For everything else, Slack will do. Information on Slack has thinner hierarchies and its search engine is great.

Slack in context

Looking back at some of the problems of abstracted hierarchies, here's where Slack makes a difference:

With Leaky Abstractions

Achilles: Imagine a king who fights his own battles. Wouldn't that be a sight?
[goes to fight Boagrius]
Agamemnon: Of all the warlords loved by the gods, I hate him the most.

Troy (2004), IMDb

One way around Leaky Abstractions is to maintain good knowledge of where a certain abstraction can leak or to get a good understanding of the workings of the layer being abstracted. This is why I think its always a good idea to hire leaders that had "walked the talk" and been through the very activity that they are supposed to lead in the first place. Leaders are users of abstractions through delegation. However, there's no point having a leader that only delegates:

function lead($tasks) {  
    foreach($tasks as $task) {
        $worker->do($task);
    }
}

Or handle exceptions (fight fire):

function leadAndHandleException($tasks) {
    try {
        lead($tasks)
    } catch (Exception $e) {
        $worker->answer($e);
    }
}

Or do scheduling and resource management:

function leadAndSchedule($tasks) {
    while (($freeResourceAvailable) && !empty($tasks)) {
        leadAndHandleException($tasks);
    }
}

We can go on and on. The point is, if leaders wanted to delegate only, today's world offers countless possibilities of delegating to abstracted functions.

Abstraction leaks are nature's way of telling us something. Maybe we should embrace leaks and use what it takes to understand potential leaks as opportunities to get deeper on the domain that we're abstracting from. Smell irony? I don't think so. Besides being used as a mean to avoid dealing with the details, abstractions saves time too. We just have to balance it to reap the benefits of abstraction while keeping in touch with the details. From a software development perspective, we get this kind of balance for example, by assigning the development of a component to a teammate and reading the PR diff afterwards. Slack somehow encourages us to be even more interactive than that. As it is integrated with git tools, with small commits, we get to jump in on each other's code any time we want to and have that interaction so important to prevent abstraction leaks right there. Over time, this has tremendous value to software quality. The same idea can be extended to organizational teams

With entropy

The danger with entropy is that it is self-reinforcing. When a department look inward with a tendency towards a closed system, it often tries to apply familiar mental models in their daily challenges. They try to do the same even when they are presented with new, different, challenges and worse, try to make the old approaches work even when it will not (see Brett & Kate McKay's great explanation on this).

Slack helps prevents such inwardness by promoting cross-functional interaction and by encouraging openness. There is an air of candour with Slack participants. This may stem from the habits of initial Slack users, the developers very accustomed to open collabouration, being beneficiaries of the proven, global success of open source movements. In any case, the culture is infectious and with hope, may ripple across various abstracted, functional teams.

With complacency

"We must not let success breed complacency; cockiness; greediness; laziness; indifference; preoccupation with nonessentials; bureaucracy; hierarchy; quarrelsomeness; or obliviousness to threats posed by the outside world."

Herb Kelleher, via HBR

This is where Slack's benefits are more implicit. There's one thing that some Slack users practice, either in #random channels or topic specific channels: link sharing. Here, usability shines. We get a preview of whatever content is being shared, encouraging clicks. Also, I find that chances are higher that teams discuss about it. It may seem trivial, but I think these practices are invaluable in helping the team maintain an external worldview, a holistic perspective of the "outside world".

The time is ripe

I had many déjà vu during the first few days of using Slack. It obviously reminded me (and I am sure most of us) of IRC. I remember fondly the use of IRC at the BBC. Many communication rituals were had around IRC, in addition of IRL. On top of communication with immediate teams, we could listen in on channels of interests and communicate with technical teams and individuals across the organization. Somehow, I felt that everyone communicated better and became more productive with IRC. Personally, I like it because I didn't have to leave whatever I was doing, there's possibilities of asynchronicity if you wanted to. Also, I met my wife on IRC when I was 14.

That's the thing, I felt that many of us developers, designers, product managers, the creative engines, the Now generation are primed for this new world of work, through our many days with IRC, with Twitter, with the various communication tools, with collabouration tools like JIRA and Confluence. And its not just about chat. It's about the ability to adapt to asynchronicity and work better with that. It's about fire and forget till reminded/responded (by software). It's about parallelization, removing the need to resolve dependencies in a linear fashion. It's about the deprecation/ trivialization of the hierarchy with the ability to communicate and connect as needed. It's about making not just deployment, but decisions non-events. Its about making time and place a non-factor for work. Its about giving you the ability to focus on whatever you're creating.

The Now new world

Going forward, I think Slack is only an impetus for a new work platform. It is the tip of the iceberg of an entire movement towards the destruction of the gatekeeper mindset within organizations. Organizations will not just find that old cliche and roles of dealing with complexity will constrain its ability to deal with the torrent of interaction and information bought about both by an explosion of creative communication by tools such as Slack and the rest of the internet, it will find itself needing new ways to deal with it.

This "new ways to deal with it" is incredibly exciting. I think this migration of work interaction onto software ether such as Slack will enable us to innovate the way we work tremendously, similar to what Virtualization has enabled for the world of software production and operations. Have a look at this list of Slackbots and this short hypothetical conversation: