Older posts...
Older posts...
1 Sep
Donjon, sharing passwords securely
1 Sep 2014
Donjon, sharing passwords securely
20 Sep
RESTful -and- fast: Representational State Notification
20 Sep 2014
RESTful -and- fast: Representational State Notification
23 Sep
Designing APIs in a resource-oriented architecture
23 Sep 2014
Designing APIs in a resource-oriented architecture
28 Sep
How I'm going to land my dream job
28 Sep 2014
How I'm going to land my dream job
1 Oct
Neural net training fail
1 Oct 2014
Neural net training fail
13 Oct
Pow + SSL without the hassle
13 Oct 2014
Pow + SSL without the hassle
17 Oct
Using machine learning to rank search results (part 1)
17 Oct 2014
Using machine learning to rank search results (part 1)
23 Oct
Using machine learning to rank search results (part 2)
23 Oct 2014
Using machine learning to rank search results (part 2)
9 Nov
Managing complexity in Go
9 Nov 2014
Managing complexity in Go
25 Nov
Remote work: an engineering leader's perspective
25 Nov 2014
Remote work: an engineering leader's perspective

Remote work: an engineering leader's perspective

A lot has been written on remote work in the software industry, most notably Jason Fried’s Remote. But many of us were left agape by the recent backlash on telecommuting by three megacompanies: Yahoo, then Reddit, the final straw being Google’s reactionary attitude on the matter.
I thought I’d share my experience as a tech lead to help spread the word: in spite of lingering 20th century management, the knowledge industry can go remote, and benefit from it.

Mine is a real-world story about successfully turning a 10-person on-site team into a 30-person distributed team. This article is a handful of factual observations, measurements, and tips from my time as HouseTrip’s head geek.


Abstract

Even proponents of remote work seem to think that you should either have a distributed team from the get go, or stick to a traditional on-site team. Our experience shows that this is incorrect.

In this article, we present evidence that a going for a distributed team:

  • can make hiring senior talent easier;
  • does not require more than 10-20% on-site time;
  • results in lower overall personnel costs, asymptotically 20% lower in our case;
  • does not detrimentally affect productivity;
  • requires a self-conscious approach but no unsurmountable effort.

We also share a few tips on how we believe it can be made to work, including:

  • getting early, team-wide buy-in;
  • starting small, experimenting with policy and processes, measuring, and iterating;
  • being obsessive about excellence of communication and media;
  • leading and trusting as opposed to managing and monitoring..
Back story

I’ve joined HouseTrip in 2011 and have been a VP for the engineering team until late 2014. Under my watch, the team grew roughly from 10 to 30 engineers. We had a great time building a leading, sharing-economy fueled transactional website for holiday rentals.

Back when I joined, the team was on-site in our London offices, with an extra 3-4 contractors. We sustained a hiring rate of 1 engineer per month for about a year and a half, which in itself was an interesting challenge—how we built a hiring process while dramatically reducing churn will likely be the topic of a future post.

Halfway through my tenure, we faced a major resourcing challenge: we were hiring a lot of brilliant people, mostly people form outside the UK, and mostly with less than 5 years of experience. Now, I love them to bits, but we weren’t getting any seniors through the doors.

And by seniors, I don’t mean people with 3 or 4 years of experience (which seems the norm in some companies), but people who’d been building software for a decade, could mentor others, and lead technology decisions.

The lack of senior engineers caused imbalance: the team was less productive than it could be, made more mistakes or hasty decisions, and was frustrated by the lack of people to learn from and bandwidth to experiment. This also took a toll on the few thinly-stretched seniors we had, namely Matt, Nas and myself.

Seniors, Y U NO join?

Hiring developers is terribly difficult in London, and apparently in other tech hubs worldwide, because the local job market is saturated (many competing offers per candidate). The competition also is global. Some candidates will relocate, but recent history has shown that experienced candidates will not relocate to London, even for very high salaries (e.g. 80k£ pa, equivalent to $130k).

Jason Fried sums this up nicely in Remote:

