Dan Munro - Dev-Sec-Ops Engineer   News  Archives  Recommendations

Working Remotely

A little over a year ago I took the plunge and joined a small startup working remotely as lead software engineer. I was nervous for a lot of reasons. This was my first lead position, my first job at a fully remote company. And being a startup, finances were not guaranteed. Could I handle it?

I did know a few things. The product was going to be interesting and fun to work on, while pushing me to grow and learn at the same time. There was a real demand for new features and infrastructure work. No time to ramp up. Development practices seemed forward facing, the tech stack and code modern. Not only fully distributed, the company was committed to fostering that culture both in tools and communication.

Five Lessons Learned In The First Year

It was July 2014. Finally fed up with the daily grind of commuting 3+ hours daily (thanks Seattle), I quit my job and started this adventure. Here are a few things I’ve learned along the way that have helped me adjust to this kind of work style. Hopefully these lessons can help you too.

Have A Schedule

Some distributed companies still keep core hours for various reasons. Usually it’s to help facilitate communication among team members that are geographically distributed. Or, someone made an arbitrary decision to do so and it stuck. Company culture is weird like that.

Anyway, we don’t keep core hours. Theoretically this lets each team member set a schedule that maximizes their own productivity. Practically, however, work and life have a way of leeching into each other, so that neither get the full attention they deserve. Focus is sacrificed, and eventually each side feels short-changed. Don’t do this!

Set strict boundaries for when work takes precedence, and for when life takes precedence. Boundaries can be having a dedicated office space, with “work hours”. Or telling your boss that you are unavailable after 6 PM. Next, set reasonable accommodations for exception cases (life: my kid has the flu; work: OMG production is burning). Then, communicate your plan. Tell your spouse/significant other, boss, coworkers, and dog.

I still wake up by alarm at 6 AM, every morning. Work is broken up into two main chunks, separated by a two to three hour lunch. Obviously this isn’t a one size fits all answer, experimentation is encouraged.

Track Your Progress

It’s easy to get lost in a waterfall of tasks, user stories, bug reports, etc. This is especially true in small companies. This is even more true in small, distributed companies.

Luckily I’ve never had the displeasure of having to justify my time on projects. However, it’s still a good idea to track where time gets spent. We use Github, and we track progress in the form of issues and pull requests, organized around milestones. Milestones function as sprints, and every two weeks the current one closes and the next one opens. Right now we’re on sprint 27.

A changelog gets updated with each release, highlighting PRs and issues closed since last release. Accountability is built in.

Face Time Is Valuable

If you want something done, grab someone and tell them to do it. You may need to tell them a few times.

If distributed, use video chat, and you may need to tell them a half dozen times.

Just don’t bother with chat or email.

Embrace Asynchronous Communication

Chat and email do have a purpose. These are the tools that should only be used when an answer is needed within days if at all. Think company-wide emails, press releases, automated alerts, medium and low priority tasks, and idle banter. I’ll refer to this kind of communication as low intensity communication.

Chat and email are great for low intensity communication. Know what they suck at? Accountability. Communication that is the opposite, high intensity. If something needs to get done, then chat and email are a great way to get ignored.

That being said, probably at least the majority of communication falls into the first category. Low intensity communication is important, on some scale, but also distracting in that it’s usually not relevant to the task at hand. Contain it to communication channels that don’t demand immediate attention.

Communicate, Communicate, Communicate

Like all of these points, good communication applies to any job, not just distributed ones. Aim to over communicate. Set expectations, send updates, ask questions, and report failures. Have daily video stand-ups, and weekly company meetings. Use email, chat, and text messages. Hold each other accountable. Document important decisions, and who made them. Then share that documentation. Good communication (or lack thereof) can literally mean success or failure for the entire organization.

Communication is like logging. Incident reports rarely cite too much of it.


This last year, with its ups and downs, has overall been very successful working remotely. The motivation dynamic can be much different, and I think it’s crucial to be working on an interesting problem at a company that inspires. It’s easy to lose motivation and put things off for later. Instead, keeping a schedule, communicating goals, and knowing the people who rely on you are great ways to stay on track and get stuff done.

There are incredible benefits to remote life. I became a dad in April, and having the flexibility to be with the little one during the day is very valuable. Mom gets a break and I get some bonding time. It’s not enough time, but I’ll take what I can get.

Thanks I hope you enjoyed reading!

Written on Sep 1, 2015.