Tag: Collaboration

Mirror, signal, manoeuvre: what I’ve learned from working in a remote team

I’ve spent the last 9 months working in a team with people from as near and as far as Darlington, Portishead, Nottingham, Sheffield, Bordeaux and Bangalore.

In the last few months, we’ve added 4 new people from Porto, adding some more non-native English speakers to the party.

Standup meetings and Slack have become good fun as we’ve got to know each other, but some of the pitfalls I expected from remote working have surprised me.

The remote working ideal swaps a long commute for improved productivity and more time to see your family (and do household chores). That has certainly been the case for me. But much like starting in any new team I’ve found myself putting in extra effort to fill in the gap that an ‘in real life’ presence – with all of its nuance and non-verbal cues – leaves behind.

Where I’m working, the approach to making software is vaguely agile, so there’s no shortage of team communication. Nevertheless when a remote team is learning to work with each other, there’s no opportunity to just get everyone in a room and “whiteboard it out”.

Regular voice and video calls provide a useful yet limited simulacrum of a team workshop environment. But there’s nothing like putting your own post-it note just in the right place on the wall yourself, then stepping back to see it in context.

RealTimeBoard (now mysteriously rebranded as Miro) has worked as a decent replacement for visualising ideas and doing team reviews, but I’d rather have a research wall in the office everyone could see on their way to and from their desks. I think the real life version embeds deeper in the sub-conscious where all the best ideas come from.

Tackling larger challenges together is more or less impossible. I’ve found I’ve had to hand off work more frequently than when working in one office, rather than working through it together. Handoffs are also more brutal because the shared space to share, and discuss, and bounce off ideas is not as rich, and the feedback less flowing than when I’ve worked in the same room as the rest of the team.

I’ve put a lot more effort into typing things up after conversations have been had, explaining the rationale behind the work and making things readable and easy to understand. In short, I’ve produced quite a bit more ‘short term’ documentation, just to communicate direction, rationale and status, and ensure people are informed and consulted as we move through design and development.

I’ve also been doing my best to stop myself from starting on new pieces of work or tackling things in new ways until I’ve made sure at least some of the team knows what I’m doing. I’m a self-motivated sort so this has been the hardest – to make sure you’re bringing the team with you (and with their blessing) when you feel the need to act immediately.

None of that is in itself bad. It’s a trade off for what for me is a 2 x 2-hour commute every day. And I think the extra work is helping the ‘lay people’ the team is dealing with – people who have limited previous experience building software  – understand the effort and thinking that goes into making a quality product.

An old client had a modus operandi for working in a bigger company. He said: “Always remember: mirror, signal,  then manoeuvre”. That way people understand your intentions rather than striking out (in vain) on your own.

I think that’s also a good motto for trying to build a remote team.