Great talent is everywhere, and not everyone wants to move to San Francisco.

Our analysis at that point was that, given the competition and the very high value of engineers in the market, non-financial considerations prime in a candidate’s decision to join HouseTrip (or even consider talking to us). This is reinforced for experienced candidates.

The three main criteria are, in order,

  1. lifestyle, particularly quality accommodation and social services;
  2. technological challenge and/or learning opportunity;
  3. team ethics, processes, and team leadership.

Due to the nature and history of our business, we have been able to neutralize the last two criteria (i.e. avoid attrition to them) but not extract a competitive advantage from them (i.e. make them a hiring argument). Our hypothesis was that

  • we could gain a competitive advantage on the “quality of life” criterion by enabling both candidates and existing staff to work remotely, part-time or full-time for the company, and that
  • remote working can maintain or improve productivity.

Facts: going remote works

From the moment we came to the observations above, we decided to run a “remote work experiment” for a minimum of 6 months (as of writing, it’s been a year since we started).

The hypothesis was that remote work could actually work well, and the expected outcomes were solid guidelines and good practices that would make a distributed team sustainable.

The 6 sections below outline some of what we’ve discovered, in our particular setting.

Hiring remote seniors is easier

Several recent candidates had declined offers for the sole reason they would not relocate to London, and mentioned they would have joined, had we welcomed remote workers.

Obviously enough, there’s an age bias at work: “senior engineers” are at least in their mid-30s. Typically, they’re in a relationship; their partner is likely to have a job too, and many have kids.

This means they’re less mobile: amongst other reasons you can’t just ask their partner to quit their job, or to uproot their kids from school, friends, and family.

So we set to figure out how to change our recruitment practices to get those profiles in as remote workers.

Our sourcing process ended up not changing much. Internally our team was two people, Sandrine (head of HR) who generally only intervenes later in the process, and Salim (talent hunter) who hunts for profiles and handles most of the process (posting ads, pitching candidates, organising interviews, etc).

We ended up keeping a mix of:

  • recruiters (but they were less effective finding remotes)
  • in-house sourcing (fancy term for Salim sifting through LinkedIn profiles)
  • employee referrals
  • inbound through advertising

For us, referrals and advertising already had a regional reach. For instance, our most successful job advert was Ruby Weekly. We also kept feeding our tech blog, which didn’t bring candidates in directly, but did leave a positive impression—thereby helping conversion.

Recruiters became less effective, presumably because they’re used to a more local search and segregate between on-site/permanent on one hand and contract/remote on the other.

Our interview process didn’t change much either. Given many of the people we hired previously lived abroad and moved to London, our process was already suitable for remote hires.

The bulk of it, i.e. the first two stages, consisted in 4 interviews: HR intro, team-intro-career-culture-fit, 2 technical interviews. We used to believe the technical interviews had to be done on-site; but with good usage of tools (more on that later) we found out through trial and error that it’s perfectly possible to assess technical smarts over the wire. Importantly, remote technical interviews are a reflexion of how we’d work with a candidate, with a similar set of communication media (chat, screensharing, video).

The final round of on-site interviews was kept as-is: 1 one-on-one culture fit interview, 1 presentation, and the inevitable HR chat/closing interview. At that point the conversion rate is high enough to afford the plane tickets to fly people in, and the nature of the interviews made them less suited for remote.

While I’d have loved to test candidates presenting remotely, that’s probably a little harsh! But we did make sure our remote candidates had some experience working from home, even if not in a team (e.g. contracting).

I’ll let the numbers speak for themselves:

Active engineers graph

All but one of the hires in 2014 H1 were remote workers.

Don’t worry, there’s a few graphs with hard data later on. The important for now is this: with similar effort and an unchanged recruitment budget, hiring remotes was clearly a success for us.

10% time on-site is enough

I’m very paranoid about team culture. Others have written better than I would why culture should not be fucked. If you don’t believe people are the most valuable asset in the knowledge industry, the Financial Times says you’re wrong, and scientists have been writing about it for decades. Culture is also an asset, and here’s my management-orientated stab at what culture is:

