To be remote or not to be remote …
Earlier this week I read an article on linkedin, deliberately
anti-remote, and a bit later on another one very pro-remote on
freecodecamp. I’m tempted to think one is the response to the other. But
The fact is that switching to a remote organization is a tricky move. It feels
like the move from monolith to micro-services, honestly. People that make
decisions about it rarely envision the extent of the change. And those change
look similar in nature. Team architecture and software design are not that
foreign. More autonomy for services or people, self-contained activity,
requirement for clear communication channels and protocols, extensive
architecture for monitoring, reporting or just plain visibility, more
debugging tools and processes, and much more.
The same way one will have to think about all those when switching to
microservices, the one that thinks about making his team remote will also have
to consider the exact same parameters. But that is all on the principles.
About the implementation, remote teams really need a strong chat culture, an
easy and transparent logging policy for all communication channels, various
tooling similar to chatops tools for assisting communication activity. Remote
organization also need to have all their processes online, and not need much
(if at all) any synchronous meetings.
From my perspective there are various very beneficial side-effects to make a
team remote. There is more traceability as everything is online and not in
corridors anymore. In some cases that I experienced, it also leads to a less
arbitrary perception on team members, because they can be judged more on
results (if you have measure tools prepared accordingly) than on attitude and
mouth-skills (did you noticed that irl meetings are sometimes just a
mouth-o-cracy?). But it’s accurate to say that on a short term, it is more
time consuming. The real benefit rises on the long run.
What I didn’t find in any articles on the matter, is the life-cycle dimension.
A software project has a life expectancy, from a business point of view. It’s
the same game as with the technical debt. It is acceptable business-wise to
live at credit for a time, until a certain milestone. A lot of projects are
just extended MVPs intended to convince big money that they could deserve some
attention. For such project, you want very fast paced environment. It’s easier
to coerce your
slaves employees to go above and beyond the
expectations, when in a physical environment. This is a disposable context,
and you can skip team debt as much as technical debt. And you really need
physicality for that purpose.
So, I would say, if a company is not making the move towards remote
organization, maybe there are very good reasons for that. But I will be very
cautious to understand what are the real reasons. They may stink. And if they
are remote, but they just came to it recently, I would be careful about the
tooling they prepared for it.