Going remote, even when you're on-site
Let's work together!
I'm also available for DevOps project work. Are you fighting fires instead of serving your customers? Hire me to identify the roadblocks and make improvements so you can get back to focusing on your customers.
Over the past few years I’ve worked on opposite extremes of the remote/on-site workplace spectrum. My current employer maintains top notch office facilities complete with chef prepared lunches, bio-walls, lego murals, and slides. Previously, I worked with a fully distributed company of 75+ people that had a strong culture and no physical office space at all.
There are definite trade-off’s to both types of working environments. Whether your team is on-site or on-the-beach, I’ve learned that teams can find serious benefits in adopting remote-first communication patterns.
Remote-first means interacting with your team members as if you all aren’t in the same location at the same time. Even if you happen to be in the same place at the same time, consider these scenarios.
Instead of hitting up coworkers in their cubicles, try having a conversation in a community chat room. People can come along later, read the chat logs, and learn from a conversation that otherwise would have been lost between two people.
Stop handing over half the week to all-hands, hour-long blocks of in-person meetings in conference rooms. Discard conventions like blocking off 30 - 60 minutes and filling the time. Establish a common way to advertise availability amongst your team. Agree to use Google Hangouts for impromptu group video chat as needed. Doing this you can be on the other side of the building or the country and collaborate effectively with your team.
Ditch the obligatory after-the-fact employee to manager status updates. Expose activity streams from actual sources of work: Github pull requests, continuous integration/deployment job results, ticket/card updates, and service status alerts. These activity streams are transparent to everyone on the team. They’re also automatic and give a much more accurate picture than any one person’s recollection of what happened over the course of a week, month, or year.
Remote-first is a transition to an asynchronous culture. It certainly doesn’t eliminate the need for personal communication. It actually elevates the value of communication by destroying artificial roadblocks associated with engaging your fellow team members.
Back to my current on-site work life today. I’ll share one way my team has chosen to experiment with remote-first communication.
I work a team of six people managing technical operations for a variety of web applications and core services. The entire company already communicates and shares activity streams heavily over HipChat.
Still, my team leans on in-person meetings for weekly planning and daily status updates. This has served us well but as the team grows these meetings take considerably longer. It also leaves us feeling disconnected when one of us works remotely for a day.
We’ve decided to replace our daily in-person stand-up status meeting with two things. First, we each commit to updating a list of what we completed yesterday and what we plan to complete today by the start of each day. We’re using a service called iDoneThis to share everyone’s lists.
Second, we’ll each commit to being available during a half hour period in the morning. During this half hour any of us can call for a stand up, on HipChat, Google Hangouts, or in person, if there’s something that requires discussion. If there’s nothing specific to discuss, there will be no meeting.
This new approach aims to cut down time spent reading our status updates aloud. It also aims to keep us informed regardless of where our workspace is.
Time will tell how this change works for the team. Willingness to experiment and make iterative improvements is key. Even though we regularly share the same space I expect the extra flexibility will help us better deliver on both our individual and team commitments.
June 01, 2015