We’ve been using Slack (the team messaging tool) since October 2014 and similarly to many other organisations, it has swiftly become our most valuable communication tool.
Previously, we used G+ hangouts and from time to time Hip Chat, but both of those could be cumbersome and a little frustrating to use in team environments. Slack is neither cumbersome nor frustrating and almost overnight it has lifted a significant organisational email burden and created a much simpler, streamlined workflow for our teams.
There are many articles that wax lyrical all day long about the huge pros of Slack and how to set up basic accounts etc etc. So in this article (and the articles that follow in this series) I wanted to detail a few ways we’ve learned to use Slack to our advantage and explain our set up.
To set the scene - as I’m writing this, at Brightec we have currently have 25 people using slack. 9 of those are our clients and we are discussing 11 different projects.
There are 34 channels and 19 private groups, although that includes ones we have archived.
As you can imagine it’s important to keep on top of how slack expands so it doesn’t become too intrusive, noisy and distracting.
From the introduction you will probably have picked up that we’ve put many of our clients on Slack (we’re working on getting them all on it). The reason being, it helps us to work as closely as possible with our clients and brings them right into our workflow.
It sounds cliche, but it is genuinely important to us that relationships are well formed.
Slack enables our communication to be as informal as possible. By this we don’t mean ‘unprofessional’ quite the contrary, sometimes an informal approach to communication facilitates the most professional relationship.
I’ve spent quite a bit of time with many of our clients both in and out of work, and I often quiz them on how the relationship between agency and client works for them.
One of the big things I’ve observed is often those decisions that really frustrate us (whilst we are developing/designing) aren’t because they have deliberately come up with something to irriitate us, but that when answering questions in emails they feel like they need to give a solid answer.
Slack blows this out of the water and helps people feel free to have a conversation to get to the best answer.
I’ve been experimenting at brightec with opening up whole new teams for clients. It means that we can keep everyone separate without having to worry whether the right people can see the right channels.
It seems to be working well. We have just 25 people using slack at a time across 4 teams. But even at these relatively small levels it’s been really helpful to keep all of our files, links and comments in a collection of channels distinct to a particular client/project.
The downside though is that you can end up with direct messages in multiple places, from users who are in multiple teams. The main way we have round that is that our internal team are encouraged to only post direct messages in our ‘main’ team.
Of course there is another obvious upside that the less users you have in your main team the lower your billings will be.
We like to keep channel creation open to all our Slack users.
I’ve spoken to a couple of agencies where channel creation is requested and then a manager decides whether it is necessary to have another channel.
To me that seems counterintuitive as team members will then tend to stick to the given channels and use them even if they are interrupting the flow of conversation or their topic doesn’t really fit the topic of the channel.
A different (better) system is to allow anyone to open and close channels as they see fit and to invite people to channels as they need to.
Often a developer will have an issue they need help with, but it's awkward to interrupt a channel's conversation to get the help they need.
Instead our developers feel free to just create a channel dedicated to that little issue and just invite the people they need help from. It means we have lots of archived channels, but we also have clearer conversations.
If you are wondering how you start putting channels in place then simply start with a few high level ones. Like most agencies we run our projects in an iterative fashion with design and development often happening simultaneously, that means for every project we have #[projectname]_design and #[projectname]_dev channels.
If the project is bigger we might then have a #[projectname]_general channel and a #[projectname]_[feature] channel for discussing any individual features of the project.
A great thing to keep in mind, and it might seem obvious, but if you’re not needed in a channel then stay out of it.
When we first started using slack I wanted to be in every channel to see what was being discussed and out of fear I might miss a decision. In all honesty that wasn’t useful at all. Its better to have someone tag you if needed and trust that someone will let you know of any decisions. It usually isn’t necessary to see the whole story of how someone came to a decision, but to trust they made a good one.
In the next post we'll take a look at '3 rules that help our Slack flow well'
Some general slack tips: https://medium.com/@slackhq/11-useful-tips-for-getting-the-most-of-slack-5dfb3d1af77
Search over 350 blog posts from our team
Subscribe to our monthly digest of blogs to stay in the loop and come with us on our journey to make things better!