5 Best Practices for Managing a Remote Engineering Team
5 Best Practices for Managing a Remote Engineering Team
Take a look at these 5 remote practices that promote code ownership, productivity, and a strong work culture.
Join the DZone community and get the full member experience.Join For Free
Managing a remote engineering team may not have topped your list of skills to acquire in 2020. However, the global pandemic made other plans for us this year. Remote work is now the new norm for software organizations, which is sending engineering managers scrambling to figure out what works best for communicating, collaborating, and coordinating from home.
As luck would have it, I’ve become something of an expert at managing remote employees. My experience began in the early days of Bugsnag when my cofounder and I needed to hire engineers for our fledgling company. As San Francisco transplants, we had many roles to fill and wanted to take advantage of our networks back in the UK. In the end, we decided to build our company with an ocean and an eight-hour time difference between two offices.
That was back in 2015. I’m happy to report that our success with remote work over the past five years encouraged us to hire an entirely remote front-end team last year and to open up our work from home policies (pre-pandemic) to all employees. While there are benefits and pitfalls to remote work, a handful of best practices can go a long way towards making the entire experience fruitful and enjoyable for everyone.
Treat Remote Work as If It’s Asynchronous
My biggest takeaway from the last five years is that remote work isn’t anywhere near as challenging as coordinating and collaborating across time zones. Everything gets magnified with time differences because the overlapping hours in the work day tend to be few, which forces everyone to be extremely efficient with time.
In comparison, employees who are remote but work on the same schedule can fall back on synchronous communication. Rather than depend on this safety net, my advice is to act as if communication must be asynchronous. When employees behave as if there’s an ocean between themselves and their colleagues, everyone becomes more invested in efficient workflows, disciplined processes, and a thoughtful and organized approach to collaboration.
Five Remote Practices that Promote Code Ownership, Productivity, and A Strong Work Culture
To supplement that suggestion, here are five best practices we’ve learned at Bugsnag that ensure success with remote team management.
#1 The ABCs: Always Be Communicating
Hands down, communication is the single most important component of remote work. Without consistent dialogue between engineers and with other team members, you risk inefficiency around design, development, testing, and releases.
The most challenging aspect of remote work is the loss of serendipity from being in the office. Think of all those lunchtime discussions that aren’t happening and all those casual exchanges across the room where anyone within earshot can pipe up and join the conversation. These day-to-day moments are not only informative, but they often lead to bonding between colleagues and contribute to company culture.
While you’ll never fully replace the ease of communication that comes from an office setting, video chats are a solid second-best. Rather than have an extended dialogue over direct message, I always recommend employees jump into a quick Zoom meeting for two reasons:
Body language is important. It’s better to talk in person than languish at the keyboard, especially if things start to feel awkward or off-track during a written chat.
Tone matters. When you’re physically present on video, it’s much easier to detect sarcasm and make a joke that lands properly.
With a communications tool like Slack, a /zoom command shortcut enables users to launch a video meeting on the fly, and everyone in that channel or DM is prompted to join. In addition, video conferencing makes it easy to spin up a quick three-minute meeting—something that doesn’t occur often in the office environment because meetings tend to be scheduled and last a minimum of fifteen minutes.
Another asynchronous communication tool we use at Bugsnag is Status Hero, which is an automated stand-up tool. Status Hero provides a holistic view into what each engineer is working on, what’s blocking progress, and what work has been completed. Thanks to integrations with tools like Jira, Github, and Bugsnag, a lot of the stand-up information is filled in automatically, which saves valuable time. Status Hero is also customizable, so managers can determine what information is most important for the team to share every day.
#2 Aim for Complete Clarity and Document Everything
Coupled with constant communication is the absolute need for clarity. When working across time zones, this issue is rather acute. If something you’ve written isn’t crystal clear, the other person may lose an entire work day waiting for clarification or waste time and effort doing it the wrong way.
Even if remote work is synchronous, back-and-forth cycles are undesirable, inefficient, and disruptive. That’s why I recommend doubling down on what’s written and documenting everything. Developing and honing clarity with written communication minimizes lost work in every scenario and is a skill all engineers should develop.
At our company, engineers are encouraged to preempt questions by showing their written work to someone else for honest feedback and assessment. That way, questions can be addressed before information is passed along to a broader audience and causes widespread confusion.
The same thing holds true with Jira (or whatever ticket tracking tool you use). When someone takes a ticket to work on a bug or new feature, he or she shouldn’t need to talk to the person who authored it. Every ticket should be written as clearly as possible.
#3 Inject Efficiency and Purpose Into Scheduled Meetings
Let’s be honest: In-person office meetings can sometimes not be the most efficient use of people’s time. It’s too easy to book an hour on the calendar and then waste a huge chunk of that time. Worst of all are meetings that sit on the calendar out of habit. For example, development sprints have a retrospective at the end, which is sometimes valuable but often unnecessary, especially if teams are communicating properly throughout the sprint.
Therefore, I recommend that, before any meeting is scheduled, there must be an agenda and clear goals for the conversation. By being dynamic and flexible about “established” meetings, you can aim to only hold those that are productive and required to get something done that may not otherwise be accomplished.
As an alternative tactic to meetings, I keep a list of items that team members have voiced the desire to discuss as a group. This strategy makes everyone think through which topics actually require a conversation. If an idea can be discussed in a smaller meeting or via collaboration in a document, then it’s a more efficient use of the team’s time to do that.
#4 Ditch Whiteboards for Transparency
We’ve replaced the majority of our whiteboards with document-based processes in Confluence and ad hoc Zoom calls. Rather than start a project with ten people in the room and hold numerous meetings to flesh out ideas, our engineers and product people develop ideas in writing first.
By building out docs in our wiki, time is invested upfront to determine what exactly is being tackled and what the goals are. While engineering designs may be more fun on a whiteboard, we’ve discovered that developers do a lot more planning upfront and really think through their ideas when they write them out. With wiki-based collaboration, ideas are hashed out while being documented at the same time.
A key component of this document-based design process is transparency. Engineers work out in the open in the wiki, where anyone in the organization can pop in and provide feedback to help flesh out an idea. With collaborative documents, visuals and technical diagrams can also be added (we use draw.io inside Confluence documents), and integrated approval tools allow the document owner to add the people who need to review it.
From a management perspective, I always try to identify team members who are holding their work too close and don’t want others to see it or contribute ideas. I believe it’s important to review early and often so no one gets too far down a path without feedback. That’s a surefire way to lose time and waste effort, especially when working from home.
Of course, we do still hold synchronous meetings as needed. Team members are brought together to discuss ideas when we want to inject collaborative energy or brainstorm something that’s stumping everyone. After all, there is a time and a place for in-person meetings, and it’s important to have a good balance.
#5 Promote Human Connections
When our company decided to staff a fully remote front-end team, I spoke to Michael Neale at CloudBees (the company that built Jenkins) to solicit his advice. He gave me a simple rule: Require everyone to turn on their cameras in video meetings to encourage the human connection.
This advice has been invaluable. Physically seeing each other, rather than listening to a disembodied voice, breaks down barriers and delivers a sense of interrelatedness and availability. And sometimes, it’s just nice to have a chat and watch the other person’s reactions. After all, work is one of the places where many of us scratch that human itch to be social beings, and we need that outlet now more than ever with remote work.
We also adopted Donut, which pairs two people for a chat once a week. We’ve found that Donut enables employees from different teams to easily talk to one another who might otherwise not. In short, Donut replaces the random socializing that occurs in the office at the proverbial watercooler, which is an important element of the workplace.
Strong Remote Practices Build Stronger Teams
We’re living through an unprecedented situation that’s changing the rules of engagement at work. While the general practices around collaboration, communication, and coordination described here are all sound, the actual processes and tools you select must be a cultural fit for your team. After all, every team is unique, and buy-in is crucial for success.
The silver lining with remote work is that it naturally promotes code ownership and turns visibility and transparency into things that engineers want from each other. And those are traits that will make your team a better engineering organization today and in the long run.
Opinions expressed by DZone contributors are their own.