Effective Communication in a Remote Engineering Setting

Engineering at Simon is a distributed operation. While remote teams come with many benefits, effective communication is critical, and we’re constantly evaluating and re-evaluating the ways in which we talk with one other.

Simon’s product and engineering team isn’t huge, yet we’re distributed across four states, two countries, and three time zones. We’re constantly evolving and trying to improve the way we communicate within these divides, and here’s where we’re at today.

Communication Goals

Before jumping into specific tools that we use, let’s dive into our communication goals, and then bridge into forms of communication and associated channels.

Transparency across the business

Pretty much anything going on within the business is available to all. With a few exceptions such as individual compensation or HR issues, anything from our Series A pitch deck to our customer contracts to architecture diagrams are available for anyone to browse.

Effective startups are cross functional, and we all wear many hats; we believe that open access isn’t just the right thing to do — it’s also the best way to operate a startup at our stage.

Audience identification

Even with our current team of slightly less than ten folks, information overload can be problematic. Not every update to our sales pipeline requires a blast to everyone in the company. Similarly, not every code check-in requires the attention of the entire engineering team.

To this end, he (or she) who creates the news is responsible for disseminating it to the right people and to the appropriate channels. In the event of miscommunication, we always seek to ask the question “how can we broadcast this more effectively next time”, as opposed to “let’s try to listen more carefully next time”.

Accountability and ownership

Ultimately, communication coordinates execution. The ownership of getting something done, shipping code, and making customers happy is very fullfilling and perhaps my favorite aspect of working at and running a startup. At the same time, with this ownership comes a large degree of accountability, and poor exeuction rooted in bad communication is largely avoidable.

Writing complex Hadoop pipelines is hard. Designing an efficient yet intuitive caching scheme can be very tricky. Tuning a random forest optimized to identify repeat purchase behaviors can be difficult to generalize across multipe datasets.

Communication shouldn’t be as hard as any of these things.

Communication Tools

Generally speaking, we’re pragmatic above all else. We still use email, and we’re not looking to grossly redefine the ways in which we’ve communicated in the past. We’ve been using Slack since day zero and view it as an important tool — effectively a fantastic IRC client — yet not much more than this.

With that disclaimer, here’s the list:

Open Google Docs

We try to keep all our spreadsheets and docs in Google. This is pretty standard amongst many tech companies these days. Yet there’s a little known setting buried deep within the Google Apps Admin panel that enables you to change the default file sharing permissions, and we’ve set this to “available for anyone in the Simon Data org to find and view”.

This is where all customer contracts, NDAs, pitch decks, or architecture diagrams live. Google Docs provides a big step towards information transparency — yet dissimenating existence of this information is largely a function of the channels below.

Slack

We have a multi-room Slack setup. A #general channel, an #accounts channel for discussing client-specific issues, an #engineering channel, a #frontend channel to coordinate with design, and automated channels hooked up to jenkins, github, and our alerting systems.

We view Slack as our primary tool for synchronous communication. I type a message in #engineering, and I receive a response from Matt answering my question: boom, that’s communication.

We view a conversation on Slack as being akin to walking into the kitchen and talking to whomever may be around you at the time. If folks are there, it’s a super convenient way of having a conversation, and we use it actively to this effect.

Yet we view the shelf life of a Slack message to be minutes and not hours; we don’t expect folks to read scrollback or to understand context of Slack discussions that happened earlier in the afternoon. We discourage private messages within Slack for all but the most mundane matters, as it reduces communication transparency.

Email & Google Groups

Everyone at Simon has an email address, and we’re all expected to read the email that we receive. One of the key tenets behind identifying your audience is making sure they get the message. And herein lies the difference between Slack & email; with email, you get a vehicle for guaranteed delivery, albeit with a higher communication overhead.

In practice, for most day-to-day within-engineering announcements, Slack is generally sufficient — if you receive an ack, success! Yet if you’re trying to message more than two people or folks outside of engineering, email is generally more reliable.

And as far as group emailing goes, we’re big Google Groups users — as with Slack, we discourage any direct emails that aren’t also addressed to a relevant group — everyone@, eng@, sales@, accounts@. As far as subscriptions goes, folks in sales subscribe to sales@, engineers get eng@, and everyone gets everyone@. And as with Docs, all these groups are publicly accessible.

Trello

Trello is the source of record for who’s working on what, and also as means for coordinating dependencies between projects and people. Many of our Trello cards are opened by multiple folks; this serves an important function in defining who’s responsible for what and for coordinating work between design and frontend, or between specific customer accounts and new feature releases. We have half a dozen Trello boards spanning core engineering, customer accounts, bugs, and even a reecruiting board.

As we’ve grown, we’ve found that Slack is too unreliable and email is too unstructured, and have started to push much of our coordination-heavy tasks into Trello.

Github

We don’t code review everything we write, but we encourage doing a quick pull request if you’re contributing anything with potential complications or nuances. Recipients of the PR are up to the author.

Skype

Sometimes nothing beats face to face communication. Skype isn’t great, but it’s better than anything else out there today. We’ve experimented with “always on” channels but haven’t had a ton of success here to date.

Recurring offsites

As we’re primarily a distributed team, we make a point of getting together every couple of months for planning purposes — often in the hometown of one of our engineers. These sessions are great for setting strategy and ensuring team cohesion, and they’re also essential for creating space to celebrate our wins and build relationships.

In between these offsites, we encourage folks to celebrate feature releases, new hires, revenue goals, and product goals using any and all channels.

Hacking Corner Cases

Despite the power of the tools listed above, we still find plenty of corner cases where communication becomes challenging. Throughout my career, I’ve often found that these issues are often best solved through creative hacking on the part of the engineering team

One of the areas we found ourselves struggling with recently was sales updates — making sure that everyone on the engineering team had clear visibility into potential customers and their technical requirements. Simply put, if our team didn’t know what integration was going to look like, they couldn’t plan for it.

Salesforce is our CRM, and was not super helpful in solving this particular issue. While we have a login that engineering can use to access the system, navigating the hundreds of Salesforce reports is an exercise destined for failure — particularly in a fast-moving startup. Yet conveying the state of our sales pipeline is super important for everyone in the company.

At our most recent offsite in Austin, in between mouthfuls of BBQ, our frontend/do-everything developer Brendan and I hacked together this dashboard with our sales team. The dashboard is easily findable within our internal intranet — complete with spinning head easter eggs that appear when you click through for more information!

Tools like this tend to have a limited lifespan as the business grows, but are absolutely critical for creating cohesion between functions and making sure that everyone has access to the information they need, when and how they need it.

Making Remote Work For You

In the past ten or so years of my career that’s included grad school, consulting, startups, and large organizations including Google and Etsy, I’ve worked on dozens of engineering teams. Some of these teams have been highly functional and others somewhat dysfunctional. And some of highest performing (and most fun) teams that I’ve worked with have been distributed.

Centralized teams enjoy such niceties such as hallway conversations or regular lunch outings. They can talk amongst each other across their desks, or huddle together in the office conference room. This ease of communication has obvious benefits.

Yet at the same time, this ease of communication for centralized teams comes at a cost of more regular interruption, and I’ve noticed that distributed teams are much more thoughtful about when and who they interrupt. And armed with the right communication tools, I’d also argue that distributed teams can oftentimes be more productive than their centralized counterparts.