[SOLVED] Struggling to find developers

Sebastian Probst Eide
Aircloak Blog
Published in
6 min readSep 24, 2017

Over the weekend I met with founders from 40 tech companies in various stages of development from early seed stage to having millions in monthly turn-over. A common theme was the difficulty in finding and hiring developers. This problem seems to be particularly pressing for startups in hotspots like Berlin, Vienna, London, and San Francisco.

At Aircloak we do not have this problem. It is not because we are exceptionally more exciting than other companies or pay significantly more. Neither is true. The difference is that we are tapping into a pool of talent than most other companies are unwilling to consider. This was a conscious choice on our part, and it is one you can make too!

Many developers want to work remotely and have no interest in relocating or being in an office. There can be any number of reasons for this. Some developers are midway through their careers and sick of wasting hours commuting every day. Others want to escape an office culture where interruptions by colleagues are frequent and often encouraged. Yet others again have families and friends they have no desire to relocate or abandon. By insisting on wanting your staff on-site, this vast pool of talent becomes inaccessible to you. Instead you end up fighting for the same, small, pool of talents as everyone else — the result of which is that you might have to settle for mediocre developers at inflated salaries and have them poached by your competitors.

The idea of creating a remote working environment is frequently met with objections, and does come with a different set of challenges. Some common objections and challenges and the ways we address them are listed below:

Common objections and our solutions to them

I want my developers to be in the office, how else can I know if they do any work? And similarly: How do I know if they work long enough?

Whether a developer works many or few hours is completely irrelevant. What matters is whether the work they do is good. If it is not they are probably not a good fit for your team, and the way you select candidates might need adjusting.

Furthermore: like any other human being remote developers have good and bad days. I would much rather my employees and co-workers take an extended break or an early evening if they are low on energy or otherwise feel unproductive than spend time unproductively in front of their desk.

The reason this does not end up in a situation where little to no work gets done is that people seem to have an intrinsic wish to contribute and do meaningful work if they are allowed to. Therefore: instead of counting hours or micromanaging, we give our developers larger tasks that they can work on independently and on a schedule that suits them personally.

This does require you to trust your employees, but those worthy of your trust are the only kind you should want in the first place.

I cannot focus when working from home and therefore cannot imagine that my developers would be able to either

Not everyone is made for working remotely. If you find it difficult to concentrate when working outside the office then it might very well be that you should stick to the office instead. That is fine. Other people are the exact opposite and work much better when allowed to choose their own location of work — be it their home, a café or any other place of their choosing. By explicitly looking for developers who want to work remotely these are the kinds of people you will find, and because most companies are not catering to them, you are likely to find them in abundance!

How will we be able to communicate efficiently when we are not co-located?

Being in an office inadvertently results in people having meetings. Be it stand-ups, general briefings, retrospectives, planning meetings, etc. This can feel like an efficient way of conveying information. Sometimes it is, but more often than not meetings attended by more than two people are either a waste of time altogether, or at best an inefficient use of the individual participants time.

As a ground rule we avoid meetings if at all possible at Aircloak. Information that needs to be broadcast is emailed, or in the cases where a face-to-face meeting is beneficial to clarify things that take too long to put in writing, we have one-to-one or three-way video calls. Most of the time information is exchanged and discussed in an asynchronous manner, either over email, github issues, or slack. This gives developers the chance to consume information and chime in when they have time, and otherwise be productive and stay in the zone.

An added benefit of having most conversation in writing is that past discussion and decision making processes are documented and can be found when needed. This is indispensable when on-boarding new members to a team.

How do I avoid the remote employees becoming second class citizens?

We were very conscious of this possibility when deciding to hire our first remote developers at Aircloak. To ensure the remote employees stay in the loop and are equal parts in the decision making processes that take place, we decided to make the whole company remote. This means that even when parts of the team are co-located we use the same set of tools and processes as when we are not. This might sound restrictive, but has turned out to be both efficient and liberating instead.

How can we build a cohesive company culture when we can’t play foosball or go for a beer after work?

It is harder to get to know your co-workers personally when you don’t see them in person. We feel we have solved this adequately in the following ways:

  • The money we save by not having to rent a fancy office or provide other perks often associated with startup life (like catered lunches) is spent on bi-yearly weeklong retreats instead. During these retreats we rent a house in a nice location and spend the time being together, discussing interesting topics and catching up on what is going on in everyones lives. These retreats also serve as excellent changes to hold the few meetings that actually do benefit from everyone being in the same room.
  • We have developed a slack bot called the “socializer”. It pairs us up two and two once a day and encourages people to take 5 minutes to talk about something that is not at all related to work. This replaces the random water cooler chats one might otherwise have in an office environment.
  • We have developed a tool called kle.io. It takes a snapshot of our faces using our web cameras once per minute and shows it on a page. This gives provides the illusion of sitting together around a table, and helps build a sense of camaraderie. It also allows you to notice when someone has gotten a haircut, or when it is snowing on the other side of the world. This might not be everyone’s cup of tea as it can easily be perceived as intrusive. It needs to be paired with an environment of trust where it is clear it is not used as a means of surveillance in order to ensure everyone is sitting in front of their desk.

Conclusion

Remote work might not be the right option for every company – especially not in companies where the management believes it to be an inferior way of working.

However if you have a hard time finding, hiring, and retaining developers you should consider giving it a try. If you do, you need to be aware of the potential pitfalls and adjust accordingly. In summary, we have found the following to be the most important:

  • Don’t insist on constant meetings
  • Allow people to work when productive and to manage their own schedules
  • Make good use of asynchronous communication to give everyone a chance to chime in where needed

Good luck!

--

--

Sebastian Probst Eide
Aircloak Blog

Technical co-founder of Aircloak, University of Cambridge graduate, and generally a connoisseur of life.