In this article, we share best practices for remote software development teams to more effectively manage and complete projects. These guidelines help ensure that remote meetings, communication, and team projects are productive, even when they happen remotely.
In March of 2020, Headway held a live stream with our team to discuss how product teams can work remotely successfully. We planned on having this online event long before the world migrated to mostly online work environments in the spring of 2020.
Headway's remote-first approach to managing teams, holding meetings, and running projects eased our transition. We hope that sharing our experiences and advice will help others build best practices for creating more impactful distributed teams.
Due to the nature of remote work, it can be frustrating for remote workers to be involved in meetings that happen "in-house". At Headway, all meetings are remote-friendly - even when there are folks in the office. Remote friendly meetings have a few things in common:
For complex conversations, having a voice conversation is better than using Slack. And having your camera on is even better. Humans are very in tune with body language, and that includes body language over video calls. Encourage your team, and any project partners, to turn their camera on. This builds trust and improves the overall relationship. And better relationships create better products.
Clear audio creates clear communication. The best calls happen when everyone has headsets. It results in less delay when talking into the mic and most headsets filter noise around you better than the mics on your laptops.
Our team uses Jabra headsets to improve audio communication.
This is a great way to prevent any disruptions from your end while others are speaking. It can prevent you from butting in before they finish a thought and prevents everyone from hearing you sneeze or cough at random. This is especially helpful if you are in a busy environment. Whether your kids are at home or you're working from a coffee shop, be kind and mute your microphone when you're not speaking. When in doubt, mute yourself.
In today's age, many of us have multiple monitors - but if you can't see my face, you're probably not going talk to me in the same way. Don't be scared or nervous. It's a little unnerving watching yourself on the camera the first few times, but trust me, you'll get used to it. The more you engage with each other, the stronger your relationships become.
Being seen in the right light is important too. Don't be the creepy person backlit by your window. Try to have light sources in front of you. If there are bright lights behind you, turn them off or reposition your desk in the room so that your face is lit more than your back.
It can be really easy to get into the weeds and talk in circles. Just like any other meeting, hold each other accountable, and respect each other's time. You can do this by having an agreed agenda at the beginning of the meeting or designate someone to help lead the group if they notice the meeting is getting off track.
As a remote-first consultancy, Headway works on a wide variety of projects. We work with new startups, established startups, and enterprise businesses. One of the most challenging things to do with a product team is handling project management. With the right tools, you can make the process easier.
Having a collaborative resource for documentation will make a big impact on remote teams. We use Notion for documenting everything we do. It keeps everything we need accessible, secure, and easy to share.
Headway uses MoSCoW prioritization to manage feature development for products that we build. It allows project stakeholders to clearly understand what work will happen, when it will happen, and why on their product at any given time.
Learn how Headway prioritizes feature work:
We use a tool called Stories On Board for roadmap prioritization. It helps bring the product, design, and development together and is an excellent compliment to the MoSCoW method. It provides a clear view of what is getting done, when it is getting done, and compliments agile development methods.
This storyboard tool isn't an issue tracker. Translating storyboard cards into usable tickets for a developer takes work. We don't always work with project managers, and often the role of our lead developer or designer includes project management. This is why our tools and consistent process are imperative to our success. Providing consistency for one another is critical.
Across all our projects, we decompose storyboard items into more consumable tickets to work in and often use a separate tracker for issue tracking. Success starts with having the right tools to achieve your goals and stay on track. Every project has different needs either because of its nature or because of the client's requirements. Here are the tools we have used to manage tasks as a team.
Birdseye - We're building it!
Our projects use different issue trackers at Headway. Depending on the clients and partners involved, the tools can change. We have used Github issues, Trello, Asana, and Jira to track project work. The important thing here is not which issue tracker you decide to use. It's how you decide to use it.
It's important to keep issues up to date and as a remote developer. This is because I can't just stop by a PM's office or a teammate's desk to see how things are moving. The place we must look at is the issue tracker.
We often include it in our Github pull request templates to make sure you check off the ticket (or update the ticket to the appropriate state) in whatever issue tracker you are using. We rely mostly on the following states: "started", "doing", "done" and sometimes we will add in "confirmed" or something else to make sure it passes through QA without any issues. It's easy to share and see what other folks are doing that way.
We use Slack as our main tool for asynchronous communication. It allows us to separate and track conversations for different projects and have quick questions answered with individuals as needed. You can even hop on a quick slack call if needed.
We use zoom when we schedule formal meetings or when we need to go into a deeper conversation about an issue together. We also record meetings to create accountability between project partners and document meetings in case they ever need to be revisited.
Struggling to communicate decisions across members of different teams is a shared failure I've seen many times. Keeping each member up to date on what is happening when and where has always been a challenge. It's one place where remote work shines.
Headway uses Slack to facilitate our asynchronous communication. There is no siloed communication about development, design, or process as we all make those decisions by working in Slack. Even if it's easier to have communication outside of Slack or using a Zoom room. Slack is the tool we use to broadcast those decisions.
When I take a day off, the first thing I do when I return is to read through Slack messages. This allows me to catch up on decisions that were made, work that is inflight, and issues that came up while I was gone.
Since you are unable to have one-off conversations or "just stop by" someone's desk, you have to focus on communication in other ways. An asynchronous tool like Slack solves this naturally with channels. Since there is a log of all communication and decisions being made, it's easier to communicate, discuss, and collaborate.
That means no more email forwards and weird gaps in the conversation.
When a decision is made in a Slack channel, it not only drives the decision in a way that all teammates can see and chime in on. It also lets everyone read that communication when it makes sense for them as well.
You no longer have to worry about getting everyone into a meeting or having a face to face conversation with a product owner because as long as they're in the channel, they will see or read about the decisions that have been made. Decisions can and should also be pulled out of Slack and included in project management tools. This provides the historical context you can link to in the slack conversation. This allows everyone to catch up on the project on their schedule and when it's convenient for them.
Not sure how to begin?
Check out this article for getting started with Slack channels:
If you don't manage it correctly, Slack can be overwhelming. It can be very intrusive into your life with constant pinging and constant updates.
Don't be scared to turn notifications off.
I usually spend at least half of my day with "Do Not Disturb", on my computer. This allows me to check Slack on my schedule and since it's asynchronous communication, you check for updates when it makes sense for you.
Another strategy is to turn off notifications unless someone explicitly mentions you in Slack. This can be helpful if you're in a Slack channel that sees heavy use but you're not directly involved. Or if you just don't want notifications every time someone mentions something.
Besides communication tools like Slack and Zoom, we use a plethora of other tools to make our experience working together optimal. I often hear that teams moving to work remotely have a hard time communicating when they don't have a whiteboard. There are some great tools to help solve this problem.
One big push back many folks have about working remotely is not being able to have "whiteboard sessions." They want to collaborate with their peers in a visual manner. Whiteboard sessions are used to understand problems, scope, and quickly visualize patterns. As a developer, it can be tough to communicate your thoughts in writing. We have found a few tools that allow us to communicate visually online that have, on occasion, saved the day.
From a development standpoint the first tool that I reach for is Whimsical. Whimsical allows you to draw mind maps, wireframes, and flow charts quickly with your team. Whimsical allows you to think and communicate visually without too much friction. Whimsical is used for architecture, code organization, process management, and quick and dirty UI flows.
The other tool we reach for at Headway is Miro. Miro is team collaboration software that feels like more like we are collaborating on a whiteboard. It's great for brainstorming, planning, and user story mapping. It's easy to use, fast, and extremely collaborative. Often we'll leave Miro up during meetings just to share notes. Then we can organize those notes together after the meeting.
Between Miro and Whimsical, rarely am I unable to feel like I'm missing out on collaboration without a whiteboard. Using these tools is often more collaborative, no one is hogging a marker, you can't run out of whiteboard space, and there almost infinite ways to move work into different formats for different learning styles. Another benefit is there is no "translating" step. It's already in a digital format.
Tuple is a screen sharing software built for developers. It allows a seamless screen share and has lots of options for the way to interact with your pairs screen. Tuple also has excellent screen annotation tools. It's the best option for pairing when developers are working in an IDE.
If you're working on a remote server or like the idea of working from a remote server and working outside of an IDE (like using Vim) we use Wemux. Wemux is a tool built with tmux that allows pairing through a remote server. It is very customizable and easy to use once it's set up. Though, if you don't already use tmux and a modal editor like Vim this one is a tough sell.
Headway developers are encouraged to learn Vim and tmux as we think they are valuable tools and we can hone our craft by sharpening out tools. When we each sharpen our tools, we own that process and empower ourselves to work smarter not harder.
Headway developers have collaborated on an incredible Vim setup. Thanks Jon Kinney! It is available via open-source below.
You probably already use version control of some sort. We like to leverage the tools we already have on hand. Git provides a great framework for documenting the "story" of your code and we make sure that our commit messages and branching schemes match the "story" of our software as we build. Over time this allows us to use Git to understand better how our software is built, what went on in specific pull requests, and how certain features were added.
I also like to use pull requests to communicate what kind of work I'm doing. I encourage those on my team to do the same. The intent of a pull request is not to present work that is "finished" and to be added to the code base after a quick code review. The intent is to communicate the code that you are writing to the other developers to ensure that everyone agrees on the structure, libraries, and other important decisions you have made in your code. You're already going to open the PR regardless. You might as well get feedback sooner than later.
On the Even-Keeled Podcast, Jon Kinney discusses the art of storytelling through commit messages, pull requests, and documentation like READMEs.
The final tool we often use for sharing terminals with other developers is tmate. Tmate allows you to share your terminal and ssh into another developer's terminal.
At Headway, we reach for tmate when we need to do something quick and dirty or just need someone's help for a few moments. When we have serious pairing sessions, we'll join a Wemux and happily code with everyone. Both Wemux and tmate are easy to set up and provide a lot of customization. They're great for sharing development work.
While process and approach can be powerful, people are the true heroes that bring projects to completion. Helping every person on your team grow to become better communicators and team players is vital.
We all have a responsibility to lead each other, even if that's not in our title.
The human element of project management is not easy or simple, but if you make efforts, you will see improvement. Below are some of the tools we use to gain a better understanding of each person on our team and how we can all work better together.
Lead Honestly is an automated tool that helps our leadership team have candid conversations about certain topics based on the person's needs. Questions are sent out once a week for our 1-1 meetings that last about fifteen minutes. These help us uncover many issues before they become a big problem. They also help each leader get to know each team member better on a personal level because they are dedicating time to that.
We use a few different approaches to understanding each individual on our team and how we can work better together. From personality traits, key motivators, and how people take action. The friendly folks at Navigate the Journey help us manage these efforts. Below are the tools we use to do that.
Assessments to better understand your team
Taking the time to review how what went well and what didn't go well in a project helps you continuously improve your process and relationships within a team. We wrote an article all about it. If you're interested, check out the link below.
Level up your pair programming and mentorship skills. Jess shares the benefits of pair programming, the pros and cons of different styles, and techniques to get better results.
The key is to take the time to evaluate the tools and methods you have and to not be afraid to try new approaches. While these tools and techniques that have worked for us, they may not be the best fit for you and your team. Our tools change as we identify issues or needs with our team or when new technologies are available. Don't be afraid to try something new.
Rather than getting everyone on a new tool, try a small team first. Listen to your team and share experiences together. See what results you get. This lowers the risk in case you don't see a positive impact. It can be hard to get a whole team onboarded to new ideas or products, but that's where leadership comes in. Become an advocate for the tool and celebrate the positive results together.
See all the ways we can help you grow through design, development, marketing, and more.
A podcast about building successful software. We provide actionable advice around product validation, execution, and promotion.
A show where we go behind the scenes on what it really takes to bring a new product to market.
Receive the latest articles, resources, events, and more!