Jeremy Stanton has been developing software since 1996, and working remotely since 2000 when the company he was working for moved to another city. The company saw no reason for Jeremy to move with them or for them to stop working together. They’d worked together long enough to know that working remotely wouldn’t be an issue. And he’s been working remotely ever since. I spoke with Jeremy over a Hangout on Air where he revealed his insights into how he got started, what’s worked and what hasn’t.

Here are the highlights:

• Be deliberate about your hiring process and culture.
• Be deliberate about your on-boarding process.
• Communication should be easy, often, and light-weight.
• Have your expectations very clearly defined so you know what success looks like and what failure looks like.
• Use whatever tools make it easy for your company to stay on top of what you should be doing.
• Have both structured and unstructured time.
• Try things in little chunks so that there’s limited risk and an opportunity to change things quickly if it doesn’t work.

Be deliberate about your hiring process and culture

A lot of building software is hiring the right people.  A lot of people think that culture is some kind of magical thing.  It’s not.  You have to be deliberate about having a specific culture rather than hoping you’ll end up with one you want.  Hope isn’t going to get you where you want to be.  Write down what your priorities are.  What kind of people do you want to have?  What characteristics do they need to have?

You need this first, especially when you’re starting a company. And then that gives you a template against which you can hire.  I think it’s dangerous, or at least very risky, to hire without having a very clear view of what your culture should be like.  I’d rather have the right kind of person than the right kind of resume.  You want people that don’t need to be lead: self starters and accountable.  You hope to surface this kind of stuff during interviews by asking for specific questions with anecdotal answers.

Be deliberate about your on-boarding process

When hiring, you want to eliminate as much risk and uncertainty as you can.  And that continues after the hiring process.  Just like with the hiring process, you have to be just as deliberate about the on-boarding process.  On-boarding is where a lot of companies drop the ball. You’ve got to fail people as fast as possible, because the longer they stay at your company, without being the right kind of fit, that’s just money being flushed down the drain.  In addition, it slows everyone else down because everybody has to deal with (at least, mentally) the fact that this person is not a fit.

Having a good process in place is clearly more important for remotes simply because it’s easier to hide shenanigans when you’re remote.  Have your expectations very clearly defined so you know what success looks like and what failure looks like.  Schedule regular opportunities for both parties to face those expectations.

Challenges of remote working

The biggest challenge is making sure people are talking.  But then, this is all stuff that should be happening whether you’re working remotely or not.  It’s just that with remotes, you can’t ignore this stuff.  You’ve got to be communicating regularly.  You’ve got to be communicating as clearly as possible and as much as possible in the least amount of time. This kind of thing can get out from under you if you’re not deliberate about communicating.

I’m not a fan of meetings.  I prefer flow.  But I like to make sure we’re having the meetings we need to have.  So with remote working, the daily stand-up happens during the first hour where it’s at least 0800 for everybody.  The idea being, that every day, everybody gets a taste of the pulse of where we are.

Like I said, all of these things are the same challenges that you deal with in the office – but you can’t ignore them when the person is remote.

Some people say that remote working is hard, so they’re not going to do it. I tend to lean into my pain and do it more, until it doesn’t hurt anymore.  If you lean away from these problems, you’re only hiding them.  I’m not saying that everyone has to have remotes. But if you physically recoil from the idea of having remotes, because something about it freaks you out, it’s probably because you’ve got some kind of underlying problem at your organization that you haven’t addressed yet.  You’re feeling it in your gut, but your brain just hasn’t realized it.

Benefits of remote working

I’ve been able to live somewhere with a very low cost of living while enjoying a metropolitan income.  But, the bigger part of this, is the opportunity to work on really interesting technology and with people doing interesting things.  And that’s what I’ve really gotten the most out of without having to move.

I’m not opposed to moving. If there was a situation where the company could clearly demonstrate why my being in the office would radically change for the good the nature of the work being done, then I would say ‘yes, I’ll move in a heartbeat’. But to date, no one’s been able to demonstrate that.

