8 October 2018 - Written by Ryan Riggin
Learning to Communicate as a Remote First Digital Agency
We’re a digital agency. Our core business model is performing services for our clients. We do that in two main ways.
Fixed Bid Projects
Ongoing Retainer Engagements
The types of work we do includes:
Website & App Development
User Experience Planning
Architecting & Building Analytics Infrastructure
Running Marketing Experiments & Conversion Optimization Programs
Managing Paid Media Campaigns
Inbound Marketing Strategy & Execution
Content Creation & Social Media Management
Sales & Marketing Automation
The clients we serve most likely fall into one of the following business models:
As you can imagine this breadth in scope can be a challenge when it comes to building a communication system that works for everything. Like anything, it’s a work in progress. And, we are experimenting with it as we go.
We’ve recently made a temporary decision to go fully remote and experiment with how that works.
Here is a hit list of the tools our team uses to communicate, along with some of the nuances and unwritten rules we have in place to make them more efficient.
Asana for Project Management:
Every client we work with starts with a fresh Workspace in Asana. Within that workspace we break things into projects. Some projects use board view, and some use list view. In another article we’ll share some of our templates and go into more detail. If used correctly, Asana provides a great high level view of what’s happening; along with a clean way to break projects into subtasks. It also provides a very simple way to send messages from within a task (or as in board view we refer to them as cards)
Generally speaking if something is related to a specific project it should go in an Asana card. A few things should happen when you force all project specific communication through Asana:
You force yourself to think deliberately about the work that you’re doing. Is what I’m doing right now related to a specific project, deliverable, or project we’re trying to solve? Who really needs to see this? When do I need a response?
It keeps project collaboration out of email. Email is horrible for managing projects. Everyone is using a different email client. People have their own email workflows that work well for them. But tools like Asana (and others Basecamp, Monday, Trello) are designed around team workflow.
It slows you down. Yes, I said that. It slows you down and forces you to think. If you revert to chat as the default for communicating project details, (yes, it’s quicker)…you run the risk of running fast in no particular direction.
You can see your progress. Tracking ‘progress’ on a given project is much easier to do in a project collaboration tool like asana. Tasks get checked off as complete. Cards move from left to right. From ‘currently working’ to ‘done.’ You can see who is working on what. If things aren’t moving then you have a problem.
We’ve adapted our communication as our team has grown and our client base has evolved. As a result we’ve learned some things and run into some bumps in the road along the way. I think it’s safe to say that we have underused Asana and it’s capabilities for group project collaboration. Mostly as a result of my failure to communicate how we should be using it (both internally and with clients), and following that process. Something we need to get better at for sure.
Slack for Group Chat:
Slack is now our office. We’re just kicking off our remote experiment and without a physical location, Slack is now the ‘office.’ As a result I’ve been thinking deeply about how we use it. What have we learned? What can we do better?
A 30,000 foot view of how we use slack now:
We have one main room called ‘office’:
Everyone on our team is a member of this channel. This is the virtual water cooler. A place where were can quickly reach the whole team to share milestones, small updates, wins, interesting articles, jokes/memes, sports bets, whatever. In the absence of physical location where everyone goes every morning this is the way we fill that void. This room is more about culture than execution. Generally speaking we don’t put project related items in here.
Then, we have a few internal team specific rooms:
#devops: This is for all of our designers/developers and project managers to keep everyone in the loop about development related items.
#bizdev: This is a channel where we track all of our internal agency biz dev & marketing activity.
Finally, we have a channel for each one of our clients. All of the project stakeholders at our clients have access to our team via slack. This is something we debated about at the beginning. We went ahead and tried it and have stuck with it. It hasn’t been without its challenges, but for the most part we think the good outweighs the bad.
Some things we’ve learned about this setup:
When you make the decision to open up a communication channel like Asana or Slack to your clients, you have to take the good with the bad. The good is that this decision for us has removed a huge barrier to getting things done. Both ways. We have direct access to decision makers and client side team members to get things we need to push projects along. The bad is that the lines are very blurry around who should be communicating directly with who, where and when. There have been a few scenarios where we (both us and the client) will fall into a pattern of communicating sometimes critical project details through one-to-one slack messages. One-to-one messaging is fine, but it can cause a lot of problems if not managed properly. This is something we need to get better at.
We struggle a bit with over communication. Or maybe “over integration” is the right word. For most of our projects we have all of the Asana activity getting piped into that project’s corresponding slack channel. This can be pretty handy because it provides a consistent feed with what’s happening on a given project right in the slack channel. However, the tendency for people to just remove Asana from the equation and communicate directly within slack is almost irresistible. Also, if you’re not careful about managing which notifications from Asana come in and which don’t, things can get lost. Recently, a couple of our clients have told us sometimes they “don’t know where to put things.” “Does this go in Asana or Slack?” “Should I just email this to you guys?” “Is this something we need to put in the backlog?” “Should we wait until the next meeting to discuss this?” These are all fair questions. If the client is confused about the process of where to communicate project details we need to do a better job of managing that flow.
The tendency to default to chat is like a drug. If you get used to instant responses you’ll get hooked. Instant response feels great at first. When you’re the initiator of the conversation you get the immediate gratification of having whatever it is that you’re working on becoming a priority for the person your pinging. You begin to depend on it. You expect it. You get that endorphin rush. It’s a fine line. If your team lets this become the norm not the exception…you can do a lot of damage. It’s like that glass of scotch after work. It tastes so good. Helps you unwind. But if having a glass of scotch is the only way you can unwind; over time you’ll kill a lot of brain cells. Chat is no different. In moderation. At the right times.
Chat can be very useful for:
Chat can be very useful for pairing up for real time collaboration on a specific deliverable. When a small group of people are directly focused on solving a multi faceted problem, using chat to quickly share screenshots, quick screencasts or feedback can be incredibly helpful. We use it a lot in this capacity. For testing the final leg of an implementation, working out bugs, collaborating over UX concepts. etc.
Building a team environment with your clients:
For the most part our clients feel like we are part of their team. Maybe not a part of their in house team, but there is a feeling that we’re working with them towards a measurable objective, vs a tug of war that can happen in a lot of client/vendor relationships. I think having an open chat room with them helps this. Having a place where you can drop a relevant article, or share a story that might impact the client work you’re doing for them…open group chat with clients is great for that.
I use this term carefully. Few things are really emergencies. But, there are times when shit goes haywire and you need to get someone’s attention immediately. When you need something right away, your best bet is probably the phone. But if you can’t get them on the phone pinging someone on chat to get their attention typically works. Be careful though. If everything is a priority, nothing is.
Email for Big Things:
When it comes to getting projects done, email is the devil. Seriously. Over the past 15 years or so, ‘emailing’ has become synonymous with ‘working.’ We need to stop the madness. How many times have you heard someone say, “I’ll be on email working.” OR, “If you need me I’ll be on email.” Email is not work. And just because someone is ‘emailing’ doesn’t mean they’re working or getting things done.
I think we’ve become obsessed with inbox zero. I think we’ve slowly buried ourselves into a culture of deflection. People are trained to get things off their plate. As a result, they sacrifice quality thought and productive collaboration for quick replies to make sure clients or co-workers thing they’re ‘working hard.’ Nonsense. A culture where it’s expected to insta-reply to an email thread is a dangerous one. It can divide team members, create a false sense of competition, make people think that a quick reply is better than one that is well thought out.
As an organization I think we’re pretty good as it relates to email. We’ve gone a little overboard with slack, which probably contributes to that. However, email can be really useful for communicating things like:
Big organizational ideas, thoughts, proposals for large changes in process or operations.
Large product feature requests
Things were you don’t need an immediate reply. Where you’d rather the recipient digest what you’re emailing.
Zoom for Video Conferencing:
When text just won’t get it done and you need that face to face collaboration, we use Zoom for video conferencing. The video conference is a huge part of our culture, but we need to continue to get better at it.
We use video conferences and screen shares for:
Collaboration on Mockups & Designs
Troubleshooting Bugs or Issues
Things we need to do more of now that we’re remote first:
Video team lunches or happy hours
Interviewing new team members
Knowledge sharing sessions
Calls: Sometimes the old fashioned pick up the phone and call someone works the best. Especially if you’re on the road, in the car or on the move you can get a lot done with a quick call.
Texts: Just don’t do it. I mean I guess if you’re running late for a meeting, letting someone know where you’re at for happy hour, or if a bunch of us are at a trade show and have a group text to keep in touch. I’d keep text out of the project communication lineup. 🙂
Killing the addiction to ASAP:
The other day I saw a tweet from Jason Fried of Basecamp. He comments that they were thinking about implementing a ‘sleep-on-it’ feature in Basecamp, where the software would require 24 hours before people can comment. He was talking about basecamp and not email, but I thought that was interesting.
How does your team communicate with remote team members? Are you working with a digital agency? What communication and collaboration tools do you use to work with them?
I’d love to hear your feedback.
If you found this article useful I’d be humbled if you recommended it or hit me with a few claps. Follow me here or @rriggin on twitter as we continue this journey. Thanks.
Ryan is a marketing guy who likes to get his hands dirty with technology and data. Outside of that you can find him out riding a bike somewhere.