Mobile Developer Distributed Office Tools

Hello business team. Look at your office, now back to mine, now back to your office, now back to mine. Sadly we’re not in the same office, but if you closed your eyes and fired up Skype you could pretend you’re in my office. Look down, back up, where are you? You’re in San Francisco with half your company. What’s in your hand, back at me. I have it, it’s a spec sheet to that feature you love. Look again, the spec sheet is now a production release. Anything is possible even when you’re in SFO and we’re in PDX. I’m on a horse.

Body wash aside, I’ve got two things for you; having offices in different cities is great for your start-up. Second, having offices in different cities can ruin your start-up. PlayHaven is headquartered in San Francisco with a sister office in Portland, OR. This helps our business by increasing our hiring shadow to two tech heavy cities. This hurts our business because half of our team is inaccessible in meat space.

It’s that second bit that can ruin your business. When I’m neck deep in code with my head down, and dub-step pounding through my headphones I’m not exactly prone to picking up my phone or checking my email. However every time I have to peel away from my desk for a meeting, take a call, or weigh in on an issue it takes me a good 10 to 15 minutes to pick back up where I left off, and that sucks.

At PlayHaven we’ve struck a balance using the following tools and techniques:

Social source management

PlayHaven’s development team is split between our offices but we all still have our fingers in the same code. Without a solid branching model and peer review process this would get hairy, fast. github provides fantastic tools that keep a high level of transparency and promotes communication. Before a developer is allowed to merge their feature branch into the mainstream a pull request is issued. Any interested parties can leave comments inline, link to examples in other projects or just investigate the change. Since each pull request has it’s own link I can drop it into Campfire asking for a review, and into the ticket for later reference. No one is getting derailed, I’m not generating unnecessary emails and there’s a documentation trail.


A single persistent line of communication

While phone calls and single IM’s can be distracting there’s still a need for a solid line of communication. It needs to be persistent, searchable, and it needs to be available to the entire team.

Campfire fit the bill for us because it allows for multiple rooms, it maintains searchable transcripts and more importantly it allows people to be expressive with pictures and video. It can get a little spammy but there are a number of third party clients that will monitor the room for you and alert you when you’re mentioned. Our team uses Propane and Fluid, both of which add support for Growl notifications and unread message counts. Our DBA gets a Growl notice anytime anyone mentions MySQL.

We also have a bot that monitors and reports pull requests, new branches and pushes from github. Via Campfires API we’ve also incorporated our bootstrap script to report success/failures when creating new nodes, and our deploy scripts to report propagation failures.

All of this could easily be done with IRC or any number of open protocol chat services.


Collaborative project and task management

While github excels at collaboration within a single project, our work more often than not involves multiple repositories and teams. That means work on the SDK needs to be coordinated with API work, which often needs to be presented on our publisher or advertiser dashboard somewhere. To keep track of the bigger picture, we use Pivotal Tracker to cost, prioritize, and assign feature development and bugs. It’s a great tool for our product guys to be able to keep track of status on features as well as making sure team priorities are well communicated to the team. One helpful addon we use with our Pivotal project is Sluglug, which automatically appends a tag to each story title. It’s much easier to talk about the status of [williamsburg] as opposed to story number 25763213.

As with github, our helpful chatbot also lets us know about new stories, comments on existing stories, as well as status changes in our Pivotal Tracker project.


Daily scrums and meetings

While we try to keep engineers out of meetings as much as possible, at some point we need to get some number of people to sit down and talk. This is true for every engineer for 15 minutes every morning during our daily scrum. When we first started, we would stand around the ping pong table in SFO, occasionally having someone call in on GTalk, Skype or iMessage. Once we started to grow we needed a solution that worked with our distributed team, and our flexible schedules. Today, we use GoToMeeting for all of our conferencing needs. We can get everyone in on a call, whether they’re on a laptop or one of the conference phones in our meeting rooms. We use a recurring meeting for our daily scrum, so that means an engineer can still call in case of a transit delay or other emergency.

These days, there’s a lot of technologies and services out there to make distributed collaboration easier. We’ve arrived at this particular combination of tools through trial and error. It’s easy enough to start a free trial, or open a basic account, that it’s worth that little bit of effort to find the right mix for your organization. In fact, we’re still looking for the perfect collaboration tool. We’d love to hear your recommendations in the comments. Until then, go forth and be awesome.

Add comment


  1. Hell yeah dubstep like that! I’ll have to add these into my pandora line-up.

    Seriously though, having up tempo music with little to no lyrics is key for my concentration. It keeps my energy up but I don’t try to follow along so much. I’d be curious to hear what other people listen to (if ya do) while they work.

Leave a comment

− three = 2

NOTE - You can use these HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Switch to our mobile site