Wednesday, January 15, 2014

Remote Control

Twenty years ago the internet was still a research project where most people didn't have email and the idea of real-time video was the fantasy of porn addicts wishing for something better than usenet. Now gigabit fiber to your home is a thing and we all have wireless supercomputers masquerading as cellphones on our hips. It should come as no surprise then that the nature of work and how it gets done is changing. Remote work is a viable option for many despite the resistance of some. I'm not here to insist that you use remotes but I am saying, if you adapt your processes and how you communicate so remotes could work well, you'll outperform companies that can't. Here's why...

Better onboarding


On-boarding is where a lot of companies drop the ball. With everyone under one roof you get a lot of it for free so it's easy to convince yourself you're doing it right. If you have gaps in your onboarding or have no formal process at all, your remotes will be culturally disengaged, and much slower to learn your architecture. You might also have trouble gauging their progress ramping up and it's likely they'll feel lost to some degree. Reality check. Your in-office new hires have the same problems but are able to mitigate your lack of support through osmosis. It's a coincidence of geography that your in-office hires aren't performing as badly.  With remotes you have to be deliberate because your deficiencies are exaggerated. Get it together.

Better processes

Do the developers on your team have to tug at someone's elbow to get code reviewed? To have the code tested? To coordinate a build? To publish a release? If your development and deployment processes require your communication to be synchronous you're going to end up with a thousand little inefficiencies with frequent blocking as people wrestle for each others time. Because the waiting is brief this is easy to overlook. Each interruption also disrupts flow causing you to lose at least half an hour per day in lost productivity. With everybody in the same space, interrupting Bob once a day to do x may not seem like a big deal, but multiply that across each work day all year long. Add in remotes and watch the problem explode.  

We did the math at our own company. Manual pushes to production were costing us three man-weeks per year on a four person Dev team. That's an enormous opportunity cost. But there was hope. The initial estimate to fully automate our test and deploy process was only four man-weeks. Given that we'd gain what we lost in the first year alone it was a no-brainer. But we didn't stop there. We found the guys at sprint.ly had some great posts on Asynchronous development. It's a natural progression from the branch-per-feature approach. We didn't go completely asynchronous, but we did cut out most everything else: meetings and hand-off-wise, saving additional weeks of Dev time annually.

Better communication

The biggest challenge is making sure people are talking.  This isn't unique to remote working but it's the one challenge managing people that is the most exaggerated by it.  Worst case, a remote could spend weeks wasting the company's time surfing Youtube for cat videos. Conversely they could be a rockstar and you'd have no idea.  

Communication should be easy, often, and light weight - stand-ups are a good start, but make as much of it asynchronous as possible.  Make your expectations clear so you both know what success and failure look like.  You can establish these collaboratively but they should be documented and clearly defined.  Is the remote under performing?  They should know without having to ask you.  Are they excelling and the business is pleased with their performance? This should be crystal clear, not in some distant quarterly review, but continuously, because of the team's definition of success. 

I’m not a fan of meetings - I prefer to maximize flow - but I like to make sure we’re having the meetings we need to have.  About now you should be thinking, hey, those things sound good regardless of whether we have remotes.  Good.  That's the point.

Test, test, and then test again

If you're a business that is interested in trying remotes for the first time, run a few tests with existing employees. Tweak the knobs and experiment to see what works. I would suggest that for anything new you are trying whether it's a business process, remotes, a new product, whatever. You want to give yourself an opportunity to try things out in short runs so you can change things quickly if they don't work.

Why do people resist remote working? Because nobody got fired for not allowing it. It’s easy to say no because there’s no perceived risk in it. It feels safe. I would argue, though, that if you aren't able to support remotes, your company isn't as healthy as one who can. And that is a problem. If this describes your organization, explore why. I guarantee you you'll find something you can improve.  

For a full interview with me on the topic check out this link here. You can also check out more material from my interviewer Lisette Sutherland here as well. Enjoy!

No comments:

Post a Comment