Over the years I’ve used a number of different IM, chat, and collaborative tools, and the current trend seems to be to use Slack to work on projects. I’ve got one thing to say about this: stop it.
OK, I should clarify. Tools like Slack, BaseCamp, Trello, even Skype, Google Hangouts and others (there’s instant messaging built in to FireFox now as I understand it) can be great. Really, really useful. But there’s a tendency for clients to ask their suppliers to use and share them on projects, and that’s causing issues.
Within a single team, tools like this can help with communication a great deal because they give a single point of contact for a team, some of whom may be working remotely. A single team can coordinate multiple projects, or multiple teams can coordinate on a single project very well and very easily. But there’s something which agencies and our clients don’t like to talk about, and I’m afraid I’m going to broach this issue now.
The thing which no agency will never admit, and which no client wants to admit, is that you – as a client – are almost certainly not the only client of your developer. It’s possible – it’s likely, in fact – that you’re the number one priority, especially if there’s an ongoing build project. But it is unsustainable for any agency, or even a single developer within a larger agency, to only have one client at a time. At the most basic level, this comes down to the time we wait for clients to reply to questions, sign things off and so on. During this time, which is totally unavoidable – there is no way a client can spend 100% of their time on having their site built – we cannot afford to have developers sitting idle. We also have to consider a pipeline: while a developer is right in the middle of a project set to launch in March they’re also trying to find, scope and plan their projects for April, May and June, and the company is working on maintaining longer term marketing, book-keeping and other administration. The projects we work on we want to do well, on time, to budget; but there will always be other jobs which need doing at some point.
What this means is that when a client who uses a tool like Slack or BaseCamp internally asks to use that tool on a project with an external supplier, the supplier needs to add another project management tool to their kit. When you’re using just one, on just one project, it makes sense to install the relevant apps or to have the website up and running every day. You know that you’ll only get relevant messages and that you’re signing up to a long term commitment to a tool.
As an agency or developer, however, unless it’s a tool we already use internally we’re unlikely to remember to load up the site every day, and we certainly won’t want to install apps for projects which will be over soon. I have two clients using Slack, one semi-dormant; I have at least three dormant BaseCamp clients, some of whom set me up with new accounts; I have archived Skype chats, Trello boards and BugHerd setups, all across two email addresses, and I’ve also used Huddle, Yammer, Google Hangouts, LinkedIn messenger, Twitter, Facebook, Wunderlist, client proprietary systems and email to manage projects and keep up with clients.
What’s worse is that many of these systems, when set up and used by client teams, include the developer as part of a larger project or community. Slack is particularly guilty of this. Important messages get lost among the other conversations which don’t have any relevance; by default Slack will notify me of conversations I have absolutely no part in, distracting me away from the job in hand to check if the notification is important. If I had one request of the Slack development team, it’s to trim down default notifications to the point that they’re only sent when an individual is directly mentioned, and that users are prompted to set notification settings when they enable a native app or browser notifications. There’s lots of talk out there about the cost of task switching and having multiple systems for contact, particularly instant messaging, is one of the worst things for this.
Instant messaging is another big issue for developers. Unless we’re fastidious in setting our availability across a range of clients, we appear either always online or never online. Just because a developer is online does not mean they are receptive to an instant message (because of this), and the nature of the medium sets expectations on both sides too high: it is unfair to expect either a client or a supplier to respond instantly to any enquiry. We all juggle and prioritise tasks constantly and my assumption that my question is the most important thing for you to do right now is not right; likewise it is easy to get in to the habit of waiting until the last minute to ask questions because we expect answers to come direct. I did it today, I have to admit. Without the availability or expectation of instant communication I would be better at planning and asking ahead.
This is why you shouldn't interrupt a programmer: http://t.co/K2dNXKzjem
— Jason Heeris (@detly) October 28, 2013
Mobile phones are as bad for this, of course, but there is more understanding that we may be in meetings or driving; a phone does not tell everyone that you are “available” just because you are physically at your desk.
There is one tool, however, which has everything you really need for project collaboration: archives, threaded conversations, multiple recipients or direct messaging and notifications set by the recipient. Even better, it’s OS and even app agnostic, meaning you can use any one of a number of apps to access it wherever and whenever you want. You can also be guaranteed that your suppliers will already be using it in the way which suits them.
There is nothing wrong with email. It’s the perfect paper trail, it’s easy to file and print, it’s as instant as we want it to be without revealing our current availability (we choose to set an out of office for longer periods of being away) and there’s less risk of being sent things we don’t need to see.
That’s taken time, of course, and CC and BCC etiquette has developed over the years, which is something I’m sure collaborative tools will come to improve on as they become more established. But even then, having a quick glance at a subject line really helps.
Google’s tools for auto-sorting email into primary, social and other inboxes has been a revelation, too; we can instantly see the most important messages.
There’s very little way I can miss emails. Email is one of the most vital tools for any business. But I can miss days – weeks, even – of Slack, Skype, Trello, or BaseCamp messages if I don’t open that app or website, or I use a different device to get online. The onslaught of emails from these services often end up ignored or in spam simply because 90% aren’t relevant; if they do get through they usually require us to switch from email to an app or website to reply, or our replies get formatted and attachments removed or fall down broken API black holes.
Let me clarify here, because I’ve been very negative so far: I do not hate Slack, really. I totally get the benefits it brings. My message is more this: clients should think very very carefully before imposing a collaborative tool on suppliers, and vice versa (although arguably clients will be exposed to far fewer of these tools). In most projects where these tools have been used, compliance is shaky at best and only gets worse over time as people get tired of unfamiliar interfaces and revert back to email. If both client and agency are using a tool already, every day, then by all means use it for the project you do together.
Where these tools are absolutely brilliant, though, is where you have either a permanent, coherent team working on a number of projects, or a single, permanent, coherent project being worked on over a long period by disparate suppliers who will be added and removed from the tool as appropriate. A six month project? Not worth it. A six year project? Absolutely. And only one tool at a time.
Right. Rant over.