Andy Crouch - Code, Technology & Obfuscation ...

Remote Working For Employers

Man Looking At Whiteboard

Photo: Unsplash

In my post last week, I covered my experience of working as a remote employee for over 10 years. This week I want to share my experience of building a fully remote team at Open Energy Market. I will share what I have found works, what does not work and things to look out for.

It is always exciting when you grow a company to the point where you can hire more employees. As an organisation, you can choose to limit your search to a radius of your office. You can choose to pay an expected salary band for within that radius. You can finally choose the recruiters that you will work with based on your location. All in all a fairly limited set of choices. Instead, you could opt to increase your radius to the whole of the UK. You could go wild and go global!


Well, the odds of you finding the perfect employee for your role within a limited radius of your office is slim. This is especially true of creative employees such as developers and designers. The very success of your company and product is reliant on the fantastic team that build it. If you’re based in a town dense with technical employees such as Silicon Valley, great! If not then look for what an employee can bring to your company and not where they live.

This leads me to hire for team fit. We have all worked with people who are at the very best of their game but who are a pain to work with. The developer who can write elegant code but is not able to work with others due to attitude. An excellent tester who’s approach to reporting issues borders on mimicry. When you get to build a team you should be looking for a good cultural and team fit. The employees should be fully invested in the company idea and the product. They should want to work for you no matter what instead of it being a local role. If you have a team then having the ability to hire like-minded people with a diverse skill set will be beneficial. If this is the first hire then hire someone with the skills you need that you would want to work with. Setting the team culture is much easier at the start.

The last reason you should consider a remote employee or team is cost. This point is very startup-specific. I am not going to shy from the fact that I can hire better people within the budget I have with remote roles. In hiring the first developer at Open Energy Market we found a developer through Hacker News. He had specific experience of early stage startups. He had recently been through Y Combinator with his previous startup. He was a very experienced developer that I hired on his requested salary. For me, I gained a senior developer for a mid-level developers salary. We benefited from looking beyond a 10-mile radius of our office.

So we have addressed the why now the how. I generally always advertise roles on Hacker News Who Is Hiring posts. Created on the first of each month, these posts allow anyone to advertise their roles. The posts are visible to millions of readers. I have had great success hiring from Hacker News. I have also met and interviewed some amazing people from around the world. In support, I generally advertise on one of the generic remote working job boards. We Work Remotely and Remote OK have had mixed results as have adverts on generic IT job sites. I have not yet used some of the newer developer community job boards such as StackOverflow or DZone jobs.

Interviewing should be a multipart process. I tend to hold a brief 30-minute call with all reasonable looking candidates that we shortlist. This is very useful for working out who wants the job because it is remote or because they see the challenge. Then I and my senior developer conduct a face to face interview. During that interview, we are looking for technical ability, team fit and skill fit. We get the candidates to either live code a generic problem or present and explain some of their own code. Almost all of these interviews are performed using Hangouts. If the candidate is going to join us in a remote capacity then let’s see how they go on video.

This brings us to having actual remote employees. If the above steps have worked you should end up with someone that slots straight in. The important part now is the tools you provide the team to communicate and collaborate. Team communication is vital. I have used a lot of whats been on the market over the last 10 years or so. I actually delay selecting the communications tool as long as possible so it can be agreed on by the team. At Open Energy Market, we use Slack. Slack seems to have a love it or hate it standing in the world but for us, it does what we need with no friction. We have integrations to email, Bitbucket, Jira and Confluence. This means that as we’re working the team is aware of what is happening as it happens. We have even integrated Slack into our own application to notify the team of everything. From new user signups to traded contracts, the team get notified via Slack. Finally, all meetings are conducted in Hangouts. It’s not the best tool but we’re used to it and it just works.

Bitbucket, Jira and Confluence are services hosted by Atlassian. They cover the core items needed to run a development team in my view. Bitbucket provides Git source control. It makes it easy to integrate with third-party applications allowing us to use it to automate our deployments. It also makes it very simple to set up rules and workflows for Code Reviews. Jira is a work item tracking application with a number of workflow methodology built in. We have used the Kanban workflow for the last few years to great success. Confluence we use to document everything from meeting notes to release logs. Both Jira and Confluence are very configurable.

This brings us to the final piece relating to remote employees, people! Once you have a remote team you need to ensure that you do not micromanage it while ensuring you stay connected. I make a point of not arranging needless meetings but it is good to get the team together once a week. I have found replacing the standard Scrum standup with a virtual stand up using Slack works well for us. This means we have a team meeting in a Monday, first thing and then each of us updates the team each day before 9:30 via Slack. The only other meeting that is mandatory for the team is a company-wide meeting on a Monday lunchtime. Done via Hangouts, each team, in turn, updates the rest of the company on what it has been doing. The final recommendation I have is to have 3 monthly reviews with each of your team. Take the time to chew over the last 3 months and see whats working and what is not. Set targets and write it down so you work to it.

My final advice is for when things look like they are not working out. Signs to look out for are lack of communication, inadvisability and a decrease in delivered work. Once this starts to happen long enough for you to notice, deal with it. Everyone has off days or days where they are so zoned into their task that they don’t communicate. Your role in running a remote team is to know your team so you know when this is the case.

If you’d like to discuss any of my thoughts here then as always please contact me via twitter or email.