Communication and Transparency in a Distributed Workforce
By: Skylar Norris
Tags: Remote Working, Remote Work, Startup, Remote, Distributed Teams

Whether you’re already a seasoned remote employee, or you’re just looking to get in to the space, there’s two terms you’re bound to hear over and over again, without fail:

Transparency and over-communication.

“We’re a transparent company,” they say.

“We work in the open.”

“We have a culture of transparency and over-communication.”

Sound familiar?

Transparency is, without doubt, a necessity for the success of a remote or distributed organization. Unlike a traditional office where information is consolidated in to one physical location and questions can be answered simply by stepping in to someone’s office for a chat, remote or distributed companies have to go above and beyond to combat one of the greatest time consumers people face: information access.

When you’re communicating asynchronously, this is especially true. A conversation that might take 1–2 minutes in an office, can — and often does — take 1–2 days in an remote organization. The reason for this? Communication and transparency.

In order to be transparent in your work, you must adopt a philosophy of over communication which, in itself, is a form of transparency. In essence, it’s a two step process.

Rather than define what it means to be transparent and over communicate (you can easily Google this), I want to show you some real-life examples of how to integrate this in to your day-to-day work.

Step 1 — Over Communicate:

For many companies (with few exceptions — I see you Automattic), email still reigns as the primary form of formal communication. I say “formal” because Slack and other collaboration platforms are highly active informal communication methods that are used by the remote / distributed workforce to keep in touch throughout the day. The problem, though, is that sending someone a DM on Slack for information may or may not ever net you a response. Posting important team updates in a channel likely means someone will miss it— either due to timezone discrepancies or because six other people posted updates right after you did; now yours has been lost to the scroll factor. Slack is ephemeral and, especially for distributed organizations with people around the globe, it can be the complete opposite of transparent.

But this isn’t an article on the downfalls of Slack, so let’s get back to email.

I use email as my fail-safe and I make it publicly known to my team that if they wish for information to reach me they should default to emailing me first. That being said, nothing annoys me quite like receiving an email that reads something like this:

“Subject: All Hands

Hey, do we have an All Hands coming up? I wanted to present something.”

Okay, so this is good — a team member (let’s call him Gabe) being proactive about wanting to present, right? Right. However, Gabe just created a time sink; what should have taken five minutes of both our time will now likely take at least a day. Let me explain.

I check my email three to four times a day (if you’re someone that checks their email 600 times a day, kudos to you, but I’m a firm believer in work / life balance). Assuming I received this at the end of the day, I doubt I would respond until the following morning. Without more information to go on, my response might look something like this:

“Re: All Hands

Hi Gabe,

Yes, that is correct. What were you thinking? Do you already have something prepared I can review?”

And now we wait for a reply:

“Re re: All Hands”

Great! I was hoping to present something on the new integration I’ve been working on — I have something sort of put together, would you like me to send it over?”

And so it goes, on and on until we’ve worked our way down to an answer. Hopefully before Wednesday arrives. I call this “the back-and-forth factor.”

When you’re distributed or working remotely and you need information from someone, always assume they have no idea what you are talking about from the get-go. The burden to find information should never be on the receiving individual. Any time you’re trying to solicit information from someone, any work that you’ve already put in to the topic should be outlined so clearly that only actionable feedback is necessary (ie: one email there, one email back).

Let’s rework this email with over-communication and transparency in mind:

“Subject: All Hands

Hey Sharon,

Happy Monday! I noticed that we have an All Hands call on Wednesday, the 6th at 11:00 AM PST. Last week Jamie mentioned there was an open invite for presenters on this call. I’ve put some thought in to it and I would really like to do a five minute presentation on the new integration I’ve been working on this quarter.

Here are some links to the work itself: (insert links here)

I’ve also included an draft presentation for your review, which I’ve attached here.

I’d love to get your feedback on the second and third points, specifically. If I do not hear back from you by EOD Tuesday, I will assume we are set on presentations and put this on the docket for next week instead.”

Notice the difference?

