Dec 15, 2016

Collocate vs. Live-Stream: are we going back to basics?

(part II)

Author: Mihai Mlesnita

In my previous article, we’ve made an introduction into the issues brought on by long-distance team collaboration in the tech industry, and we’ve started discussing why it often doesn’t go as planned. Today, we look at what does work, as well as elaborate on the top problems developers experience with long-distance professional relationships.

When communication means colocation

Many types of meetings will not suffer in the slightest when people are sitting on either sides of internet-connected computers. We can discuss our progress, send in new features for approval, receive feedback, tweak contract details, exchange get-to-know-you presentations or look through professionals’ CVs in search for the best-suited candidate. Ironically, many of the things we actually take the time to arrange a formal meeting for could’ve well been discussed over a conference call just as well. It’s actually working together that has to suffer considerably from long-distance arrangements.

If my team and I handle one feature, and your team handles another – but we work on opposite sides of the planet – then it becomes complicated. The final product might lack cohesion, and time is bound to be lost coordinating things that would come naturally in an open-space collocation scenario.

Colocation: the buzzword is here to stay

Colocation has good reasons to be back into the software outsourcing picture.

Choosing to adhere to the colocation trend doesn’t mean sending people to work on-location from the client’s headquarters – oftentimes, it just means keeping people who work on the same project in one place, from team-lead to developers and testers.

Looking at some of the most common complaints developers and managers have regarding remote work, I can’t help but feel that this approach isn’t justified, especially for long-term and/or more complex projects. So here are the top 5 complaints regarding remote collaborations, as reflected by more than a decade of my experience with tech-people, tech-teams, and the various ways of bringing them together:

1. Approval times are higher with long-distance teamwork. That’s disruptive and creates a frustrating feeling of being restricted. Especially when said approval is preventing you from moving forward with your work, and you end-up staring at an email client, pressing Send/Receive way more often than you need to.

2. There’s lots of obscurity regarding decisions when teammates are scattered across the globe. Why would one even bother to come up with something new or a better way of doing things, when they don’t understand why they’re doing what they’re doing in the first place? Being made responsible for things makes employees feel responsible, increasing their involvement. On the other side of the spectrum, nobody likes feeling like a remote-controlled robot someone just throws tasks at, without ever bothering to outline the plan or to help employees understand how their work fits into the entire team effort.

3. Motivation decreases when there is no common goal and no feeling of communion, of ‘belonging to the team’. Teambuildings might not seem like ‘a big thing’, but simply having everyone in the same space, eating and socializing freely without a looming deadline, really goes a long way in terms of driving commitment. If I approach this project minimum-resistance-like, what incentive do I have to care about how that makes my team look? – there is no ‘my team’, for all I know them, we’re just a bunch of people being handed out tasks that will eventually be part of the same product/service.

4. It’s difficult to pass the blame around from person to person, when everyone’s in the same room – but surprisingly easy to do so remotely. I’m not even saying that people are trying to purposefully blame one another instead of taking responsibility. It just happens. A sort of magic, like that of the self-filling water tank in the company kitchen. Before you know it, the blame-game gets crazy out of hand, and nothing good ever comes out of winning the blame-game.

5. In my experience, roughly 9 out of 10 developers list lack of response to inquiries as primary source of frustration and delays. This brings about a variety of more or less costly symptoms and side-effects. Back to the image of you incessantly clicking Send/Receive in hopes of finally getting that response that will allow you to continue actually working.

What we could be taking away from this

Consider this: with dedicated teams or other outsourcing models, it’s most efficient if you go all in, or stay in-house.

Of course, there are bound to be exceptions to any guideline, but in most cases it helps to outsource an entire project in one place, or have one of the teams travel often – not for meetings, but for actually working alongside one another. It will save a lot of time in the longer term, and definitely save everyone involved from the bottomless pit of overcrowded, focus-lacking long-distance calls.

Now tell me about your experience

Don’t let me take charge of this conversation completely: tell me about your experiences with remote collaboration as well. Did it turn out all right, with none of the problems I mentioned, or did you encounter additional ones that didn’t make my top 5?

Leave a note

This site uses Akismet to reduce spam. Learn how your comment data is processed.