2012/How We Went Remote

From Open Source Bridge Wiki
Jump to: navigation, search

Hiring remote workers is great for filling those holes on the team…but if you don’t have the correct infrastructure in place you’re just setting yourself—and your remote team members—up for a world of hurt. This session will detail how our engineering department went remote and thrived because of it.

Speaker: VM Brasseur

Return to this session's details

Contributed notes

The slides for this presentation are available on Dropbox. --VMB

Case: iPost. Used Perl, MySQL, open source stuff

VM Brasseur: software engineering manager

Based in Novato, CA. 5 yrs later, moved to San Rafael.

Why: geography. Not a lot of tech stuff in the North Bay. San Francisco is behind a bottleneck (Golden Gate Bridge); people want to work there, not North Bay. Can't rely on finding good engineers there.

Senior engineer had been at the company since ~beginning. He and CEO were only ones who knew what to do when shit hit the fan. Decided to move to Las Vegas.

Another engineer decided to move to San Jose. Said he was willing to do the drive, work 5-2 daily. 2.5 hours each way on a GOOD day. VM said sure, willing to try it -- but also knew he was going to leave. Jobs easy to find around San Jose.

Final engineer left for reasons not relevant to this presentation.

VM lived in Oakland, 60 miles round trip to Novato. Meh. Wanted to reduce carbon footprint.

  • Nigh on impossible to recruit or hire
  • Retaining critical staff
  • Personal philosophies

Some other reasons companies want to do remote:

  • 24-hour coverage
  • Employee satisfaction
  • Real estate costs (IBM dropped $150mil in costs)
  • Can pay lower salaries. :-( VM does not do this -- pays the same regardless of employee location; pays based on value to team.
  • et cetera

How ...

Not a fast process! Gradual evolution. Took over a year to get it working, approved, and in place.

Had to address many areas in parallel:

PROCESS

  • care and feeding of a bug ticket. Should be solidified before people start using it!
  • In-person processes with other departments (e.g., HR has people sign a form for vacation requests). Used PDF forms, emailed in. Had to get HR to be okay with "Digital Signatures." HR was okay with a "Digital Signature" in the form of an email with an attachment.
  • Expense report. Accounting turned out to be happy to get digital files, using the same signature requirements HR specified.
  • Coding style. Needed to get it written down and agreed to. Didn't expect to have to resolve this before going remote, but did.
  • How to deal with Kanban board. Had to move out of meatspace and into cyberspace. One of the engineers was a wizard with extension.js and wanted extra credit, so he put the board on the web. This board also acted as a moving agenda for the daily meeting.
  • Processes that are ubiquitous in effect, practiced by people, and accepted as fact MUST BE QUESTIONED. (Venn diagram)

DOCUMENTATION

  • Can't say RTFM if TFM doesn't exist.
  • Absolutely critical for a distributed team.
  • Email doesn't scale.
  • Had a wiki. Like most of us, iPost had a wiki, which was in a sorry state. Went through the entire wiki, updated all the pages, organized it. Was not nearly as hard as changing the mindset of everyone who thought the wiki was not to be trusted. Started referencing the wiki all the time, issuing bug reports for wiki pages. Now people have a place to look for *and* to put information.
  • Demanded perldoc.

COMMUNICATION CHANNELS

Wanted to build a distributed team, not a collection of remote workers.

  • Had wiki.
  • Corporate skype accounts. Had all meetings via skype with web-based kanban board.
  • How to duplicate information-rich environment for office? Group chat room. (Some people use IRC. For security reasons, company had rolled out Jabber, so they used a chat room there. If you're working, you're in the chat room.) As a side benefit, they were able to push forward a technology the company had already adopted but wasn't using much, use it to connect with other departments.
  • In-person contact. 2-3 times a year, in-person at the mothership. With beer in the evenings. People in support were hesitant to approach engineers until after they'd met in person.

TOOLS

  • bug tracker (bugzilla)
  • wiki
  • jabber
  • skype
  • Had trouble finding:
    • whiteboard
    • screen sharing (didn't have gotomeeting then)

"Eat your own dog food" -- if you roll out a tool, you need to use it (or verify that it's being used). If not, scrap it.

PLAN OF ATTACK

  • Have to sell stuff, e.g. to CTO. How long did it take to find your last engineer, how many resumes are you not getting?

SELLING IT

  • Know your audience. Have your documentation together, finesse it.
  • Don't be afraid to use FUD. (E.g., key person is leaving.) But don't lie or deceive.

EXECUTING THE PLAN

  • Processes are all in place.
  • Needed to make one change: interviewing. Did them by phone; made them easier to schedule!
  • Remember to click the "telecommute okay" box.


Q: What's the name of the web-based kanban board that was used? A: She didn't mention a name, but it was internally developed using extension.js