Everything I need to know has been outlined for me upfront. I know how long the presentation is going to be, I know the topic the presentation is on, I have direct access to the work, a draft of the presentation itself, and I know exactly which points this person would like feedback on so my response can be scoped accordingly.

This philosophy should apply to all areas of written communication. It doesn’t matter if your company uses Trello, Asana, Github, etc. to collaborate. If you’re writing an announcement, updating a project status, soliciting feedback, or shipping something out to the rest of your organization — there should always be background, links to relevant information about the topic, dates, timelines, and most importantly, direct questions.

Don’t be the person that wastes others’ time because you did not put in the effort to mitigate the back and forth factor.

Step 2 — Make it Transparent:

Long ago I started working as though no one had a clue what I was doing during the day. I stopped thinking that my manager would know what our priorities were when we met for our 1:1’s or that anyone followed my Github repo which beautifully outlined my to-do lists each week. I gave up believing that even emails sent to the right people were read and quickly became tired of getting emails back asking me where I was at with this project or that proposal.

If you’re a distributed or remote employee understand that posting information in one place is never going to be transparent enough.

Emailing the right people directly means still getting Slack DM’s that say, “Hey, what’s the status on X?” Writing an agenda for your team call ahead of time and posting it in the team channel doesn’t mean John is going to look at it and add his items as requested.

Keep in mind that people in distributed and remote organizations often work very differently; programmers might turn off their Slack notifications in order to focus on writing code, CEO’s might disable the email feature on Github because they’re already inundated with notifications from other outlets. The safest bet is to always assume at least one person is not following the platform you’re using to communicate.

Before a team call I usually write up an agenda in a Google Doc and make sure all of my major points are outlined. Then I email that agenda to my team (if you’re not familiar with Google Groups, you’re missing out on a useful transparency / mass communication tool), post it in the respective Slack channel, update my Github issue with a link to the Google Doc, and even add it to the department page so the rest of the organization can see what we’re discussing that day.

Let’s review this, quickly. For one meeting, I’ve sent out, or posted, an agenda through:

Email / Google Groups

Slack

Github

Drive

That’s four different outlets. If someone in Spain is asleep and misses the Slack notification, they have three more chances at finding that information in their email and through the team drive.

From there, to take it one step further, I add that agenda to my running weekly Task List that I keep pinned on my Slack profile. Anyone can view that Task List at any time.

In distributed work, very few things should be a surprise. If someone has to ask me where my proposal is or what my priorities are that week, I’ve done something wrong.

Let’s take that email scenario from a bit earlier and extrapolate that into transparent over-communication.

Assuming I agreed to add the integration presentation to the weekly All Hands call, the first thing to do is send an email back to my team member with my feedback points and ask them to add the new item to the All Hands Agenda (you wanted it, you need to make sure it gets on there). Because the presentation is now approved, it means there has been a change to the meeting schedule, so I’ll want to copy the relevant All Hands leads on that reply email to make them aware (and now they can see the email exchange up until this point) that we have a new demo to include.

Following the All Hands call everyone in the organization receives an email with a video recording of the call (in case they missed it) and a copy of the agenda. In that email, I should be able to click on the agenda item link for Gabe’s presentation and have it take me to his Github issue. In it, I can find copies of his slides, links to relevant code or work, and drop comments if I so desire. For transparency sake, we’ll also post the email notification to Slack and notify the @channel that a new recording is available. The agenda itself, along with the recording, will be saved in the All Hands Meeting folder, which can be accessed at-will by team members.

No one should ever have to say, “So, what did I miss?” in a distributed or remote organization. Ever.

Think of over-communication and transparency as a way to protect — not others — but yourself. When you adopt a philosophy of working this way, you’re opening up your work to an entire organization. You might receive feedback on a half-completed proposal, or have team members drop comments in to an outline that you’ve barely started, but that is the little picture. The point is that you’ve done your due diligence to make sure that you’re working in the open; you’re creating access to information, not blockers. More importantly, you’re saving yourself and your organization valuable time.