lap top, headphones: remote work important tools

fully remote working: my work station for a whole week

In the first week of December I ran an experiment: our entire team was made to work remotely from the two main offices. The aim of the venture was for everyone to feel exactly what our remote employees feel every day. As a result, we hoped to improve team communication, both within the team and external to it.

Our team is probably one of the most distributed engineering teams in Metail. While most of our engineers are in the Cambridge office, a few work remotely. We’re lucky enough they are in the same time zone as the headquarters. Nonetheless we still suffer a lot of the pains that distributed teams feel, especially when the rest of the company is more used to working between the two offices, based in Cambridge and London.

Our hypothesis was that we would probably miss out on a lot of incidental “water cooler” conversations. We also guessed that communication with the rest of the organisation would be somewhat difficult.

Before Kick off

Before we rolled out the experiment, I had to lay some groundwork. Firstly I checked with our crew director (we work in teams called ‘Crews’ at Metail) and the other engineering managers that this wouldn’t impact anything crucial. We communicated widely across multiple channels that our team would be entirely remote during the week before the start date. I also spoke to the team to hear their concerns. It certainly helped to draw up a few guidelines. This is in summary what we came up with:

  • We use Slack by default and Skype as a backup
    • We say when we are at our keyboards and when we’re not
    • Everyone is to use headset and have their webcams turned on.
  • In general we try to ensure that we are over communicating
  • If there is a problem or someone can’t be reached, people are to come to me (the engineering manager) or our crew director.

There were a few practical things to take care of as well. We made sure our contact details were added to all the meeting rooms’ Skype accounts. We also checked we could all access internal resources via the VPN. Just to be sure, we ran a couple of trial calls to make sure Slack and Skype would work for us (they did!).

So how did it go?

We were able to anticipate the problems we hit; there wasn’t too much of the unexpected. It was much harder to run work past people on a casual, in person basis. Attempting to do so required both parties to mic up and jump on a Slack call.

Meetings with the wider company is where we struggled the most. We noticed people in Metail occasionally talk over one another and because of this it was hard to participate in guilds and other group meetings. Usually it meant one person in the office would drown out another who was further away from the room mic. We also noticed that if there were multiple people in the office participating in a meeting, remote workers often ended up ignored. In some cases it was difficult to observe body language that would normally be cues for a person to start talking. From time to time it was hard to hear people in the office. Sometimes this was because of problems with the audio equipment, other times it was because of background office noise.

We encountered a few minor technical issues as well. Some of these things were easy to fix, like tweaking rules on a firewall. Others were harder to diagnose, like why a developer was seeing Jenkins time out during load, preventing him from being able to see when builds were finishing. A couple of times we had issues with Slack where one person in the group couldn’t see another but these were easily fixed by leaving the call and re-entering it.

Generally speaking the engineers found it easier to focus on the work they were attempting to do. On the other hand it was pretty difficult for myself and our crew director, being the main communications interface between the team and the rest of the company.

I also discovered that my house gets really cold during the day if I don’t put my heating on! I made a special effort to be a little more social, going out to dinner and to the pub for much needed social interaction.


On the Monday following the experiment we ran a retrospective where we recorded our experiences. On the whole, the world didn’t end and the company kept working. We recognise that it was a pretty short experiment, lasting only a week, but we still found it valuable. One thing we noticed was that we certainly affected how the rest of the company interacted with us by communicating that it was coming up. I can now say I have a much better understanding of the pain our remote colleagues go through every day. I’m definetely going to be reminding people in the office about it in the future.


If you engage with remote employees or are planning to in the future, here is what I’d recommend:

  • When you are having a meeting with remote people and it’s possible for everyone attending to have mics, then do so.
  • Let remote employees know if you are starting a meeting late.
  • Respect meeting etiquette and allow all attendees to fully express themselves. Don’t interrupt until they’re done speaking.

AWS Meetup

On the 22nd October Metail sponsored and hosted the third Cambridge AWS User Group (who have a few photos of the event up). It was great to welcome the meetup organiser Jon Green, AWS tech evangelist Ian Massingham (the main speaker for the evening), and around 25 others to our office “town hall” for drinks, snacks (including honey roasted cashews), networking and of course the talks.