Team culture is the intangible asset that makes groups of workers more productive, and stay longer in the company, that they would individually or in other teams.

Hint to VCs: measure happiness in your prospective start-up investments. You’re welcome.

In an era where attracting workers is costly, and particularly in startups where efficiency is crucial, culture must indeed be excellent.

Back when the whole team was on-site, we’d focus on hiring people with whom we shared a work ethic (no “rock stars”; you’re here to learn and have an enjoyable time; you’re judged on what you deliver) and values (empathetic and down-to-earth). We’d make sure they were decently skilled at had the potential to grow. And we’d count on the “intangible” part of the culture to rub off.

We thought, the rubbing off wouldn’t happen as easily with people being on the other end of Skype or Slack most of the time. So we’d need either a major rethink of how culture spreads and is stimulated, which we had no clue how to do, or get people in regularly so the rubbing off would happen.

Needless to say, we opted for the latter. After some discussion we settled on this rhythm:

  • For their entire 1st month, remote hire would live in London. This eased the on-boarding process a lot, got them immersed in the team culture, and they had a chance to put faces on names and socialize a bit. A far as I know, they all loved it.
  • From there on, they’d come back from 3 consecutive days, Wednesday to Friday, every other month. Friday is important because we have the team huddle in the morning and beer’o’clock at 5pm. Although we missed that the first few iterations, we figured it was best if they’d all come back at the same time.

Over a couple years, that’s roughly 10% of the time on-site. As a remote leader, we figured I’d come back twice as often—I ended up being on site about 20% of the time.

We had plans for a “remote week” where everyone would come in for a week then everyone (including management) would have to be remote for a week, but we never put it to the test.

Culture is not easily measured, unfortunately, so we do not have elements of proof beyond the generally increased job satisfaction in the team.

Remote workers are less expensive

…with a naggy sub-fact: compensation is contentious and complicated. But then, isn’t it always.

The brilliant folks at Buffer introduced open salaries a while ago, including for remote workers. I think they’re unfortunately biased, as they only seem to hire in high-cost-of-living locales. Their math is wrong: you get a extra flat amount per year if you’re in a high-cost city, period. They ignore subtleties like tax systems, social security, or the local job market.

Their formula-based system has the merit of simplicity, but it’s simply not enough in such a diverse landscape as Europe, where the cost-of-living and taxation can differ by a factor 5 between countries (thinking of it, this probably explains the mess our economy is in).

We decided instead to reason purely on a cost-of-living basis: for a given candidate, decide how much we’d pay them in London, then run the math.

The principles guiding the actual compensation were then:

  • The aim is to maintain comparable living standards between remote and on-site workers of similar experience and seniority, based on local cost-of-living data;
  • The local job market for equivalent positions is taken into account, with and aim to make offers in the 75th percentile.

For instance, cost of living is 20% lower in Lyon (France), 50% lower in Sofia (Bulgaria) than it is in London. Copenhagen is about the same cost but the tax there is mental. Differences in local wages, unsurprisingly, match cost of living differences quite precisely.

Our formula would make sure the effective take-home pay, after all taxes, social security contributions, and health insurance costs allows for similar standards of living—purposedly not the same absolute amount.

It was gruesome work, but we put together a spreadsheet and added cities to it as candidates came it. A few excellent sources of information:

  • Numbeo has details on costs of living, city by city;
  • KPMG’s TIES series (for instance for France) has precise information about the taxation mechanics in each country in the EU and the OECD.
  • Glassdoor and Payscale both have decent information on local wages.

Of course workers abroad can’t technically be employees, so we’d make sure to bump the compensation up a notch to account for perks they can’t get—e.g. sick days; typically adding 5% to the total.

Travel costs also need to be factored in: typically £3,000 for 6x 3-day visits per year (airline fares or roughly the same from any large city in Europe to London when bought in advance).

And conversely, fixed costs are lower for remote workers. Just counting office space, which costs about £3,000 per year, per seat in London, cancels out the travel costs.

