A collection of insights made during several years of building, managing & scaling a distributed development process
Let’s say you’re lucky enough to know of, or actually have a working profitable business model. By changing it radically you risk breaking it completely. Too much entropy, too many assumptions. Risk grows exponentially. Unless you are especially farsighted, risk is best taken in measured doses. Having the option to be careful like that allows to quickly understand where things went wrong and correct or backtrack on your changes.
Increased communication overhead and latency contribute to longer execution times for “one off” tasks.
Thus, quickly mutating and communication intensive tasks such as feedback-intensive research, PoC, rapid prototyping are all best done close to your stakeholders.
Having stated the cons in the last paragraph. The advantages of hiring remotely are reduced costs and higher specialist availability.
Therefore, it is best to hire remote once you know precisely where you’re going and how you’re going to get there. Once you do, it is possible to break down your roadmap to individual tasks and spec them out in detail.
Office space is not required with remote employees. Without commitment, hiring and termination are frictionless.
With that said, you may easily lose ⅔ of your remote new hires to various reasons, such as cultural incompatibility, candidate unsuitability for remote work, lack of motivation, time zone differences, even outright fraud. Only some of these can be detected up front at interviews. The highest cost of bad remotes hires are efforts wasted while onboarding and project delays.
Therefore, if your operation has a well-oiled onboarding mechanism and your funds are more abundant than time, always hire more than you actually need for your particular task.
Here’s why. Often, when you look for an existing solution, you’re tempted to plug it with a self-made tool, if the established tools seem complex and an overkill. That’s where you go into debt. Instead of adopting an existing solution, you take the short way and come up with something simple and quick.
Over time, as your needs grow, your self-made tool evolves. Unless it becomes widely adopted, the burden of maintaining, fixing and enhancing it to satisfy your project’s increasing needs lie upon you.
It is impossible to hire specialists on the market who know your tool. Anyone you do hire will have to learn it.
Additionally, the incentive of an employee working with such tools to stay on the job are small, since he understands that the gained skill set could not be applied elsewhere. Therefore, it’s a career dead-end, in which unambitious employees tend to stay.
This one isn’t specific to remote. More has been written up on this elsewhere, but here goes:
Developers are single-threaded creatures. They do best when they are allowed to work on a single task, without interruption, continuously. It takes them a while to concentrate, but once they’re “in the zone” - they work efficiently.
When conditions arise that require the shifting of a developer’s focus between multiple tasks, his effectiveness diminishes by the force of the context switching overhead incurred after each interruption.
The ability to plan and execute requires an understanding of the resources at hand (budget) and a good understanding of the desired end result, including the required flexibility and degree of possible deviations and mid-way changes.
Significant budget fluctuations that force valued team members cut-downs have a long-term damaging effect. Long term knowledge & experience accumulated are gone. Remaining team members are demotivated by being woken to an understanding of the fragility of their employment. They begin looking elsewhere, with the more competent gone once they find an alternative.
Over time, workers become demotivated. The causes for this could be lack of professional growth, unmatched expectations, mundane routine, burn out, toxic colleagues. Your options are to either shape employee conditions to facilitate their growth and accommodate their expectations or to factor in their regular replacement.
Communication patterns within a team are complex. A given unit of work is formed through communication between stakeholders and a PM, to be evaluated by a technical authority, broken up into multiple assignments for several developers, and once ready, end up with QA, and eventually DevOps. And that is only the shortest possible path in a fairly standard development pipeline.
Complexity in communication is often unnoticed and is not explicit. Humans intuitively “know” how (and when) to talk to each other, for the most part, when they’re in a tight collective. That being a room, or an office floor.
Once the organization is larger, or is distributed, things tend get out of hand, unless the communication is formalized. By formalization, I do not mean e-mail, but rather a commonly shared, explicit (and enforced!) knowledge of what are the steps to be taken by each participant in order to accomplish a greater goal.
© 2021 Web GMA R&D Ltd.