3 Things I Learned Working with Remote Engineers

Like most Product Managers who work for a startup, I have to work with extremely limited resources. One of the biggest expenses for my company was in engineering, which lead us to the decision between hiring a remote team or in-house talent. After deliberating the pros and cons we decided to go with the remote team due to cost and commitment. However, managing a team which I had never seen or personally met except over email or telephone created issues with collaboration; logistics, and overall difficult maintaining product scope.

However, through the trials and tribulations there were three main things which helped me overcome the challenges working with a remote engineering team.


This cannot be overstated communication, communication, communication. I learnt my lesson in communication when at first I handed over the technical requirements and specifications to the remote team and expected the product to match the company’s expectations. After the first iteration of the product and an upset CEO, I decide to implement the scrum system which provided a transparent view of work done, and emphasized communication from the team. I discovered that having all participants follow a framework is important to ensure consistency. By implementing a trello board to follow movement in task along the product roadmap, creating clear user stories and having virtual stand up meetings we were able to get product on track and by the second iteration it was more aligned to expectations.


This is always overlooked in the product development process. As a PM, we just want to get this thing built and launched, I can do documentation later. That may work when you have engineers sitting across the corridor and you can physically get what you need from them later in the process, however with a remote team I discovered how valuable proper documentation was in pre-empting many issues. Like others I had the tendency to assume documentation was a waste of time and greatly devalued the importance of clarifying important issues and goals. But proper documentation created trust, stability and prevented team members from acting ignorant when it came to the deliverables. It provided a sense of accountability, and it gave the team something to cross check.

Making communication as visible as possible

Even with clear constant, consistent communication and proper documentation some tasks were still getting lost in translation. I realized after some time that by making our documents more visual we got a better response from the remote team. Not only did the visuals help to relate information which was a bit difficult to put into words, but it made the content easier to understand to a team which had a different cultural background. Depending on what we were trying to convey, different visuals are appropriate. Mockups, wireframes or infographics were helpful in illustrating instructions, while tables were the best medium when conveying relationships between two sets of information. It lessened confusion and made communication documents less wordy.

Now these actions did not eliminate all of my issues, I still had to deal with time zone alignment, cultural differences, velocity of delivery, etc. What these actions did however, was allow for a much more fluid and transparent process which immensely improved product development. If I had to this over I would have first established open communication lines followed with clear and distinctive documentation which included visuals to properly outline product expectations, scope and specifications.

@garethburrowes is the Product Manager at the Tech Connection. The Tech Connection is a recruitment platform that supports the professional development of untapped technical talent. We offer individualized career planning and job placement to candidates. We believe that introspective leadership coupled with proper planning is the key to career success. We strive to deliver the best talent to high performing and innovative teams.