How I Work Remotely

Saturday, June 2, 2018

I've been working remote since September 2016. There are a lot of engineers who have worked remote longer than I have; there are others who have more insight into how they work than I do; and there are plenty of people who simply don't work in the same way I do. My intention in this post is to share how I work, the reasons why I work that way, and what I think others should try while finding the process that works best for them and their teams.

Remote Work, Round 1

In September 2016, I joined a team as a remote engineer for the first time. I had just recently left a full-time traditional software engineering job to pursue my own company: I was splitting my time between 50% contract work / consulting and 50% personal projects with the goal of creating a startup. (I managed that, and co-founded a startup non-profit which aims to make the barrier for immigration whether you qualify, not whether you can navigate bureaucracy.)

This was a learning experience for me in more ways than I was prepared for. This year of independence taught be a lot about time management, prioritization, the sheer difficulty of starting and running a business (let alone two at the same time). It also taught me a lot about how to work effectively. I'm going to focus on that: the mistakes I made and lessons I learned which increased my productivity and happiness as an engineer.

In many ways, it's easier to identify what not to do, rather than what to do, so I'll start there.

My first real remote-work experience was as the solitary remote engineer on an otherwise colocated team. I put my head down and focused on pure productivity, ignoring personal interactions. This worked well in some respects, because the code I wrote was really good code and achieved its purpose. However, it failed to recognize one important aspect of that work: yes, I was a remote engineer... on a team. I never built cohesion with the rest of the team, which led to some suboptimal outcomes.

I also communicated at a level I thought was appropriate, and avoided over-communicating. What I have found since then is that it is almost impossible to over-communicate (I would say that it is impossible, but I tend to avoid absolutes). More on over-communication later; for now, suffice to say that a lack of communication leads to decreased visibility, clarity, and rapport.

For another client, our project ended up having a mismatch between delivery and expectations for one team member. We expected a certain outcome, he expected a different outcome, and at the end of the day, the stakeholders were unhappy with what we delivered. This, too, was a result of not checking in with the team and building a rapport. If we had had more frequent check-ins as a team and had more rapport built-up, then it would have been much easier to both detect the problem and to course-correct for it.

A lot of these mistakes can be boiled down to highlight what it is important to value:

My observation is that engineers tend to be singularly focused on shipping and less focused on the other aspects, so deliberate attention toward these helps avoid these kinds of mistakes. A team of remote engineers is still a team, and the team aspects of the problems will not be solved unless you, dear reader, approach them with intention.

Leveling Up

In July 2017, I joined Remesh as the third engineer, and the first remote employee. I knew I had to approach remote work with more intention to win the trust of the team--not just to protect myself and my job, but also to avoid giving a negative impression of remote work in general. Since then, we've hired more remote engineers and I'm still employed (🤞), so I would say it has gone well!

In spite of the mistakes I made in remote work previously, I was still an effective engineer. With this new job, I wanted to make sure I was not just effective, but could set others up for success as well, as the team grew. To learn more and refine my approach, I read Cal Newport's book Deep Work, Julia Evans' excellent remote work blog post, and countless posts on StackOverflow, Reddit, and HackerNews about how to do this effectively. I ended up with an approach that works very well for me and which may be useful for others.

What I have found is that the most important thing to work on as a remote engineer is communication, and your working style is also key to your individual and team success.

Communication

Communication is where a lot of teams break down, especially teams which are a hybrid of remote and colocated engineers (one of the most challenging team architectures, in my opinion). Communication takes active effort to learn and is certainly not taught in computer science curriculums, which is part of why you primarily see senior engineers working remote: junior engineers need more active, personal, face-to-face interaction to develop their craft. It is doable if you put some effort and intention into it, and here are some maxims which I've found work well.

Maxims for the Remote Engineer

Maxims for the Colocated Engineer

If you're on a team with remote engineers, it is helpful to intentionally work to enable their inclusion. Here are some maxims which I've found are helpful to follow to include your entire team, not just your colocated team.

These maxims are what I've found to work for me, and are not universal laws. If you have something else you think should be included (or something which shouldn't be), email me@ntietz.com and I'd love to have a conversation about it!

Working Style

Everyone has a different working style: morning people who get up early (hi), night owls who work late, some people work super long hours, some of us have strong work-life boundaries. Here is how I've set up my working style. I think these transfer well to colocated practices, as well, and I'd encourage trying them out.

Conclusion

If you take away nothing else, take away this: approach your working style and your communication style with intention and iterate on it until you've found something that works well for your team and yourself. I've found an approach here which I think is very good and works really well for me and our team, but there is no one-size-fits-all solution.

If you have thoughts on this, or want to talk more about your organization's approach to remote work, feel free to reach out to me@ntietz.com, or on Twitter (@NicholasTietz).


If this post was enjoyable or useful for you, please share it! If you have comments, questions, or feedback, you can email my personal email. To get new posts, subscribe to the newsletter or use the RSS feed.

Want to become a better programmer? Join the Recurse Center!