Every time I see a “the future of work is remote” article, I think to myself: “How backwards! How retro! How quaint!” That future is now, for many of us. I’ve been a fully remote developer-turned-CTO for a full decade. So I’m always baffled by people still wrestling with whether remote work is viable for their company. That jury rendered its verdict a long time ago.
One reason companies still struggle with it is that remote work amplifies the negative effects of bad practices. If everyone’s in one place, you can dither, handwave, vacillate, micromanage, and turn your workplace into an endless wasteland of unclear uncertainty, punctuated by ad-hoc last-second crisis meetings — and your employees will probably still conspire against your counterproduction to get something done, albeit much less than what they’re capable of.
If they’re remote, though, progress via conspiracy and adhocracy is no longer an option. If they’re remote, you need decisive confidence, clear direction, iterative targets, independent responsibilities, asynchronous communications, and cheerful chatter. Let me go over each of those:
Decisive confidence. Suppose Vivek in Delhi, Diego in Rio, and Miles in Berlin are all on a project. (An example I’m drawing from my real life.) It’s late your time. You have to make a decision about the direction of their work. If you sleep on it, you’re writing off multiple developer-days of productivity.
Sometimes they have enough responsibilities to have other things to work on. (More on that below.) Sometimes you don’t have to make the decision because they have enough responsibility to do so themselves. (More on that below.) But sometimes you have to make the business-level decision based on scant information. In cases like this, remember the military maxim: “Any decision is better than no decision.”
Fortunately, because you run things well, the decisions you make will always be informed by a –
Clear direction. You, and your engineers, always need to know what the overall vision you’re striving for looks like. Engineers make a thousand tiny decisions: how to handle connection failures? What kind of errors to pass up to the UX layer, in what detail? How to partition components for intuitive understanding, and maybe even re-use, by the next developer? And you too of course make decisions along the way. Is this a one-screen form, or a wizard? How does the app work, if at all, without connectivity?
In order to deal with all the myriad decisions made en route to product development, you need a clear vision of where these decisions are meant to take you. What’s more, it needs to be clearly articulated, ideally in a (possibly quiet brief!) prose document that everyone can refer to. If everyone knows their ultimate trajectory, they won’t need constant directional corrections.
Instead, they can focus on their –
Iterative targets. From time to time, Engineer A will be blocked because they are waiting on Engineer B. That’s OK! …as long as Engineer A has something else meaningful to work on. This is easiest if at any given moment there are several things to iterate on, and meaningful progress can be made in the space of a day or two.
Of course, every project has its own shape. If you’re building from scratch, it may make sense to make every engineer “primary” on one facet of the project and “secondary” on one or two others, so you spread knowledge around, and an engineer blocked on their primary responsibility can switch seamlessly to working from a secondary.
Maybe more tests could be written, or the test harness overhauled, or the CI pipeline streamlined, or your Docker images optimized. If you’re patching up an existing codebase, maybe it’s as simple as pulling tickets from the backlog. Regardless, a single obstacle can’t block an individual engineer.
Image via Getty Images / Ja_inter
But at the same time, you need to foster –
Independent responsibilities. In some ways, this almost goes without saying. If an engineer is working remotely, they’re probably not pair programming. They may not be the official technical architect, but within the bounds set by the person who is, they’ll be designing and building their own subsystems themselves. You need to trust them to generally do that well.
Note: generally. It’s always good to have extra eyes on code, especially early code, whether that be from the architect browsing checkin diffs or from another engineer who’s “secondary” on their code making suggestions. But you have to trust them to respond positively to constructive criticism, and to do better next time, and to take responsibility for their work in the end.
Even remote, though, no engineer is an island, nor should they be. You need to forge a team out of them, via –
Asynchronous communication. I’ve written about this before. It’s important to have times when your whole team talks to one another, stand-ups or confabs or whatever you want to call them; but, especially when some of the team is remote and some is not, in general, your communications need to be asynchronous-first.
If you’re not currently in the midst of a conversation, aka a synchronous session, always send an email, or add a question on Slack, in the expectation that it may be some time before you get a response.
This changes everything. This means you always need to be thinking a little bit ahead, rather than responding in a panic. This means you always need to have contingencies in mind. This means your approach to the project needs to be, consistently, confidently proactive rather than anxiously reactive. But you’ll note that none of these are bad things. On the contrary; remote work disproportionately rewards good practices, and punishes bad ones.
Image via Getty Images / alashi
But even if your approach is poised, positive and prepared, communication can’t only be stand-ups and strictly business. To really gel, to make people work well together, requires –
Cheerful chatter. This is as true remotely as in-person. Your team will work better if it is a team, with a shared background that extends beyond the strict demands of the workplace, with a more instinctive understanding of one another, and a natural urge to help and support each other. And both you and they will have a better time.
So crack jokes, post interesting tidbits, talk about the latest Marvel movies (but no spoilers until they’re streamable!), compare and contrast Liu Cixin with NK Jemisin, etc etc etc. No dev is an island; no engineer is a machine. They may only be faces on your Google Meet, and words in your Slack channel, but at the same time they remain your siblings in arms against entropy.