On average, remote workers end up costing the company 20% less than on-site workers. Not a bad argument when making the case to your CFO, especially if you point out it’s lower than what most eastern European software outsourcing shops will charge you.

Contracts and compensation caveats

Practices, employment law, and commercial regulations don’t really get in the way but they weren’t designed for remote work.

Contracts

On the contractual side, remember that remote workers cannot (practically) have an employment contract without being resident in the same country as your company. This means they’ll have to set up a company of their own and invoice you. Many countries have a special, simplified regimen for the “self-employed” or “sole traders”. This can be complicated to set up on their end; the paperwork takes up to a couple of months in France, but only a few days in Poland or Bulgaria.

The trick here is that you do not want remote workers to be sort of second-class employees; their contract has to reflect that. We chose to tiptoe at the edges of employment law to make their contracts as close to employees as possible.

In practice, this meant factoring sick days into their daily rate and making sure we’d pay their invoices at the very beginning of each month. It also meant the contracts were 3-months rolling (to mimic notice periods) and 2-week rolling for the first quarter (to mimic the probation period).

Unfortunately, it wasn’t possible to pay them a fixed amount per month, only days actually worked; otherwise the contract would be too problematic legally.

Compensation

Over time, we’ve encountered some remote candidates who want London rates whilst living in a lower-cost country. I don’t mean them any harm, but can’t think of any other term but “greedy”. I didn’t believe in hiring these people. Not only is it ethically debatable to pay someone a disproportionally large amount of money, but it would create a very unfair imbalance situation in a team. Perhaps the market will prove me wrong.

Conversely some companies use remote workers primarily as a means to cut costs, and end-up hiring only remotes from low-wage countries. There’s a saying about peanuts and monkeys, of course. But more importantly, I think they’re making the same mistake as companies hiring only on-site: cutting themselves from most of the global talent pool, by limiting themselves to “low cost countries”.

For those outside the currency zone (Sterling for us), we chose to not have them suffer the Forex effects; they’d invoice us in their own currency, typically Euro. This means costs vary somewhat, but fortunately the GBP/EUR stays fairly stable.

If they’re outside the EU, we’d also have to take VAT into account, and possibly import tariffs. We never had to face the situation, so I can’t say much about that.

Distributed teams are as productive

As I mentioned earlier, we wore our scientist hats throughout our “remote experiment” at HouseTrip. After all, we’re breaking new ground—nothing of note seems to have been published on teams going from on-site to distributed.

Team productivity is difficult to estimate for knowledge workers, especially in an agile environment where objectives are loosely defined both in quantity and in quality. However, it is possible to

  • Use proxy metrics to compare test teams (within the area of impact) to the rest of the product team;
  • Use proxy metrics to compare productivity in the overall team before and during the experiment;
  • Complete a qualitative assessment survey at the end of the experiment.

All three come with caveats and are very noisy measurements. Fortunately, because we’re number freaks, we’d been tracking several metrics all along.

I’ll jump to the results as you’re probably expecting graphs at this point, starting with velocity.

Velocity graph

Velocity is the amount of story points delivered each week. It’s an approximation of effort delivered. We extract this data from Pivotal Tracker’s API. This measure is dependent on team maturity (how long has the team been working together?), average experience (senior engineers deliver 3 to 5 times the work once on-boarded; senior product managers and experienced lead developers act as a multiplier up to x2), and part of the project lifecycle. We have over 18 months of historical data on this metric.

Our execution processes when we started hiring remotes were already well-oiled, and we were planning to keep adapting them anyway. In particular, our estimation practices (“how many points for this chunk of spec’d out work?”) haven’t changed much over time. 2 points is supposed to cost a day of work for a typical engineer, and ends up taking a bit more, so typically we’d churn through 6 points per week, per person on average.

For reference, this is the number of active engineers any given week (the number of engineers who completed any work):

Active engineers graph

We started introducing remote work (hires, plus letting on-site workers remote fairly freely) in January 2014.

