Skip to main content
  1. Dev Handbook/

🌐 Going Remote: Replacing What the Office Gave You for Free

6 mins
Table of Contents

Switching from a traditional in-office job to a remote job puts your habits and skills to the test. Positive habits developed in an office setting often have negative results in a remote setting.

Things like:

  • “Just get it done”
  • “I want to see results”
  • “Can you help me sometime later today?”
  • “I’ll grab you when I can”

Each of these has been encouraged by employers as ways to get ahead and be an effective team member. But since going remote, each of these habits has gone through a systematic process to undo them. This page explains why, and what to replace them with.

“Just get it done”
#

My fictional boss Stephen comes in with his morning coffee and on his way to his office says, “I have a project I need done, meet me in my office in five minutes.” I grab my notebook and head into his office to find out more. The next thirty minutes are spent covering a new initiative that needs to be addressed by next week. If I am to do it right I know I better be thorough before stepping out of the meeting less I forget an important detail.

Starting out my career as a junior developer I yearned for the opportunity to do the “fun pet projects” that my senior peers worked on. I’d pressure my boss with a “why not me?” argument whenever the opportunity presented itself. It took me a few years to realize what made my co-workers “pet project worthy” was they “just got it done.”

Taking on this new “just get it done” stance at the office worked out great. I quickly became the go-to employee for the majority of projects. However, when I switched to a remote position, this way of working became detrimental to my career and success at the company.

The office gave you observational communication for free
#

There is a major difference between being in an office environment and a remote environment: people can see you. I know that’s obvious, but let it sink in for a minute.

The “just get it done” approach exchanges direct communication for observational communication. Instead of nagging my boss for clarifications and additional requirements, we communicated progress by observing: staying late, being the first one in, having working lunches. He knew, or more accurately he assumed, that every step of the way I was busting my ass to get the project done. He didn’t come ask me; he judged by what he saw. This observational communication built a level of trust between us that was pivotal for the whole system to work.

My boss seeing me in my seat doesn’t mean I’m going to make the deadline or that I’m not struggling. That’s not the point. The fact is, this is how it worked. He was reading my body language and used that to reaffirm his assumptions. It’s not ideal, but it’s the reality of office work.

Remote work removes all of that
#

In a remote environment, body language goes out the window. Even on video you often can’t trust it due to latency or other technical delays. All of the observational communication mechanisms that worked in-office no longer function.

But our habits still drive us to look for observational signals. If I need a status update on a project, I instinctively go check emails, chat rooms, even GitHub repos for “signs of life.” This is my virtual way of searching the office for the person who isn’t at their desk.

The fastest way to lose trustRegardless of environment, there is no faster way to lose trust in someone than when you need answers and they are nowhere to be found. In an office, at least you can see the empty chair and draw your own conclusions. Remote, there’s nothing. Silence reads as absence, and absence reads as disengagement.

Replace “just get it done” with “notify and handle it”
#

Folks working in a remote environment have a shared responsibility to each other. They must fill the void left by the lack of observational communication with written communication. This means replacing the “just get it done” approach with a “notify and handle it” approach.

The adjustment is actively communicating events as they come up and handling them accordingly.

Notify
#

By “event” I mean anything of interest, planned or unplanned, setbacks and milestones. Actively communicating these things builds trust all around. It instills confidence that nothing is being missed or falling through the cracks.

Here’s what this looks like in practice. Say I hit an unexpected infrastructure issue. Instead of going heads down and quietly solving it, I send a quick message:

Team, I ran into an unexpected issue with firewall rules on one of our web nodes that will prevent us from using web sockets safely. I’ve looked at our options and suggest we set up some boxes in a DMZ zone to bypass this issue while maintaining security of the existing servers. Please let me know if there’s any issue with this approach or if you want more detail. I’d be happy to set something up.

That took two minutes to write. It tells the team what happened, what I’m going to do about it, and gives them a window to weigh in before I start.

Handle it
#

The “just get it done” part doesn’t go away. When you’re assigned something, you still do whatever it takes to get it done. The difference is the notification step it’s paired with. After sending that message, I’d usually give it an hour before jumping on the solution, just in case I misunderstood something or someone has a better idea. Then I’m off to implement.

This isn’t an exact science. It’s understanding that when you’re remote, you must keep folks abreast of what you’re working on. Without it, people begin to wonder if you’re stuck or heading off track. These quick messages serve as a reminder that you are neither of those things.

Overcommunicate until it feels weirdWhen you first go remote, you’ll feel like you’re sharing too much. “Does anyone really care that I’m switching to a different ticket?” Yes. They do. In an office they would have seen you stand up, walk to the whiteboard, and move a sticky note. Remote, they see nothing unless you tell them. Err on the side of sharing more. You can always dial it back once the team finds its rhythm.

This is why the rest of the handbook exists
#

Every practice in this handbook is, at some level, a tool for replacing observational communication with something intentional and written:

  • Your Project Board is a Mirror because nobody can glance across the room to see what’s happening. The board has to tell that story instead.
  • Standups exist to surface blockers and alignment issues that would have been caught in hallway conversations. But they can also accidentally slow communication down if people start saving updates for the meeting instead of sharing them in real time.
  • Stories need clear acceptance criteria because you can’t lean over and ask “hey, what did you mean by this?” You need the ticket to stand on its own.
  • Done means done matters more when nobody can see the loose ends piling up on your desk.

If your team is struggling with any of these practices, it’s worth asking whether the root cause is a communication gap that the office used to fill for free.