What is a remote engineering team?
Remote engineering team typically sits away from the company “headquarters”. Two main reasons for working with such a remote engineering team are technology competence and cost efficiency. Often times the remote engineering team is a third party outsourcing company.
Since you will be working with a remote engineering team, probably halfway across the world, you might run into some issues initially. But the best part is, once you overcome these issues, the remote team can become a strategic asset. BeautifulCode has more than five years experience in working with clients from various industries/countries and in this article we summarize our learnings. These recommendations are for fairly large projects that span over six months to several years.
- Work with a fully managed remote engineering team instead of several individuals. Select your team after doing a small project with multiple teams. This basically serves as a paid interview.
- After choosing the team, onboard them by providing the business context for involving the team. Do the necessary training and more importantly set the right expectations from day one.
- It is recommended to have a “product sprint” along with the “development sprint” especially given the distributed nature of teams.
- Do at least two meetings every week. One of them can be sprint planning/sprint retrospective. Use the other meeting to discuss open questions, launch plans, etc.
- Plan for couple of hours of overlap in work timings if the remote team works in a different time zone.
- Last but not the least, meet the team in person. Personal touch can work wonders.
Keep it simple. Work with a fully managed team.
The team structure and composition is one of the most crucial decisions that you’ll take as the business stakeholder or the product manager. Broadly speaking you have two options to structure your remote engineering team.
Option 1 – Handpick your team members from various parts of the world.
In this option, you typically research on freelancers and contractors and assemble your team. Following are some of the pros and cons of this approach.
- You can hand pick talent from wherever you want. Theoretically you get the best people for your job.
- The onus is on you to manage the team and set them up for success. Working across multiple time zones can be quite challenging.
- You’ll spend a disproportionate amount of time and energy in finding the team members and building a cohesive unit.
- Managing several people is not so easy. You will have to double as project manager as well. This simply means that you’ll spend lesser time on what you should be doing – thinking about the product roadmap and product features.
- Risk: If you are working with 3-4 individuals from 3-4 countries there is always a possibility that one of them would want to leave your project. Now all of a sudden you have lost your only designer or the only frontend developer and are faced with the challenge to hire someone ASAP so that the whole team is unblocked.
Option 2 – Work with fully managed remote teams.
This is usually achieved by contracting your projects to established companies (or vendors) that specialize in niche technical areas. Large companies also setup “captive centers”, that are fully controlled subsidiaries that take advantage of low-cost location and low-cost personnel.
- Managing technical talent is handled by the vendor and you can focus on the business and strategic initiatives. Typically there is one point of contact, often an engineering manager, who is responsible for the delivery of the user stories or planned milestones.
- The entire team of designers and developers is under one roof. This means the decision making/knowledge sharing is seamless and you can target more aggressive project timelines.
- There is very limited risk of individuals leaving the team. Since the team is “fully managed” you need not worry about finding a replacement. The engineering manager will find a replacement and work with her.
- Selecting the right team: There are chances that the team as a whole might not meet your expectations. You should choose your remote engineering team carefully. Always start small (try out a less critical project) and try out a couple of different teams. Once you have chosen the team increase the scale of engagement over a period 6 months to 1 year.
Given the above two options and their pros and cons, it is easy to see why you should work with a fully managed remote engineering team.
Onboard the team
After you have selected the team, onboarding the team sets up the expectations and aclimitizes the remote team to your working style and culture. Onboarding would typically involve:
- Agreement and NDAs: Make sure that you have the right contract/NDAs in place before you start any major work. Once you have NDAs in place you’ll be comfortable in sharing the context of the problems that you are trying to solve. This context will help the team empathise with user and design better solutions.
- Explain the context: Your remote team may or may not have built solutions for the problems you are trying to solve. Before they start building the application explain the industry and the business. Explain what your company is trying to accomplish with the team. This context will help the remote team appreciate the product and the features they are trying to build.
- Set expectations: Talk about the best case scenario of the engagement. Talk about delivery expectations. Be clear about who is responsible for what. Ex: You expect the MVP (minimum viable product) to be delivered in 8 weeks. You expect all P1s to be fixed within 24 hours.
- Training: You can definitely expect your remote team to be adept at agile practices and be familiar with standard tools like trello, github, google docs, wireframing tools etc. But you should invest some time to help the team understand specific tools/processes that your company employs.
The delivery process
After you have on-boarded the team, you should figure out a delivery process i,e how does your user stories implementations end up as shippable features. At BeautifulCode most of our successful projects have followed the below version of Scrum with a 2 week sprint cycle. The key insight from our experience is that by making parallel progress in product definition(via product sprints) and product implementation(via development sprints), we setup the delivery operation for high velocity.
Product sprints (aka backlog grooming) – The velocity of delivery will be easily impacted if the team is unsure of the long term vision of the project. Backlog grooming helps in feature prioritization and help start off the initial business and user research exercises that validate the feature value of what is going to be eventually built. Building software for the sake of building software is not smart. Ensuring the software built will deliver value to its users is the key. The product sprints help build this business clarity.
Usually the product owner, the designer and the engineering lead are active in the product sprint cycles. The goal of these parallel sprint cycles is to ensure that the most important(high priority) product backlog items are well defined and are ready to be discussed in the sprint(development sprint) planning meetings. At BeautifulCode we try to accomplish the following in the product sprint.
- Get clarity on product backlog items. Ideally, there should be zero questions on the feature requirement in the development sprint planning meeting.
- Prepare interactive prototypes (ex: Invision prototypes in case of a web or mobile application) and get sign-off post user research.
- Identify dependencies (ex: an external data dependency) and notify external teams to reserve their bandwidth.
- Do a one pager documentation on the proposed architecture for medium (ex: development of a new microservice) to large sized user stories.
- Build a healthy backlog of prioritized and detailed user stories that need to get delivered in the next two quarters.
Development sprints – This is the “sprint” in the traditional sense of scrum. Thanks to product sprints, at the time of development sprint planning meeting the team is clear on the top backlog items and all dependencies such as high fidelity mocks and data dependencies would have already been addressed/defined. The goal of this sprint is to complete the development of the chosen user stories and be ready with a potentially shippable product. At BeautifulCode we do the following in a typical development sprint.
- Breakdown the user story into smaller subtasks and have them assigned to the developers during the sprint planning meeting.
- Development of the committed user stories, which includes implementation and test code.
- Code review of the new code written.
- Demo of the new features in a production environment for product sign off.
Some things to keep in mind to get the maximum value out of your sprint process.
- Sync twice a week: Practically speaking, even after vetting the product backlog items during the product sprints there will be a few open questions or data dependencies during the development sprint. It is recommended that you sync 2 times a week for 30 minutes or so to go over the outstanding blockers. You can also use this time to do backlog grooming.
- Manage time-zone difference: If you end up working with a team that is halfway around the world there are a couple of things you could do manage the time-zone difference.
- Be responsive to emails/slack messages: Prioritize responding to messages from your remote team. This way the remote engineers do not get blocked and lose a day
- Try to have at least 2 working hours overlap every day. This will help you address any blockers or high priority questions quickly.
- Proactive delivery: A 2 week sprint does not mean that the team comes up with shippable features by the end of 2 weeks. Taking a leaf from the Kanban approach, you can plan to implement some features and demo them as soon as they are completed. This will keep the team develop their “shippability confidence” gradually over the sprint instead of waiting till the very end.
- Retrospect the process: While the Scrum process is a good generic framework to execute on complex projects, every team can benefit from tweaking it for their particular context. The processes we set up should be serving us and not the other way around.
Communication is key.
One of the common fundamental reasons of project failures is failure to communicate. Understand how communication is happening in your technical teams and plan for the right amount. Following are some of the processes and tools that focus on getting communication right.
- Scrum standups – The daily standups within the remote team helps quickly check on the status of the sprint and calls for attention on any problem areas.
- Interactive user validated screens/mocks – Interactive mocks help envision the future very quickly and gets everyone on the same page quick. One pitfall we have observed with some product managers is that they skip the step of user validation of the mocks. Communication is not just about transferring information between you and your team. Involve the end user as well early on. You may start off slow but you will be walking in the right direction.
- Intra team communication tools – Tools such as Slack, Hipchat help teams broadcast updates in realtime for effective collaboration.
- Architecture documentation – The system architecture documentation helps the engineering team consider multiple options to solve the problem at hand and avoid rushed implementation. Iterating on the systems and UML diagrams helps build confidence between the architect, engineering lead and the developers.
Understand and play to the strengths of a remote team setup.
Remote teams have their unique strengths and playing to them will result in very effective operations.
- Autonomy – Enabling the remote team to be autonomous has multiple strengths.
- Once you get the communication aspect right, a clear agenda is set for the team and they will focus on getting to the finish line in their own way. This will also help you in disconnecting from them and focus on other priorities.
- The remote team realizes that they are in the driving seat and will proactively reach out to you for progress updates, demos or escalating issues. This gives the remote team ample opportunities to lead, which in itself is challenging and satisfying in addition to the technical work they accomplish.
- By forcing to be autonomous, you will be evaluating a long term relationship with the remote team. Ideally, you want partners not short-term contractors.
- Reduced non-productive activity – This has become a huge benefit for the modern workforce that value flexibility and work-life balance over everyday commutes and constant interruptions in a centralized workplace. We are seeing “digital nomads” who take this aspect to an extreme where they are constantly on the move and using their lifestyle to inspire themselves at being their best.
- Forced to get communication right – This point is worth repeating in the article. A weak communication setup will demotivate the remote team and lead to confused outcomes. The onus is on both the parties to communicate very effectively during the syncing sessions and set the right expectations. This is a classic example of a constraint turning into a strength.
Don’t forget the human touch!
Share both positive and negative feedback from the end users – Your team is just not an blackbox that spits out feature implementations. They are also emotionally invested in the success of the project and take pride in the outputs. A negative feedback will help the team empathize more with the end users and create better workflow and designs. On the other hand nothing motivates the team more than a customer that says “I love the feature. Thank you!”. Forward such emails to your remote team!
Meet the remote team in person – This is especially true if are about to start a big project. Meet at least once a quarter. You fly out or have them fly in. In person meetings goes a long way in building trust and motivating the team. This ensures a good start and sets up the relationship for success. Once the trust level goes up between the parties, they will graduate from “remote engineering team” to “co-creators”. When you co-create, the possibilities are endless.