The graph above speaks for itself: remote had no significant impact on velocity. If anything, it stabilized! The bump and trough in summer and fall ‘13 matched a lower number of people being on-boarded, then a large number of hires in rapid succession, taking a temporary toll on team productivity. No such thing in ‘14, in spite of a similar number of—senior—hires.

Team activity graph

Velocity isn’t meant for long-term projections, so we complemented with a couple of other metrics including a contribution score. Contribution is our measurement of activity in a team—basically you get points for every pull request you submit (that’s Github lingo for “submitting code for review”), comments on pull-requests, merging them, and deploying to production.

This metric is more reflective of individual developer participation in engineering (i.e. has less team bias), and is less sensitive to raw skill, competency, or experience.

The graph above (the size of the team is averaged out) clearly shows the team interacts more, on average, over the first 3 quarters of 2014 than during the same period in 2013, this in spite of up to half the team being remote.

These results came as a pleasant surprise to us, and match our gut feeling while running the experiment.
While “remote” inevitably introduces some friction (even if timezones are the same), remote workers don’t have a crazy commute nor the stress of the big city, and it seems to rub off on the rest of the team.

Non-physical presence is a non-issue

In many companies, and in start-ups in particular, the myth goes that “magic only happens when we’re in one room”. I attribute this to the lasting impact of our pre-Internet era heroes, the canonical example probably being Steve and Woz assembling the Apple I in a garage.

Countless modern examples demonstrate the “magic” can happen without people meeting in person, from people assembling to fund projects on Kickstarter to the people toppling oppressive regimes by leveraging social media. There are, of course, brilliant examples in the world of startups: Sqwiggle, a tool proudly supporting distributed teams, lists a few successful tech companies that went remote from the get go.

We’re in the unique situation where we can measure the impact of non-physical presence on a software engineering process, so let’s see what happens to communication efficacy in a team that went remote.

PR latency

Another metric we harvest over time is pull request latency, i.e. the time between issuance and merge. If you’re interested in measuring this for your team, the code’s part of git-heroes. We find this to be indicative of good communication and cross-team cooperation: pull requests are reviewed asynchronously, and conventionally merged by a different person than the issuer.

For those unfamiliar with PR-driven code reviews, we consider that barring exceptional circumstances, a “good” latency is between a few hours (0.1 in the graph above) and one day. Too low means the code hasn’t been reviewed properly (bad engineer behaviour) or the unit of work was too small (bad requirements). Too high means communication broke down (“I can’t be bothered to review code”) or, again, poorly specified / overly broad requirements.

Latency did, on average, increase in 2014 H1 (the period where we went full-on remote), but stabilized around the 8 hours mark, well within our acceptable range; if anything it was better than before, as in 2013 pull requests tended to be merged hastily.

Now, this first graph exhibits another trend which I’ll clarify:

PR latency spread

Roughly speaking, spread is a metric that decreases as latency becomes more consistent across a team. It’s in log scale, so linear improvements are actually much larger (for the stats inclined, I’ve defined it as the log-difference of the 3rd and 1st quartile of latencies of pull requests on a given week).

With the team getting used to systematic code reviews over 2013, spread had already started to improve significantly; far from being affected by the presence of remotes, it steadily kept on improving in 2014.

The trend of PR latency and its spread over time is, in our opinion, indicative that remote stimulates consistent, asynchronous cross-team communication. In other words, latency has marginally increased but throughput has remained constant.

Working remotely is hard

We’re not debating that working in a distributed team is harder than with a fully on-site team, be it for those working remotely or those on-site if any. Our point is that the benefits significantly out-weight the difficulties.

This said, we believe that understanding those difficulties is critical to make remote work. Here’s a short list of the issues we’ve encountered.