With working remotely, there’s a lot more room to ramp into the company. You can get great people at a reduced rate, without it feeling like a reduced rate to them. They’re getting a premium salary for their location and they don’t have to move.

The one exception I can imagine is where you’re a co-founder responsible as the product owner where you have to marinate in ideas constantly, then I could see value in being co-located.

Companies that can support remote working will outperform companies that don’t. Companies don’t have to have remotes.  But if they have communication processes that make it easy for a remote to work with them, then they’re going to be better off.  All the things that make it possible for a remote to work, and work well, are things that you’d want anyway.  People pay lip service to those things, but they don’t necessarily execute on all of them.

If you’re trying to allow for remotes, or make existing remotes more functional, the focus should be whatever makes communication more efficient with the least friction possible. It shouldn’t be hard for the team to communicate. It shouldn’t be hard for them to know what they are supposed to be doing right now.  It shouldn’t be hard for them to know what success looks like, to be doing their job right and know they’re meeting expectations. Every company pays lip service to this stuff but only the ones that could be successful with remotes can be certain they’re achieving those things.

Remote collaboration tools

Use whatever makes it easy for your company to stay on top of what you should be doing.  I’ve had a lot of success with Atlassian’s Greenhopper, now Jira Agile.

We used Skype but switched to Hangouts because it was more reliable and screen-sharing was better. At a previous company, we were big fans of flow and we tried to make as much communication as asynchronous as possible.  We considered video very disruptive, so we would only do it for things where we absolutely had to be in the same place.  We had a rule that if you were going to interrupt someone with video, you couldn’t just do it spontaneously.  You had to ask with a chat message first.

For documentation, I tend to like wikis. For small teams, a doc in Google drive will work. You’re going to want to have your culture documented.  You’re going to want to have your on-boarding process documented.  Not just so you can keep track of it, but also so that your teams can help you collaboratively maintain this stuff.  There shouldn’t be just one person owning this.

Structured vs unstructured time

Agile offers cadence and enforced conversations. You’ve got stand-ups. You’ve got retrospectives, and things of that nature, where there’s a very specific agenda.  And with a known agenda, you want to get in and out as fast as possible.

What that doesn’t allow for is room for intuition, for issues surfacing organically, or room for empathy related stuff, where if somebody’s got “the feels”, there’s not really an opportunity to express that.  So I borrowed an idea from Google and had office hours… with two separate team meetings for “tech talk” and “process talk”.  They were essentially our process for improving our process.

The last piece we had was one-on-one discussions where we had some time blocked off each week so we could just talk to each other…. it’s a stand in for the water cooler. It’s an opportunity to have a very unstructured time to discuss what’s on your mind. Again, when your entire team is remote, you have to be deliberate about these things.

The only thing I couldn’t find a replacement for was Happy Hour… and the team building that happens with everybody just hanging out over a big pile of nachos. How do you do that when everybody is remote?  I’m still working that one.

Why do businesses resist remote working?

Because nobody got fired for saying no to remotes. It’s easy to say no because there’s no risk.  But I would challenge anybody who has a knee-jerk ‘no’ reaction to remote working, to really dig into why they’re saying no.  And they can still say no, but they should do their homework.  If your first reaction is to say no without really thinking about it, there’s a good chance there’s something wrong with your organization.

If you create a culture that’s exciting to be in, and you’re working on stuff that’s worth working on, people get excited about it and want to be working.  They don’t have to be in the same room with you for that to be the case.

Advice for companies just starting

For businesses who are just starting out, try going a week and experiment with what works… tweak the knobs. I would suggest that for anything new that you’re trying, whether that’s a business process, remotes, a new product, whatever.  You want to give yourself an opportunity to try things in little chunks so that there’s limited risk and an opportunity to change things quickly if they don’t work.

More information about Jeremy Stanton.