Announcement: We're Writing The Book On Remote Work

January 20th, 2016Dan Yoder

As you may know, Panda Strike is a 100% remote work company. We’ve been so since we started back in 2012. During the past couple of years, we noticed that interest in remote work appears to be increasing. So we thought we’d share what we’ve learned in an ebook on the subject, which we plan on making available in February. Join our mailing list and we’ll let you know when it’s ready.

A Tale Of Two Offices

I came to remote work by accident. Back in the early aughts, I was leading a software development project where we did most of the development offsite in a remote office in Austin, Texas. I’d fly from Austin to Washington, DC, two or three times a month to meet with the client, update them on progress, give them demos, and so on. This worked well. So well, in fact, that I found myself wondering what it was that was so different about this project? We had the usual spate of last-minute changes and unexpected technical hurdles. But my team had met every challenge without appearing to break much of a sweat. Was it the team? Was I just becoming a better leader? Or…was it that we were working off-site?

Noticing The Obvious

At the time, I didn’t draw any big conclusions from this. After all, it was just one project. Three years later, I helped launch a regional office for this same consulting shop. This involved a lot of sales. It dawned on me that salespeople routinely worked remotely, and probably had done so since the first cave went up for sale. “You won’t believe the fireplace!” Of course, this made me wonder why companies objected to software developers working remotely in the first place.

It also dawned on me that sales work was profoundly different than development work. Sales involved nearly constant social activity, whereas development required intense concentration, working either in isolation or with a small team. This helped explain my earlier experience leading a remote team. Their isolation, combined with my flying to D.C. to handle the meetings with the client, allowed them to work in a way that was the most natural for software development.

It also meant that it was possibly more important for software developers to work remotely than it was for salespeople.

Banning Meetings Makes Them Unnecessary

Still, there was no big epiphany. The years passed, and I found myself leading another team. This time, we were in the same building as the executive staff, product managers, and marketing teams. Having the learned from my past experience, I did my best to minimize interruptions. For example, I banned meetings entirely. This was an admittedly drastic measure, intended merely to make a point. I even lobbied for an off-site office for my team.

In the end, I was unsuccessful in creating an interruption-free work environment. But that failure had other, unforeseen, consequences. In particular, banning meetings forced people to communicate asynchronously, even though we were all in the same office. Initially, this took the form of a flood of emails. Little by little, emails became chat sessions, which, in turn, became tickets and wiki pages. Our development process was steadily replacing conversations and do-not-erase whiteboard sessions with a searchable record of our decisions and their rationales and end results. Our communication became more reasoned and reliable. My meeting ban had accidentally created a process in which meetings were superfluous.

If Mohammed Won’t Come To The Office, Maybe Just Let Him Work Remotely

Meanwhile, I was under pressure to hire more developers. I had a strong network of talented developers to draw from, and perhaps a half-dozen expressed an interest in joining our growing team. But convincing them to relocate was proving difficult. I convinced my boss to let me hire one remote developer as an experiment. I should add that I couldn’t have done any of this without my boss’s support throughout. He weathered a lot of unpleasant meetings with executive staff so that the rest of us could focus on building software. He prefers to remain anonymous or I’d credit him directly. And it was at this juncture that something marvelous happened.

Since our process did not depend on face-to-face communication, our lone remote developer, Matthew, Yup, that Matthew. was able to jump right in and be productive from day one. We created tickets and Matthew worked on them. We argued and discussed them with him over chat. We referred to him to wiki pages. And he added his own. I realized that we had not only eliminated meetings, but we’d created a process that made it easier to add remote workers. Not easy, mind you, just easier.

Of course, I had also picked the perfect candidate. Matthew and I had not only worked together before, but we’d collaborated remotely on open source projects. I knew Matthew was a capable developer and could work remotely. This eliminated a major variable in our experiment. Since I knew Matthew could work well remotely, the only thing I was testing was whether my team, and our process, could incorporate remote workers effectively.

And the answer was yes.

And They Lived Happily Ever After, Over IRC

From that day forward, I became convinced of two things. First, that an asynchronous process that naturally produces, and relies upon, durable artifacts was better than one that relied upon perishable communication. Second, that being willing and able to hire remote workers gave me access to a broader talent pool, which was a major strategic advantage.

Remote Work At Panda Strike

Naturally, when I started Panda Strike, I insisted on doing projects remotely, and on processes that supported remote development. This has sometimes been difficult. We’ve lost projects and even clients because they preferred working with on-site teams, usually because they believe that face-to-face communication is irreplaceable, and that, generally, developers can’t work effectively remotely.

And there’s some truth to these things. You do lose something when you can’t put everyone in a room together. And not all developers can work effectively without an office, and the accompanying structure an office environment can provide.

But…you also gain some things, too. Lots of talented developers prefer to work remotely. Lots of them work better that way. And technical decisions made in a series of written exchanges tend to be more reasoned and consistent than those made in meeting rooms, where social dynamics tend to play a greater role.

Our Upcoming Ebook

In spite of the bumps in the road, we remain advocates of remote work. And I’m excited to share the lessons we’ve learned with you. Join our mailing list and we’ll let you know when it becomes available.