Cabin fever: the lack of a real watercooler—or in London, of the after-work pint at the pub—can mean workers don’t have a chance to vent. Individuals problems (anything from lack of recognition to personal problems) can go unnoticed, and this can result in frustration from remote workers. We found that this can mostly be averted by re-creating a watercooler atmosphere (e.g. in a cheerful #random channel in Slack), and by more proactive, self-conscious management (more below).

Time zone differences: we experimented with workers 9 hours ahead of us, therefore with minimal overlap between normal working hours. The experience was disruptive and stressful both for the remotes and the rest of their on-site team. We haven’t found a good way to circumvent this; our conclusion is that time zone differences of up to ±4 hours (half a day) should be the limit inside a team/squad/scrum.

We briefly considered to ask engineers to adjust their working hours to GMT, also known as “work all night and sleep during the day”. Some outsourcing companies, e.g. Toptal, advocate this. To us, it’s obvious that putting workers in this situation would make them less productive, stressed, unable to balance a healthy non-work life, and generally unhappy—the exact opposite of what we’re after.

Behaviour inertia: particularly when stress levels go up (e.g. around a deadline), we found that on-site workers would fall back into old habits. They’d forget remotes during stand-ups, or turn their back to the camera. This was particularly negative for remotes.
Again, being proactive (e.g. running retrospectives) and apologetic whenever this happened (either because we forgot or because Skype went full FUBAR that day) seemed to compensate the issue.

Inexperienced remoters: we envisioned this to be a problem, as we do not know how to train a person to be efficient as a remote. We chose to avoid the issue by favouring candidates with remote experience, or agree on a trial. As remote work picks up in the industry, this will have to be addressed.

Remote management: as part of our “remote experiment”, I went progressively remote myself. Over a quarter, I went from 100% on-site to 80% remote (on a 20 days remote / 4 days on-site basis).
After a brief period of cabin fever on my end and sense of abandonment from my team, we found a suitable rhythm and communication style. One-on-one discussions became more frequent, meetings became more focused (agendas!) albeit less frequent, and gathering on-site with the team became more celebratory.

Our conclusion is that having a manager at least part-time remote was instrumental into changing our practices to make “remote” work for us.

Tips: making remote work.

This second part is about sharing practical, applicable elements to make your on-site to distributed transition work.

Read!

Distributed teams are still uncommon, so you may have trouble finding a brain to pick in your own network. Here’s a few resources we found valuable:

  • Remote: Office not required by Jason Fried of Basecamp (née 37signal) fame.
  • Sqwiggle has great tips, as they shoudl given their product supports remote teams explicitely.
  • Ralph Dandrea, CEO of ITX (a small IT firm), has employees on 3 continents and writes about what makes “remote work workable”.
  • Zaharenia, a UX designer at Workable, shares a personal experience.
  • Zapier writes about how to build culture in a remote team. Also check out their previous article on a remote-oriented hiring process.
  • Rick Freedman shares some tips specifically for leaders, on the topic of trust.
  • Zoho shares more tips on culture, based on their Indian experience.

There’s plenty more out there, just remember there isn’t much maturity on the topic—other experiences may differ from you own (or ours!). YMMV.

Get buy-in

Convincing upper management to “go remote” is tough, but avoiding emotional arguments and presenting the facts should work, provided your company is well-led.

After all, assuming you have a hiring crisis like we did, no sane manager would refuse an opportunity to

  • solve the hiring problem,
  • while lowering overall costs,
  • with demonstrable success elsewhere, and
  • low and controllable risk.

The trick, in our experience, was getting everyone else on board. Engineers and product managers alike can have an “if it’s not broken, don’t fix it” attitude towards organisational design. Even worse, some on-site workers may want to become remote and resent the fact the opportunity would be given to newcomers.

We took that latter risk, in the sense that we explained that (a) this all was an experiment, and (b) should it succeed, of course we’d consider letting people “go home” to the country they’re from, or work part-time remotely, on a trialled, case-by-case basis.

All things considered, what convinced the team was:

  • we were completely transparent about how we’d run the remote “project”, to the point various iterations of the draft internal policy on remote work were open for comments and publicly debated;
  • the team was feeling the pain of the lack of seniors on board;
  • I personally showed commitment and confidence to the cause, and actually went remote myself progressively.
Start small

I’ve mentioned we originally ran remote as an experiment. This was made clear to all, including prospective hires: success was not guaranteed. We made the experiment manifesto public internally, and decided on

  • a timeframe (6 months)
  • metrics (which I’ve described at length above)
  • goals (improving the number of hires while maintaining productivity)
  • test and control groups (we only included remotes in 3 out of 6 product teams initially).

This rational and cautious approach was instrumental in convincing the powers that be this was worth a try.

Communication tools are crucial

Over the first quarter of the experiment, we highlighted two points:

  • good tools supporting remote are absolutely fundamental.
  • the magic quatuor for us is Pivotal Tracker + Skype + Slack + Screenhero.

Groupware. To the ire of some of our designers, it quickly became obvious we’d need to get rid of any physical artifacts. Our very last physical Kanban board went the way of the dodo, as it quickly became useless and impractical.

Face-to-face communication. Yes, Hangouts and all of its WebRTC-based friends are nice and open and fun. But they just don’t bloody work: they’re resource intensive and cope poorly with degraded connections, or many participants. Plus their UX is far from convenient. Skype, as much as we loathe Microsoft products, is still unrivalled for general use cases.

Team discussion + watercooler. I don’t even know where to start with Slack. They’ve simply nailed group chat, standing on the shoulders of HipChat and Campfire. Integrations, bots, public/private rooms, cat GIFs, and a great mobile app; you name it. Oh, and it’s free, too.

Pair programming. Vim+Tmux is hip. It kind of works… but it does require more setup (such as a central server), and can be painful to the inexperienced geek. ScreenHero, while not free, just works and doesn’t care which app/editor you’re using. It also marries nicely with OmniGraffle or Balsamiq for UX work. For “real” (active/passive) pairing, Skype’s screensharing is reliable and good enough.

Last but not least, remotes should most of their time have a solid Internet connection. Inexperienced remotes (and inexperienced teams) might think a 5Mbps/1Mbps, run-off-the-mill cable connection will work. It doesn’t. The minimum for a smooth experience with all the tools above: a 20/5 DSL line with <100ms ping times, and no traffic throttling or caps. We’ve found that a good VPN can help. This might be a show-stopper for most parts of the US, but it’s generally achievable throughout Europe: I live in a tiny town of 3,500 souls and have a 50/10 VDSL2 line, and 32/15 on mobile 4G.

Trust your team

A few of the links above cover this; and Remote even has this nugget:

There’s something primal about being able to see your army, about having them close enough that you can shout “Now!!” like Mel Gibson did in Braveheart, and watch them pick up their spears in unison.

To emphasise my point, here’s an excerpt from a conversation I had with a manger toying with the idea of hiring remote workers:

Them — Did you use any software to manage the time? eg TimeDoctor or HubStaff

Me — we considered it. but we ultimately decided that what matters are results, not time spent working, so it would be a bad message; and we wanted a relationship based on trust in the team.

Monitoring and micro-managing people assumes, as a default, that they’re untrustworthy slackers. This may make sense in some industries (although I doubt it) but certainly doesn’t for knowledge workers.

Even worse, imposing this kind of constraints solely on remote workers instills a dichotomy: trust on-site workers (they’re at their desks, so they must be working) but not the remotes.

We did have issues with attendance, but only with a single person. They’d disappear at 3pm (actually to go pick up their kids at school). A frank conversation on the matter, and laying down the rule, resolved thing easily and peacefully.

In our experience, remote workers are just as dedicated as on-site workers. Why wouldn’t they ?

Tool up for accountability

In product, design, and engineering work, accountability is often implicit but also implicitly measured: requirements, wireframes, and code all are visible artifacts of the job having been done.

Morning stand-ups are the moment when this becomes concrete; and tools like we’ve used (Pivotal Tracker to define, dispatch, and track work; Github specifically for software artifacts) provide means to keep a track record of the team and individuals, should the need arise.

Accountability is unfortunately even more implicit in leadership roles, as there are fewer tangible artifacts. As a remote VP, or for team leads who were part-time remotes, we found that using a low-overhead reporting tool worked just fine. Google Snippets is bare-bones, but lets you broadcast a text-only weekly digest of your activity to interested parties (typically your manager and peers), thus materialising your not-immediately-visible work.

Make remote meetings smooth

Too many meetings is the source of all evil, but you do need some.

Assuming your on-site meetings are already relevant, targeted, and have the right people and frequency, you now need to make the same magic happen with potentially half the attendance not physically present.

I’ve paranoidly instigated a habit of including remotes in all discussions; I’d get properly upset if someone called for a quick, informal team meeting and excluded a remote out of convenience (or habit).

While those symptoms are likely to require some care for as long as a large portion of the team remains on-site, I’ve observed them recede after we:

  • ran dedicated “remote retrospectives” to highlight issues, the majority of which were practical;
  • acted on the issues, by providing remote-friendly spaces in our offices.

I turned out to be as simple as:

  • cranking up the quality of our Wifi: 1 access point per every 10 people (or ~25 devices), 5GHz only, in a roaming setup (single SSID). Thank $supremeEntity for no-hassle Apple Airport devices.
  • buy headphones. Duh.
  • invest in video-conference rooms.

This last point can sound scary and expensive; we only spent about £1,000 per meeting room (for up to 5 people on-site) and a bit more for our boardroom (for up to 20 people):

  • 1 Mac Mini, with a dedicated Skype account (“Meeting room Foo”)
  • 1 or 2 big-ass screens of any quality (1 for the conference, 1 to share slides/code/designs)
  • 1 AppleTV (to project what’s shared on the screen)
  • A decent HD webcam (Logitech C920)
  • A really excellent speakerphone. The ClearOne Chat 170 is your friend.

The remote end is simpler, as long as their Internet connection is good and they use headphones too. As an anecdote: I twice ran our Friday all hands (with over 20 people) over a 3G line. Yes, it did work well—Skype doesn’t need much resource. As long as you don’t speak immediately after changing slides, it’s enough in a pinch!

Communicate less but better

Going distributed means more will happen asynchronously and online. Meetings don’t disappear, but it because more crucial to do those well.

In an on-site team, you can get (sometimes) away with not having a written agenda, by asking about it during the morning coffee break. Likewise, you can get away with pushing a meeting back by 10 minutes because you’re late from the previous one.

In a distributed setting, meetings aren’t inherently more painful or expensive (as highlighted above), but bad meeetings become more painful.

It’s not my place to give lessons on running efficient meetings, but remember the basics:

  • have a clear agenda;
  • invite the right people (never more than 7);
  • be on time;
  • always consider discussing on-line instead.

A killer symptom I’ve observed occasionally, particularly in teams with part-time remotes, consists in pushing back meetings to when the whole team will be on-site.
This happens because until a team gets into the new habits, remote meetings are more difficult (because they’re a new practice), and people are lazy (which as you know is a virtue in software, but not in team organisation). Rationalizing the issue, along with the improved meeting rooms, was met with moderate success.

Finally, a tip for team leads and manager: take time for one-on-ones with your team members (and your own manager). I’d suggest scheduling them regularly, for instance biweekly. This will be awkward for those used to having one-on-ones during coffee or smoke breaks, but having some “us” time is still crucial to forming and keeping a bond, and to discuss issues that cannot be discussed in a group or would be hard to express over chat or email.

Advocate and experiment

In conclusion, if turning your on-site team into a distributed one is tempting, know it isn’t a walk in the park. You’re likely to be met with criticism and concern initially.

Hopefully our experience convinced you that it’s doable, and provided some ammo to demonstrate it can be effective, even a competitive advantage for your company.

After reading this, you’re likely to have numerous questions about how this would work in your particular environment. Would this work at all for us? How often should remotes come? What process needs to be changed? Should we hire for different skills? What about people who used to be on-site? Should we allow switchers?

Please remember that as an organisational practice, remote working is still in its infancy, and lacks the decades of experience gained from traditional management and organisation styles.

So, please do experiment, advocate remote work, and share your good or bad experiences!