Working as a distributed team can be tricky, but if you do it right, it can be great. I’ve been a remote developer at BackerKit for three years. It’s been a great ride. In this post, I’m going to share some of the things I’ve learned, and what product teams can do to make it all work.
It’s important to reduce friction wherever possible. Just because a team member is remote, doesn’t mean it has to feel that way. Remote team members can feel like full team-members, and the on-site workers can feel as though they aren’t slowed down by the fact that other people are remote. Being thoughtful of the five modes of operation will go a long way when finding the best ways to communicate. Those modes are:
- Holding efficient distributed meetings
- Maintaining a permanent telepresence portal
- Effectively remote pairing
- Leveraging digital organization tools
- Embracing casual interactions
Each of these modes are important in their own way, and each involve different considerations to optimize interactions between team members. The omnipresent challenge in each of these modes is reducing the friction that the distance creates. With a little thought and a little attention to establishing effective habits and protocols, the telepresence technology can blend into the background, and remote-teams can be incredibly effective.
Holding Efficient Distributed Meetings
Being remote doesn’t mean being absent. Things get better when remote workers are fully present at meetings. Being a remote participant at a meeting is familiar to most professionals, as is the friction that can go with it. Reduce that friction.
For small-ish teams, keep it simple. What works for BackerKit is a simple Google Hangout sessions with a high quality microphone. We use the Jabra Speak 410 for smaller meetings and the Jabra Speak 810 for larger ones.
At BackerKit, we’ve established the convention that the person who is the organizer of the meeting in the calendar makes sure to have a computer pointed at the Hangout before the meeting begins. Google makes it easy to attach Hangout URLs to Google Calendar meeting events, and you can even configure your GoogleApps domain to add Hangouts to new appointments automatically, making it all routine and thoughtless. Each meeting is also linked to a GoogleDoc with a meeting agenda and notes (more on that later).
Once we decided what our meeting telepresence setup looks like, we realize the details aren’t as important as the clarity of the decision. Like so many things, what is actually decided isn’t as important as the fact that it is decided. And that decision has to be known by everyone. Friction has been reduced.
Maintaining A Permanent Telepresence Portal
It’s also important to be accessible outside of meetings. For smaller teams with less structure, and with fewer formal meetings, this is especially important.
First, it is important that remote team members be full team-members, and be as accessible as the on-site folks. It’s natural to choose the path of least resistance, and if there is more friction in speaking with a remote team-member, people in the office will always look for an on-site team member first.
At BackerKit, we have an open office plan, and in our development corner, we have an always-on video chat set up. Remote developers are expected to be accessible there when not pairing, in meetings, or purposefully absent to deep-focus on something. Presenting the remote team members as friendly faces in the office with an always-on, static location lowers friction, and opens doors to a conversation that would otherwise not happen. Reducing the friction can almost make the distance disappear. When people don’t have to fiddle with headphones and microphones, it works wonders for making remote workers feel truly present.
Having an always-on connection provides the remote team members with ears in the room. When remote developers are not pairing, it’s great to be able to not only participate, but also just overhear all of the casual conversation that happens in the developer’s corner. Having just a bit of reference to what the team has been talking casually about gives remote workers the important context they need to tackle assignments, and to effectively participate in more formal conversations at later meetings.
Having an always-on connection also provides the remote team members eyes in the room, which, it turns out, reduces friction further because remote devs don’t have to wonder who is currently pairing, who is at lunch, if the project manager is available, which developers might be available for a quick chat, and so on.
At BackerKit, we use the Pluot/Daily service for our always-on connection. It’s simple and affordable. They provide dedicated little Linux appliance which can be connected to a monitor or TV via HDMI or DisplayPort, and a decent USB speakerphone. We configure the appliance to always join our static conference room and leave the thing on all the time so that remote developers can drop in with no friction, using their own dedicated hardware or via a free browser.
Effectively Remote Pairing
Pair programing is an esoteric art, and remote-pair programming has its own challenges. It’s important to have an established routine to set expectations, synchronize schedules, and help reduce setup friction. At BackerKit, developers are expected to come to stand-up having already breakfasted and caffeinated, and be ready to pair one minute after standup. We rotate pairs, and we don’t close our five minute stand up until we know who is pairing with who for the day.
We have our sharing technology worked out (Screenhero*) and it is fired up and ready to go right after standup. Remote devs don’t drop out of the standup Pluot/Daily room until they are joining a pairing Screenhero connection so there is no time lost in transitioning between portals. Having these expectations settled and routines established helps pairs get up and running quickly.
*Screenhero has merged with Slack. The stand-alone Screenhero software will shut down on Dec 1, 2017. Most of the functionality of Screenhero is now available in paid versions of Slack.
Leveraging Digital Organization Tools
If you want to enable remote-work, consider remaining just a tad more organized than you think you need to be as your team grows. Organized knowledge repositories and well-defined asynchronous workflows become more important as more people are involved. It eventually becomes impossible for a Product team to hold all the acquired knowledge in their heads, and tools become necessary just to understand what everyone is working on. Fairly standard product team organizational tools and best-practices can be leveraged to address these challenges. These tools and practices provide additional value to distributed teams because they foster information transfers into modes that aren’t dependent on co-location and synchrony.
Organization is always a work in progress, but at BackerKit, we try to have a place for everything and everything in its place. Notably, we’ve had some discussion about where this information should live. We’ve considered separate repositories on GitHub, Google Docs, and other wikis. We aren’t in love with the GitHub wiki in particular, but we’ve realized that having a clearly dedicated place is a better approach than delaying organizational decisions. We can always move the information to a different platform if we change our minds. Again, clarity of process is far more important than the process itself.
BackerKit is a fully agile shop, and we’ve always broken our work into stories and tracked them in Pivotal Tracker. As our team has grown, we’ve found the need to include more and more information about stories in Tracker, but having verbose stories really helps the remote developers who may have slightly reduced access to casual conversations with our product manager and designers.
Use a messaging system that isn’t email. It makes communication better and is especially helpful for remote team members who have reduced access to conversations and the sticky-notes you would otherwise be putting up on the wall. We use Slack (and Hipchat before it). If something is important or needs to go to the whole team, it goes in our Dev/Product Slack channel. Unlike conversations, Slack can include links. Unlike conversations, Slack persists and is still there when people who are absent return. And unlike conversations, Slack doesn’t disrupt the paired-development.
We have specified times for certain types of discussions. These include morning standup, weekly retros, weekly 1-1 meetings with team leaders, monthly developer’s technical discussions, and security reviews. Having a time-and-place for these things is generally a great idea because it helps keep designers and developers focused on the task at hand – allowing them to prioritize more easily, and rest-easy knowing that there will be a forum to discuss issues that crop up during work.
Every standing meeting has a living GoogleDoc attached to a calendar appointment. Each one has a living agenda on it and team members are free to dump things into that agenda during the work intervals between meetings.
Corralling conversation this way is not only a great way to organize thoughts for growing teams, but it goes a long way in keeping remote folks in the loop. As much as our always-on Pluot connection provides ears in the room, remote-workers will inevitably miss a non-trivial amount of the casual conversation. By trying to corral non-urgent substantive discussion into formal meetings, remote-workers have the ability to more-fully participate.
Having semi-formal documentation of knowledge-earned and work-to-be-done serves a primary function of allowing larger teams to work together. It also works wonders for bridging the distance and working asynchronously.
Embracing Casual Interactions
Establishing deep relationships takes face-time and downtime – and there are no fully effective shortcuts. Distributed teams need to be especially cognizant of allowing space for casual interactions, and they also need to get together in meatspace sometimes.
Having remote workers feel ‘present’ means carving out spaces to be social and allowing relationships to breathe. This supports team members to be empathetic human beings and helps build trust. This can be the most difficult challenge for distributed teams. Establishing rapport, especially with the non-developers, is hard. Simon Sineck says it well in his “Millennials in the Workforce” talk:
There should be no cellphones in conference rooms…. “When sitting and waiting for a meeting to start … everyone should be focused on building relationships. We ask personal questions, “How’s your dad? I heard he was in the hospital.” “Oh he’s really good thanks for asking. He’s actually at home now.” “Oh I’m glad to hear that.” “That was really amazing.” “I know, it was really scary for a while there.” — That’s how you form relationships. “Hey did you ever get that report done?” “No, I totally forgot.” “Hey, I can help you out. Let me help you.” “Really?” — That’s how trust forms. Trust doesn’t form at an event in a day. Even bad times don’t form trust immediately. It’s the slow, steady consistency and we need to create mechanisms where we allow for those little innocuous interactions to happen.
Remote folks can consider being a few minutes early to meetings or staying online for a few minutes afterward to create opportunities for casual non-work conversation. This is another reason why having the telepresence-tech well established is so important.
But this still won’t be enough for distributed teams. There is absolutely nothing (yet) that can replace full face-to-face interaction. As great as the various telepresence solutions are, they are not high-bandwidth-enough to establish deep relationships.
At BackerKit, our remote developers spend more than four weeks a year on-site. This includes an annual 3-5 day corporate retreat where the entire company is offsite, where the agenda gives a generous amount of downtime. These times are essential. The telepresence in-between keeps the relationships alive, but meatspace is usually where they are built and evolve.
Remote workers should try to visit often, especially with rapidly growing teams with lots of new faces. It’s the moments of down-time and non-work time where real trust and empathy are built. Remote folks need to go to the office often to share in that, break-bread, and share beverages (caffeinated or otherwise).
Notes on Distributed Teams and Company Growth
BackerKit has grown significantly in the past two years, and each stage posed significant but overcome-able challenges. We’ve learned a lot, below are just a few of the highlights.
Small distributed teams don’t have to think too hard about it in the beginning, but once a team reaches a certain size, they will need to decide if they are willing to commit to making the ‘distributed’ thing work. Remote workers can’t make it happen alone. Even with the simplest telepresence setups, someone will need to be in the office to turn them on. But with a little thoughtfulness on both-sides, it can work well.
Three years ago, having a distributed team as a small company was easy. Location wasn’t very important. The conversations were always small enough that remote workers were able to fully participate, either via A/V telepresence or our main HipChat room. Hearing everyone was easy, and microphones weren’t an issue. The lone remote-developer (me) of our six-person company was always either pair programming, or on the always-on Google Hangout in the small office room. We were not incredibly organized, but we didn’t need to be. It worked.
As BackerKit grew larger, distributed work got harder. Being big enough to need a procedure, but not big enough to have it all worked out, was a hard time for us to be distributed. Conversations became more fragmented. Everyone was doing the start-up scramble, meetings were sometimes ad-hoc, and we often didn’t have the patience to work out the telepresence technology. Not everyone on the company needed to be on every thread, and it took a lot more thought and attention to make sure that remote workers were part of the conversations they needed to be in. At these early growth stages, it was essential to have a guardian angel for the remote-workers in the office– someone who was always willing to restart the Google Hangout and own the telepresence technology. (Thanks Kaz!)
As we grew larger and decided that we were committing to being organized and being thoughtful, being distributed got much easier. Once we had two or three pairs of developers working in our code-base, we quickly developed the infrastructure and procedure we needed to keep our work organized. We solidified our organizational procedures and culture, started using google-calendar religiously, and started to cross-reference everything. It became easier for a remote team member to plug into our process, see the landscape for the week/month, and contribute. We also took on an office manager (Thanks Annie!) who worked wonders to get our technology needs worked out and make the rooms work for remote team-members.
Making it all work
Be thoughtful. Define your different types of team interactions and optimize them. Reduce the friction wherever possible, and don’t forget to be human. The BackerKit Product Team is proof that having remote developers can work well.