Ian had two spots on the schedule. The first was a round up of the announcements made last week in at AWS re:Invent. I’m not going to produce my own recap of Ian’s summary, A Cloud Guru gave a nice summary of the keynotes at re:Invent in their medium blog post and there’s a nice summary with follow on links over at trendmicro. There were a few questions from the audience last night all of which Ian answered to their satisfaction. Seems AWS is doing something right 🙂 My favourite bit of the talk was during the overview of AWS’ now beta IoT platform (apparently the first thing AWS themselves have referred to as a platform) and the consumer stories from re:Invent. Here the focus was largely around an application in farming, mentioning the possibility of fitting monitoring devices to animals and being able to buzz them to wake them up. As someone who grew up in the valleys of Wales surrounded by sheep I found the thought of experimentally setting the state of your flock to be awake quite amusing. The scale of farming in the US is slightly larger than what I’m used so that’s a lot more sheep to wake up through patchy signal coverage ;).

Ian’s second talk was a demo of the new EC2 container service. I’ve played with docker before but it’s not my area of expertise however the audience seemed suitably impressed and there was a good bit of discussion at the end.

Having bribed my way onto the agenda by getting Metail to host (and doing the literal leg work to get the drinks and snacks to the office) it was good to give a talk to an engaged audience. I opted to go into some depth on the tracking and batch processing steps of our data architecture and skimmed over the insights and how we actually drive the pipeline. I’m hoping to get invited back to go in to a bit more depth. Elastic MapReduce is a slightly more niche service in AWS, and perhaps being overtaken by the use of real time systems such as AWS’ kinesis family. The talk itself is up on slideshare and you can see me in action on the @CambridgeAWS twitter account 🙂

We are often complimented on the selection of beers which we put on at the meetups at Metail. This is in large part owing to the excellent choice found at the King’s Parade branch of Cambridge Wine Merchants; it makes a nice lunch time outing to go over and choose the selection for the evening’s meetup. Having said that, a little data insight from our event hosting is that diet coke is the most popular drink.

Photo cc Ian M.

We’re delighted to be hosting and sponsoring the 3rd Cambridge AWS User Group meetup tonight. Where we’re going to be getting a run down of this year’s AWS re:Invent and I’ll give an introduction to Metail’s data pipeline with a focus on how we’re using and configuring some of AWS’ services to power Metail’s data insights. As sponsors we’ll be providing beer, soft drinks and wine as well as some snacks (I’m a big fan of honey roasted cashews and in charge of purchasing, so feel free to comment on this post with any special requests).

It’s the first of these events we’re hosting here at Metail and I’ve used it as an excuse to write a presentation for the group. Although the meetup is moving around various hosts and sponsors in Cambridge you can expect to see it back at Metail in future, and hopefully a follow up/continuation of my talk in a future meetup.

Here’s the summary of the event from the user group page:

Docker, containers and the like. Plus, those of us who made it back from Vegas alive report on our findings.

The BIG news…if you’re in the Internet of Things business, a database or data analytics specialist, are into Docker containers, or use Kinesis or Lambda, there were some major announcements – and you will definitely want to be here to hear them!

This meeting is hosted, and snacks and drinks sponsored, by Metail.

We’ve got a lot to get through, so the meeting will start at 7pm sharp, with doors open from 6:30 – please be prompt!


The presentations:

Notices and news – Jon Green (Adeptium Consulting) and Brief Intro to Metail – Gareth Rogers (Metail)

• re:Invent 2015 Debrief – Ian Massingham (AWS) (and/or Jon Green)  – all the gory details and new announcements!

•  Metail’s Data Pipeline and AWS – Gareth Rogers

Docker and Amazon Container Service  – Ian Massingham

• [Possibly] From Zero to Hero in AWS – follow-up – Tom Clark

Hope to see you later! We also host the Cambridge R Users Group, Data Insights Cambridge, DevOps Cambridge and Cambridge NonDysFunctional Programmers so if you can’t make it, there are plenty of other opportunities to come along to Metail for some drinks, snacks and tech chat.