Running a distributed team has clear advantages over "plain" remote, but does not suit all cases and requires thorough formalization to get right.
The text below is a digest of my close to a decade long experience of running a Russian-speaking distributed software development team in eastern Europe for english speaking clients & stake-holders. although the text uses broad terms, please apply common sense when trying out with other fields.
Startups typically exist inside of a single information silo
This usually means that everyone gets to share with everyone freely & intuitively, because they are all share the same physical space (an open space, for example). As a startup grows into a larger operation with more involved actors, it becomes divided into compartmentalized organizational units. Because TMI becomes an issue & managerial structuring takes place.
Further down the road, an organization sets up offices in new locations
For the purpose of sales, access to talent, and, of course, cost optmization. That's the typical approach, but is a coarse one.
But what if we could hire anywhere, for (almost) any role?
We'd still have constraints such as timezone and language, but we'd become be extremely flexible in our ability to hire.
A world of possibilities opens:
- Major cities have higher salaries. hiring people who won't leave their 2nd tier towns is cheaper.
- If enough of the work process is managed (at least verbally) in the native tongue of a given region's remote employees, the requirement of "good spoken english" is removed. and that makes it possible to hire competent talent that otherwise couldn't have been tapped.
There are some gotchas!
Going distributed is possible, but with some reservations. here are the show stoppers that i've mapped out.
Information sharing needs to be explicit,
Effort must be put into making sure everyone is up to date. What's an intuitive process when sharing a physical location becomes a desirable goal that requires conscious effort. The name of the game is sharing context in an engaging way but one that doesn't become the goal, but stays as a means. To get there, the usual toolset is at your disposal:
- Daily group calls (standups)
- Topic/goal focused calls
- Collaborative docs, boards and so on.
Communication with the clients/stakeholders
Stating the obvious, your Product Manager has to understand the client's needs precisely. Therefore, it is best if they are as close as possible to the client in terms of mentality, location, understanding of the problem, and of course - vision. However, the day-to-day communication can be managed by Project Manager(s) who can be anywhere between local & remote. It's imperative they undertsand the problem definition and expected output. Sometimes, a strong-willed QA can fulfill this role succesfully.
Information security requirements
Having a project's intellectual property uncontrollably shared in environments that are not controlled and/or monitored is fine for open source development. That may not be the case for proprietary software development, and depending on your industry and specific needs, this could be a deal-breaker. Here are some ways to approach this challenge:
- Compartmentalize code access to reduce chance of catastrophic knowledge leaks
- Limit access to copies of production database, production database itself. developers that need a full db (for scalability/performance requirements) can be handed an obfuscated snapshot.
- If the security of a remote employee's local environment cannot be trusted, access to the work environment can be mandated to be performed via ssh jumphosts and/or rdp/vnc gateways. This is what banks do when working with external software/service providers or when on-premises systems needs to be setup by 3rd parties who are not bank employees. This way no work ends up on an uncontrolled machine, and the most that can be captured by an adversay is keylogging information + screenshots (or a screencast) of work sessions. Such solutions result in a less comfortable work environment for employees and extra overhead.
The usual constraints that apply to remote work are also there:
- Do not hand out open-ended assignments to remote workers with whom you're not intimately familiar. this will likely result in disappointment.
Research-oriented tasks are less suited for remote workers. the best are units of work where input and output are clearly defined and are routinely verifiable by other cheap labor - QA.
- Everything that's here also applies.