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:

• Frequent clear communication
• Team cohesion and rapport

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

• Always overcommunicate. You can't actually achieve this, so trying to get there is a good way to ensure that lines of communication stay open and everyone knows what you're working on, how you're doing, what you're struggling with, etc. and views you as more than a couple of comments on a GitHub issue.
• Let people know when you're in or out. There's a tendency for colocated people to have no idea when remote people are on or off, because they can't see you, which leads to assuming that you're either always reachable or always unreachable (frustrating either way). Saying when you come online or are leaving for the day helps set expectations and establish a rhythm, just like when you see your buddies at the coffeepot in the office in the morning, and walking out at 6pm. Similarly, say when you step out for a moment to go for a walk or head to the coffeeshop, as well.
• Ensure that you are reachable for emergencies. This usually just means: put your SMS number in your Slack profile so that if we need to find you, we can. Details vary by company. If there isn't a good way to discover your coworkers' contact info, suggest a system for it (can be as simple as a spreadsheet of phone numbers and timezones).
• Uninstall Slack from your phone. I'll wait, do it right now. Get rid of email while you're at it. The reason for this: as a remote worker, boundaries between work and life are already blurred, so it takes extra intention and effort to actually establish separation between work and life, which will boost your productivity and make you happier.
• Practice clear and concise written English. We're programmers, and a lot of us were probably (unfortunately) in that group that made fun of English majors. Turns out, though, writing well is really damn important and it benefits everyone to run a spellchecker, proofread for grammar, and make sure your messages/emails are well-written and structured logically. It only takes a few minutes to do this, and it will save you and your coworkers a lot of time by making things clear the first time, instead of requiring a back-and-forth. Also, try to write with more formal English, not how you text your friends: it will be clearer to more people, and it will project more professionalism.
• (Controversial) Use tons of emoji 😁. It's hard to tell someone's tone without body language. Emoji can help convey tone and at least make it clear if you intend something to be funny or not.
• Schedule unstructured time with coworkers. You know those water cooler conversations you have in a real office? You know how you bond over lunch? We don't have that, so you have to put in deliberate effort to construct those same interactions. I've scheduled a bunch of biweekly touchbase meetings with my peers and have gotten a lot of value out of them (including a discussion which led directly to me writing this blog post). These meetings spark interactions which wouldn't happen otherwise, and they're valuable precisely because they have no plan and no agenda. I suggest scheduling these with the people you work closely with, those you do similar work to but aren't close with, and other people across your organization. I also have been loving our coffee buddy app which pairs random people every two weeks; now I've talked to a lot of people on the business side of the organization and gotten unique insights into our product.
• Talk about personal things with coworkers. It's important to develop bonds with your coworkers. I had no idea that my coworker Dan is as into coffee as I am until it came up in conversation in our NYC headquarters, but now we have something to break the ice and chit-chat about, leading to higher team cohesion, happiness, and productivity.
• Schedule deep work time. One of the key benefits of remote work is the ability to easily enter into deep work. However, when you do this, manage expectations and let your coworkers know through your Slack status, calendar events, etc. that you are doing deep work and are not reachable. This manages expectations and leads to less frustration from them because it's clear why you're not responding, and less frustration for you because they're less likely to keep pushing to punch through and notify you.
• Use calls whenever it makes sense. Even though a lot of remote work is asynchronous, a phone call is often the most efficient way to quickly hash something out and unblock someone. It's less frustrating to talk for 5 minutes than to have 20 emails back and forth. Don't call someone if they're in deep work mode, but if you're actively chatting with someone, consider if a call would be better than using text.

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.

• Don't treat colocated as the default. Even if your team is 90% colocated and 10% remote, if you refer to colocated engineers as "the engineers" and the remote engineers as "the remote engineers", then you are other-ing the remote team members. It is helpful to simply acknowledge that these are two categories of your employees, and make neither the default in your language.
• Default to text first. If you're discussing something and you can do it via Slack or email, do it via Slack or email. That way everyone can participate, not just other colocated engineers.
• Let other people know when you're in or out. Just like you can't see when remote people sign on, it's super helpful to say on Slack when you arrive in the morning, are going out for a coffee, or are heading home for the evening, so that remote people know if you're reachable or not.
• Ensure that you are reachable for emergencies. Exactly the same as above.
• Practice clear and conscise written English. Exactly the same as above.
• For one-off meetings, mention them on Slack. Your colocated coworkers can overhear an interesting meeting and chime in, but your remote coworkers cannot. So if you mention something like "Hey, I'm talking with @AwesomeEngineer about CoolTopic right now," then people can respond with "Oh hey, I had thoughts on that, can you loop me in?" or "That sounds interesting, mind if I eavesdrop?" This will lead to more insights and more knowledge transfer among the team.
• In meetings, use raised hands or a passed object to get input. If you rely on body language to determine who speaks next in a conversation, colocated coworkers will dominate the conversation because remote workers cannot express much body language on a call (and the call's speakers are usually quieter than a colocated person can be). If you rely on raising hands or passing an object to pass the metaphorical mic, it is much easier to see if a remote person has something to add and loop them in.

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.

• Set a standard schedule. Yes, you'll deviate sometimes, but having a standard schedule achieves two things: it gives predictability/reliability to those on your team if they need to reach you; and it makes it so that you can rest and recharge when you're outside of work. Remote engineers don't have as strong of a physical separation between work and home, so a temporal separation is very helpful.
• Maintain a physical separation. It's very hard to dissociate work from the place where you work, so set aside some of your space for just work and don't do anything there unless you're working. This also makes resting and recharging easier when you're offline. I'm fortunate to have a separate room of my house which is my office and is used just for work, but this space could be as simple as a desk in your living room that's used for work and only for work.
• Visit colocated engineers occasionally. It's important to get this face-time, especially with new team members who you have had less interaction with and with junior team members who benefit from more mentoring. And make sure you communicate your travel plans loudly and often so that everyone is aware of where you're going to be and when you will be there.
• Make a daily agenda. I write out all my priorities for the day and then try to fill my day (approximately 9 AM to 6 PM) in 30-minute chunks with what I am doing and when I am doing it. I rarely stick strictly to this schedule, and I believe the core benefit is going through the daily exercise of prioritization and estimating how much I can actually achieve; it keeps excess optimism in check. (If I don't do this, I tend to work longer hours and still get less done, because I feel overwhelmed and pressured.)

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.