There is an extreme shortage of talent in the traditional pockets of entrepreneurship in the United States and Europe. The offshore strategy is as much about tapping into talent that exists all over the country and the world as it is about managing the costs. Instead of thinking of teams in a hub-and-spoke way as onshore/offshore entities, it is far more useful to think of them as nodes in a geographically distributed peer-to-peer (P2P) network where each node in the network is optimized for the value it can provide. This P2P model has existed for decades in the world of open source development. It is already modeled in the modern development methodologies such as agile development and tools such as Git.
Here I’ll present eight key lessons I have learned in my time building and organizing geographically distributed development teams across several organizations.
1. Treat each team as a peer
First off, get rid of the words like “offshore” and “outsourced” as they do nothing but make some teams feel like outsiders and subject them to the tyranny of low expectations. What you have is a network of peer teams that are geographically distributed.
2. Trust and measure
The foundation of every company’s culture is trust. You have to make a special effort to make this a reality if many members of your organization are remote. You have to trust your developer’s estimates, their code and overall commitment. And then you must measure what you trusted. There are a few key measures that every software development organization must obsess over on a regular basis. Some key ones are each team’s velocity over time, development estimates vs. reality, burndown charts, unit test code coverage, bugs found by QA and so on. These metrics apply to all teams regardless of where they are and should be monitored on a regular basis.
3. Hire for your company and not for offshore development
Every candidate regardless of the location of the peer team must go through the same rigorous interview process. In practice, this almost never happens. Most companies relax their interview process, especially when it comes to hiring remote contractors and they pay for it later. Remember — you are not hiring a contractor or an offshore development resource; you are hiring a peer in a P2P network of teams. Every node is of equal importance.
4. Try to make each team as self-sufficient as possible
One of the key principles of a scrum team is that it should be self-sufficient. That generally means a product manager (PM), at least one QA and a few developers per team. Product design could be a shared resource depending on how much work is there for a particular product area. A common preference that many companies have is to keep the PMs in the HQ or where their primary market is. This is an important consideration. However, in the agile world, a PM is responsible for not just gathering the requirements from customers but also writing stories and acceptance criteria, doing acceptance testing, and being available to developers and QA for any questions. A PM in a remote peer team could coordinate with their counterparts who are gathering requirements from the customers. They can then provide the rest of the services to the local development and QA teams.
5. Establish program management as the referee
An essential ingredient for making this P2P network of distributed teams work is a referee (i.e., the program management office). In the beginning, it could just be one program manager who is independent of engineering and product and reports to the COO directly. The program manager’s responsibilities include making sure the release is going smoothly, checking to see if everyone is aligned on the objectives and dates, and raising any red flags quickly. Program managers should also report on burndowns, estimated dates and velocities in the weekly executive leadership team meetings.
6. Establish a virtual architecture team as soon as possible
You need a team of architects who meet regularly (at least once a week) to discuss major design issues. My personal preference has always been to have the architects be virtual (i.e., they are key developers in their respective teams). The architecture team makes sure that the core design and architecture of the company’s products is evolving in a consistent fashion. I have found architecture teams to be a very effective means of driving architecture alignment across all teams. Have it be open where anyone from any team can propose a topic and present it to the group, but keep the core group small so that the decisions can be made quickly. Lastly, have a chief architect in place (or CTO) who can break the ties and make key decisions if necessary.
7. Emphasize quality in theory and in practice
Establish processes for code reviews, as well as unit, functional, security and regression testing. Strive for full test automation in a CI/CD pipeline. Do this for all teams.
8. Celebrate wins and have all-hands meetings at a time that works for everyone
Remote teams in the network must feel like they are part of the same company. It’s hard to achieve this but try your best. If you show the intent and put serious effort behind it, people will take notice. Have an all-hands meeting regularly (once every two weeks works great) where you share the latest from the business, welcome the new hires and celebrate people and wins. Always make sure to give an update on the business in these meetings, and don’t hesitate to celebrate wins no matter how small. At a certain scale, you may want to run employee engagement surveys across all teams and measure them over time to make sure you are making progress.
My current company, Vineti, is operationalizing these learnings and is off to a great start with P2P teams in San Francisco, Armenia and India. Make sure you keep these eight lessons in mind as you begin to organize your distributed software development teams.