How to Build Software with a Remote Engineering Team

Building software can be hard. Many companies struggle to translate customer needs into finished software features. More importantly, many times the forecasts and delivery times for roadmaps fail to meet the deadlines imposed by the business. This can cause frustration and friction between engineering, sales and finance teams. Why would you complicate things by considering a remote software engineering team? Our experience is that the remote aspect of software engineering forces your company to develop more professional processes and communication mechanisms that lead to a more successful outcome for everyone.

In order to run an effective remote team you need clear process, documentation, and ownership for each functional area. Although this might sound difficult or painful, it’s worth the effort. Engineers and product managers thrive when there’s a clear structure. We have seen that they will happily embrace a well defined process to build software and make decisions.

A good starting point is to define, agree to, and document how the team operates. Who owns the product decisions? Who decides what goes on the roadmap? What goes into each sprint and what goes into the icebox? Typically this work is done by a product manager, but it only works when that person has true ownership over the prioritization and is only accountable for the KPIs that the company is trying to drive through the product; not the pressure from a sales leader to close a given deal. Our advice here is to define clear KPIs and empower your product owner to make the decisions that need to be made to drive that number forward.

Another important question is how the product manager gathers feedback from customers, prospective users and other stakeholders. Is it done in a weekly meeting that anyone in the company can attend? Is the meeting remote friendly for a designated remote engineer or designer from the team to join? Is there a place in the application to leave feedback or product ideas that anyone can see and vote on? Can people simply throw a new card into a Kanban board in Jira or Trello? Is email or Slack the right mechanism to share these ideas within your team? Whatever the answer to these questions is for your software development team, the most important thing is to decide and document the process in a product wiki so that everyone is on the same page regarding how decisions are made. One added benefit is that any new person who joins the team can refer back to this document and learn without confusion how these decisions were, and are, made.

Another important aspect is how the product features are prioritized against the existing roadmap, against bugs and against other technical improvements (paying off technical debt). The question at hand is how engineering and product interact and make decisions. Once again, whatever the answer, document and communicate the process to ensure everyone is on the same page.

This investment in process and documentation will pay off in the long term. Instead of having one-off conversations after the meeting, managers and peers (remote or co-located) can refer back to the wiki, get up to speed and follow the process and the agreed direction. Every process needs to be documented and every decision should be accessible for others to read.

Following these basic documentation steps to capture how decision are made is a great starting point. After this, we need to organize the team and get to work. We see most companies following some version of Agile to actually design and build software. For many this only means that they have daily stand-ups, but there’s much more to Agile than that.

We recommend using Dual-Track Agile to help remote software engineers and product teams collaborate effectively. With Dual Track Agile, the idea is to have a discovery sprint, led by the product manager in collaboration with designers and engineers. Here is where customer discovery happens and validated backlog items are added to the sprint. At the same time, there is a delivery sprint happening which is all about executing on what was planned in the prior discovery sprint.

Once you’ve set up a proper rhythm around discovery and delivery sprints, you should include all the known pieces of Agile or Scrum into your daily, weekly or monthly cadence. This ensures that everyone in your software development team knows what they’re supposed to be doing. These scrum ceremonies should include:

• Planning
• Async Daily Stand-ups
• Sprint Reviews
• Retrospectives

Now, in order to make this process remote friendly a few things need to happen:

• Ensure that all meetings are properly scheduled in a calendar, with all the necessary people on the invite list and most importantly that everyone gets equal access to all the information or context that is being shared. If you truly want to have a remote team, then everyone should be able to dial into a Zoom conference call or join a RemoteHQ room – even if they are co-located. Don’t have three people in a room with a fourth person dialing-in trying to make sense of what’s being said or scribbled on a whiteboard or what’s being communicated through body language. Every remote engineer needs to feel like a first class citizen for remote work to succeed.
• Document everything to allow for people who aren’t in the room to get up to speed. Remote engineers who are in a different timezone might not be able to attend and in order to get up to speed they need access to what was discussed and decided in these meetings – documentation is key. This is why meeting minutes and product decisions need to be accessible via a wiki like Notion, Confluence or Tettra. This takes work, but it makes you a stronger company in the end.
• Don’t forget that everyone in your company is human. Establishing a human-to-human connection among your co-located and remote people is probably one of the biggest and oftentimes overlooked challenges of building software remotely. A good starting point is to encourage people to say ‘thanks’ or ‘celebrate’ wins in a visible way for the team to see and join in conversation. This will align everyone to push in the same direction, agree or disagree and commit!

This is a brief summary and good starting point if you’re considering working with a remote software development team. Some of these best practices will set you off in the right direction to ensure that your remote engineering team is effective and happy. In order to successfully build software while taking advantage of the benefits of remote software engineering you might need to accelerate the your use of internal documentation and collaboration processes and this will help you build software more effectively and prepare you to scale.