Efficient Remote Work For Tech Teams - by James Stanier

8/10/22, 10:05 PM Efficient Remote Work for Tech Teams - by James Stanier
Efficient Remote Work for Tech

Teams
Remote work is here to stay. What are some practices which
managers and team leads can introduce to promote healthy and
efficient remote teams?
James Stanier
Writes The Engineering Manager · Subscribe
Aug 9
Q: Help! I'm a tech lead and my whole team is remote.

What are practices I can introduce to help us work
more efficiently?
Since the pandemic made remote work far more common, I’ve received several
questions like this. Another common one is; “I didn’t sign up to manage a remote
team! What should I do?”
I turned to James Stanier whom I’ve known since he released his excellent book
Become an Effective Software Engineering Manager, which I reviewed and
recommend. James is the Director of Engineering at Shopify, a fully remote company.
He’s been working remote for 4 years, leading engineering teams of varying sizes
throughout. He recently released his latest book, Effective Remote Work and I could
think of few better people to give quality practical advice on remote work, than
James.
This article aims to inspire you with some tools for your team’s toolbox, as we
transform the biggest remote working experiment in history into – dare I say it – a
‘new normal.’
In this issue, James covers:
1. Everything and nothing has changed since the pandemic.
2. Treating everyone as remote.
3. Setting team norms.
https://newsletter.pragmaticengineer.com/p/efficient-remote-work 1/18
4. The spectrum of synchronousness.
5. Practical tips for remote collaboration.
Over to James:
1. Everything and nothing has changed

I’m writing these words as I sit on a train, trying not to get distracted by the beautiful
countryside passing by my window. I’m heading down to London for a few days to
attend a conference and some satellite meetups we’ve arranged around it.
To catch the train, I drove about 40 minutes to Carlisle station, located in northern
England close to the Scottish border. Sometimes, you can’t trust the estimates of
mapping applications here because you can get stuck behind a slow tractor that’s too
wide to overtake. Hey; that’s life up here. By the time I reach London Euston station,
I’ll be about 320 miles from home. If you add another 50 miles or so to that total,
you’ll get the distance which my family relocated two years ago, in order to
completely change our lives.
The pandemic was the tipping point which made us truly see time wasn’t slowing
down. Our parents weren’t getting any younger, and each opportunity to see them
became more precious. I had a glimpse of a radically different future that didn’t
involve commuting on trains like the one I sat on every single working day of the
week. This possibility turned into a reality quite unexpectedly, and we took a big leap.
But now we’ve settled, we have daily views of the coast and the Fells, and most
importantly, the ability to be close to those who mean most to us.
We don’t regret a single thing.
After all, remote work is just work. It doesn’t matter where you are. It’s what you’re
able to do during the time when you’re not working that’s the most important choice
you can make. This is the shift many of us have experienced during the past few
years: why haven’t we taken relocation for quality of life, as seriously as relocation for
work?
I know I’m not alone. As an industry, individuals and workplaces are now navigating a
new world where what has been granted – albeit reluctantly – can’t be taken back.
Technology workers expect more flexibility and choice over how, when and where
they work, and companies which cannot or will not adapt face attrition. Feet are
casting votes, and fast.
We often talk of the ‘sunk cost fallacy’ as engineers – where we continue behaviours
as a result of prior investment. It can arise during debates around refactoring or
rewriting software. Companies are now facing their own sunk cost fallacy dilemma:
many which spent significant amounts of money on office renovations, leases, and
even purchases, may be tempted to pull technology workers back, in order to make
that spend seem worthwhile. However, even those with the most impressive offices –
and engineers – in the world, have found it hard to convince them to do so. For
example, Apple – for years having the position that returning to work in its
headquarters is mandatory, not optional – has recently admitted its remote policy
could change.
We have to unlearn decades of habitual behaviour from location-centric office

work and embrace a remote or hybrid future. With the engineers in our industry
making it clear where they want to work, we all face new challenges as leaders, peers
and programmers. The tricky part is it all feels so familiar, but it is simultaneously
fundamentally different. We all do most of our work on computers via the internet,
and the tools we use to work remotely are fundamentally the same as we used in the
office. But the way we use them – and the intentionality of their use – is the key step-
change.
Just as I’m sitting here on a train like I’ve done countless times during my life, and
even though my destination is similar to before – and the WiFi is just as bad – the
choice and reasoning behind my journey is nothing like it was in the past.
2. Treating everyone as remote

So, let’s start answering the question of how we can work better together, regardless
of where we are. The first answer is surprisingly simple. It’s just a few words.
We should treat everyone as remote.
That’s it. It really is that simple, and it doesn’t cost anything. It’s a mindset shift. But
here’s the catch; it isn’t at all straightforward to implement consistently because it
involves the unlearning of countless habits we acquired over the course of decades of
working in offices together. Achieving this goal involves tens, if not hundreds, of tiny
habit shifts and holding each other accountable. We’ll list some actionable ways to
unwind these old habits shortly. But you might be thinking: “which habits?” Well,
perhaps I can jog your memory…
Before the pandemic, those of us who worked in offices and occasionally took a day
to work from home, experienced the full effect of what happened when this rule
wasn’t followed.
In the morning, we sat at our computers wondering why colleagues were not joining
the video call, only to find the team had forgotten to dial in from the meeting room.
Later in the morning, we remembered the architecture diagram which we were
working on was drawn on a physical whiteboard next to the team, prompting us to
ask one of them to kindly take a blurry photograph of it and send it over.
In the afternoon, while programming, we got frustrated because our two 27-inch
monitors we usually have at our desk had been replaced for the day by a 15-inch
laptop screen that can barely contain the code, let alone the server logs, telemetry
and the debugger. When the weekly team meeting involved dialling into a room of
people sitting round a table, distant from the camera and microphone and therefore
barely audible, we probably wished we’d just taken the day off, instead.
During the pandemic, many of us were forced to be remote at the same time,
thereby levelling the interfaces we all experienced with one another. None of us had
the physical structure of the office; the whiteboards, meeting rooms, communal
kitchens, which implicitly dictate how we interact. So instead, we all adapted and the
experience of being remote – global health crisis aside – was possibly better than any
of us had previously experienced.
As we begin to look forward towards a world that includes more remote and hybrid
working, we’ve never needed our motto about treating everyone as remote more
than we do right now. If we neglect it, we may slip back into our old ways of
interacting, creating physical and remote silos partitioned by the different means in
which both groups typically interact.
So what practical actions can we take to treat everyone as remote? Here’s some ideas
to get you started. Remember, the key point is the way in which you collaborate
should allow the same cultural experience, the same access to information and
people, and the same ability to work efficiently, regardless of where you happen to
be.
All meetings happen on video call with individuals dialling in. Even if
most participants are in the same room, everyone should dial in with their
own webcam and microphone. This makes the interface of the meeting
identical for those not in the same room, and ensures everyone can see and
hear the same things.
No physical artefacts are allowed; only digital. Collaborative drawing
software has matured to the point where it is more featureful and interactive
than any physical whiteboard. And most importantly, remote attendees don’t
need to view the diagrams through somebody’s webcam in the office during
a meeting. There’s no excuse for a whiteboard diagram being a canonical
source of truth anymore; a collaborative diagram is editable, copyable,
archival and able to support comments and suggestions.
The collective mind of a team must be captured in accessible
documentation. In order to be inclusive to everyone, we must provide the
same interface to knowledge, and this needs to work asynchronously.
Therefore, documentation has never been more important for capturing the
collective knowledge of a team. Correct use of READMEs, wikis, videos and
written documents capture past decisions and form a frontier of the new
work.
Essential information must be purposefully broadcasted to the whole

team. It becomes the responsibility of everyone on the team to identify when
there is information everyone should hear, and then to ensure that it can be.
This typically involves taking information “up a level”, i.e. turning a DM into a
summary in the team chat, or taking the contents of a meeting and
summarising it to a wider group than the original participants.
All collaborative benefits of being in the office must have remote

analogs. Fundamentally, the office used space to curate interactions
implicitly; the kitchen served as a place for informal information exchange,
and meeting rooms provided whiteboards for expressing diagrams and
thought processes. Treating everyone as remote involves identifying all of
these office interactions and providing digital equivalents, such as social chat
channels, sufficient collaborative tooling, and for flexible time to be social as
well as for working.
The best way to ensure your team, department or company treats everyone as
remote is for the leadership to be remote for all or most of the time. By putting those
who have the most power to enact change in this position, the sooner the culture will
improve. Companies which offer remote work, yet have their leadership working full
time out of an office, have no skin in the game for making things better for everyone.
I would bet you that companies with fully remote leaderships have the best stipends
and perks for working from home, and the most progressive policies.
So that’s the first answer to the question of what you can do to make remote working
better for your team and everyone you interact with: treat everyone as remote. It’s
simple, but not straightforward.
This makes for an interesting exercise with your team: if you were to imagine living by
this motto right now, would you find the habits and practices you currently work
with, help you or hinder you? What would you change right now? Which changes
might be harder, requiring budget or buy-in from leadership?
I reckon you’ll be able to do a lot more than you think without needing any approval.
Bring it up as a discussion and see where it goes.
3. Setting team norms

Now let’s take this a little further. In order to work better as a remote team, it’s
important to make it absolutely clear how you communicate with each other. This
further builds on the idea that offices have implicitly shaped the way we work without
needing to show much intentionality: it’s obvious when we’re contactable because
we’re right there, and it’s clear when we’re busy because we’re in focus mode. We can
see when people go to lunch, and when they go home.
However, in order to be effective remotely we need to intentionally restore these

indicators of how and when we communicate with each other in a way that lets us
reap the benefits of the flexibility of remote work, without dialling up FOMO and
anxiety to the point where we habitually refresh our messages every 10 minutes, just
in case we’ve missed something.
You can do this by running an exercise as a team, in which you set your norms
together. This makes what is expected of communication within a team completely
clear, and the resulting norms can be documented for future reference.
The number of ways in which we communicate with each other daily can be
numerous: email, chat, audio calls, video calls, pull requests, and more. Each platform
has nuances and expectations which vary by individual interpretation. Which should
be used and when? Do particular situations warrant a particular choice of platform? Is
it okay to only check email once per day?
Within your team, you should aim to make the following clear:
The specific software tools used to communicate and whether they

should be actively monitored. Is the team chat something that should be
read hourly, or is it only important if people are specifically notified? Is all
email expected to be read by all?
The expected response times per platform. You should list all of the
different tools you use as a team and make clear with what regularity people
are expected to reply. For example, there may be an expectation that emails
are answered within 24 hours and that DMs should be turned around within 2
working hours. What is right is something your team should define; there is
no universal correct answer. Knowing response time expectations dramatically
decreases anxiety and allows staff to stop checking messages out of hours,
unless it’s urgent.
Which tools should be used for particular situations. More formal and
archival communications may be expected to be broadcast via email.
However, day-to-day interactions may be expected to take place in the team
chat room. You can also agree on what to do when something is urgent. For
example, we use SMS as our “drop everything” form of contact. If you’re out-
of-hours and haven’t gotten an SMS, you know there’s nothing to check in on.
If one comes in, it’s definitely important. The choice of format determines the
required reaction.
The level of formality expected. Chat is usually more informal than email,
but what does your team expect in terms of the quality of written
communication? Using everyday interactions as a medium to practice good
writing can make crafting those company-wide emails much easier, if they’re
written in the same way as your daily chats.
Establishing norms may feel like a chore, but there are big benefits. It makes it easier,
more predictable, and less stressful to communicate.
You can run a session on establishing norms with your team. Perhaps take an hour to
list all the ways in which you communicate, whether they should be actively
monitored, the expected response time per platform, and any other criteria you
deem important. This should result in a table like the one below, which you can
include in your team’s documentation.
An example output of agreeing on communications norms within a team.

Create one for your own team.
4. The spectrum of synchronousness

When establishing norms, we need to be mindful of the different effects different
types of communication can have in terms of their effectiveness, their ability to create
records and documentation, and also in how they make us feel personally. For
example, your team may decide the norm is to be predominantly synchronous during
the day – which is entirely reasonable – however, the side effect may be that little
documentation is produced. Similarly, a team which wishes to be predominantly
asynchronous may find that, over time, it feels like bonds between members haven't
had time to develop, and hey; sometimes it can be a bit lonely when you only
communicate via written messages.
What we really need to understand our communication better is a model, so we can

make more informed choices about the time, location and format we use, based on
exactly what we’re trying to communicate. This sounds complicated, but it can be
expressed in a fairly straightforward way.
Check out the diagram below, which plots different methods of communication
along three different spectrums on the same axis:
The synchronousness of different methods of communication.
We can see on this diagram the subtle interplay between different methods of
communication; from synchronous video calls and pair programming, all the way
through to asynchronous wiki pages, and the effect it has on the permanence of
created artefacts and whether or not it helps people feel connected to one another.
Predominantly asynchronous communication can deprive people of essential

human interactions which are required to build rapport and trust. This is where
your team needs to think carefully. It is certain that being predominantly
asynchronous is the greatest leveller for teams who happen to be globally
distributed. However, video calls are fantastic for exchanging complex and nuanced
information quickly, and for developing and sharing ideas together. But within that
synchronous moment there is no documentation being created for colleagues not in
the exchange.
Fundamentally, there is no right or wrong answer for you and your team. However,
the model is useful for remembering there are tensions at play in whatever method
of communication you use, and you may need to choose against being fast, in order
to ensure that documentation is produced for the entire team. Otherwise, you may
need to be more synchronous than you’d like to be, in order to give staff the space to
interact and build rapport together, or to ensure less experienced colleagues get the
facetime and mentorship they need.
Yes, it may be the case that everything needed for getting work done is documented,
but often pairing up with someone on a task is simply more fun and rewarding and
also helps strengthen connections within the team.
For example, I’ve noticed my teams at Shopify have replaced stand-up meetings with
automated asynchronous written check-ins. However – as per Shopify culture – our
engineers pair program far, far more than they did at previous jobs, since it helps
spread knowledge, write better code, and includes social time as part of what would
typically be individual, isolated work.
Do think about the level of asynchronousness when you are establishing your
norms as a team. Using the diagram, what might be suffering as a result of how
you are choosing to work? Could it be that insufficient permanent documentation is
being created? Might it be that staff aren’t getting a chance to get to know each
other personally? You should identify these areas and ensure you’re purposefully
pushing in the opposite direction along the spectrum from time to time, in order to
redress the balance.
5. Practical tips for remote

collaboration
So, what are some key learnings you can take away right now in order to make
remote collaboration work better in your team? Here’s a number of things I have
seen work well in my own teams and at Shopify, as a whole.
Use a structured onboarding program

We all know onboarding remotely is hard. So devoting time and attention into
creating a smooth onboarding process is key. Your company should think about
onboarding in three phases, and ensure you have the processes in place for each of
them:
Onboarding that is relevant to every single new employee, regardless of

their role. This covers learning about the company, the products, the market,
the mission and values, and understanding what users like and dislike, via
answering support tickets. At larger companies, this onboarding program
could be facilitated and run in cohorts of new starters who can get to know
each other as they progress through the program; thereby forming peer
groups as a neat side effect.
Onboarding that is specific to a given craft. Once the general onboarding

program has been completed, it’s time to go down a level of abstraction and
focus on the shared knowledge within a given craft: e.g. engineering, sales,
marketing, etc. This is knowledge that isn’t specific to a particular team. It
could cover how the department ships to production, or how to set up a dev
environment. This can also be facilitated in cohorts who can work together on
small exercises, such as shipping a change to production via a toy codebase
that’s configured and deployed exactly how the mainline codebases are.
Onboarding that is specific to the new starter’s team. Once the craft-level
onboarding is done, new staff can phase into their new team, which will cover
the specific product or service they own. At Shopify, we heavily encourage
engineers to pair remotely on problems, in order to share context and ramp
up new staff. We’ll cover this next.
The structure of the onboarding program at Shopify.
In order to set new staff up to succeed in a remote environment, we need to have

structure and focus around our onboarding program. Being remote as well as being
new can be a huge trigger of impostor syndrome, so we need to make sure new staff
feel welcome, psychologically safe, and able to take the time to learn and ramp up. At
Shopify, we explicitly tell new starters that their first 3 months are a special time in
which we expect ramping up to be the main priority, including taking the time to
learn any new languages or frameworks they’ll be using in their roles.
Pairing everywhere
Pair programming is even better when remote. There, I said it. At Shopify, we are
huge advocates of Tuple, which is by far the best pair programming application out
there. Pairing is part of our culture, and has been since the very beginning of the
company. Pair programming often results in higher quality code, and even in less
code being needed to solve problems.
As well as being ideal for onboarding new members of staff, we have Slack channels
set up for folks to matchmake with pairing buddies in different teams and divisions,
since it’s fun to meet new people and also to gain different perspectives and context
while working together.
Pairing doesn’t have to be limited to just writing code. We’ve experimented with
pair writing for documents and documentation using Tuple, to similar success. Most
importantly, it injects some of those human connections into our work which make us
feel supported and united.
A centralised system of truth

A key part of treating everyone as remote is having the same interface into company
information for every member of staff, regardless of their role and location. This is
why it’s important you both provide a centralised system of truth for company
information, and make it so that everyone is able to edit and contribute.
Information easily gets lost on email, Slack, and even team-specific documentation
systems, so it’s vital for companies to ensure their staff are always kept up to date.
One way of doing this is to use one source of documentation that is the system of
truth for everything going on inside the company.
Shopify’s internal wiki is called the Vault, which provides everyone with access to the
company newsfeed, ability to stream and rewatch all-hands meetings, the ability to
curate their profile page and browse the org chart, get updates on projects and
initiatives, and much more. Documenting our decisions, progress and keeping the
Vault up to date is a key part of our culture.
A small wiki can be a good place to start. Just how many frequently asked
questions could you document which would save people from answering the same
questions over and over on Slack?
Decision logs and audit trails

Further to a centralised system of truth, how hard is it for your staff to understand
why particular decisions are being made in your codebases and in your architecture
as a whole?
You can try experimenting with Architectural Decision Records as part of your team’s
processes. Additionally, I would highly recommend moving processes such as
technical design reviews, into an archival place. For example, you can experiment with
teams writing Requests For Comments for designs in the same way that the IETF
(Internet Engineering Task Force) does, and raising them as pull requests so anyone
can read and comment on them. Additionally, actions taken are always archived in
GitHub, providing an audit trail showing what was happening in the company at a
specific time, which resulted in a particular course being chosen.
Form mostly synchronous teams with

asynchronous borders
Going remote requires a little more organisation than just everyone not being in an
office. Being completely asynchronous is extremely hard and definitely is not ideal for
many people. Whole organisations can be global and distributed, but we still need to
design our organisations so people can work in teams which allow plenty of
synchronous interaction.
Have teams with a significant time zone overlap within them, as a good rule of
thumb. For example, European teams can be composed of staff in the UK, France,
Germany and Spain, while US East Coast teams can cover cities such as New York,
Toronto and Montreal.
Managers can typically be more asynchronous than individual contributors, so they

become essential for ensuring connectivity across divisions and the department.
Organisations should be designed with care to ensure teams have clear ownership,
which in turn leads to autonomy.
When expanding globally, ensure a plan is in place to gradually grow teams in

locations. This can begin with mirroring context from other parts of the organisation.
We’ve had great success with hiring experienced engineers (Staff+) who can handle
being more asynchronous initially, as they learn crucial context from another time
zone and then help ramp up less experienced staff as they join.
Fun needs more intentionality

It’s hard to replicate that 4pm phenomenon in the office on a Friday, when people
naturally begin to wind down ahead of the weekend. Remote fun requires more
intentionality, which like the observer effect in quantum mechanics, can completely
change the experience of it. During the pandemic, I’m sure you went on enough
video call quizzes to never want to do another one, ever again.
However, the games and tools available to us are getting better. There are plenty of
free, fun games you can play like Gartic Phone, GeoGuessr, Skribbl, Type Racer and
thousands of board games on Board Game Arena. However, sometimes you want to
be able to blend fun and work; is it possible to hang out together and do a group
meeting while being off-camera? That’s why we created Shopify Party, a browser-
based internal tool which makes virtual hangouts more fun.
It allows staff to create virtual avatars and hang out together, with the added ability
of easily exploring the world and playing games. It allows teams to easily inject a bit
of fun into their regular get-togethers, and you can end the meeting with a race or a
Takeshi’s Castle-style gauntlet – the 1980s’ Japanese TV show; think of the video
game ‘Fall Guys,’ but in real life.
IRL is still important

My final tip is that regardless of how well your team works remotely, you can’t beat
meeting in real life to truly understand the people behind the usernames and avatars.
When working with people digitally, our mental model of who that person really is,
can become skewed by our own interpretations of others’ interactions, so it’s
important to regularly reset these mental models by enabling real human connection.
At Shopify, we give a name to teams getting together IRL; we call them “Bursts.” We
have a number of locations around the world which are easy for teams to book time
in, since they provide easy access to accommodation, food, coworking spaces and
activities. They consist of our repurposed offices and a number of partner venues and
hotels. When teams book these locations, they know pretty much everything is
organised for them, allowing them to just turn up, get things done and enjoy some
downtime together.
A few times a year seems like a sweet spot for the frequency of team get-
togethers, though we’re still settling into a regular cadence. Some things that
trigger a get-together include planning major milestones, beginning brand new
roadmaps and product directions, the forming or significant expansion of teams, and
taking part in training and workshops.
As teams have been meeting together more in 2022, Shopify has been providing
“Bursts in a box,” which make it easier for teams to focus on getting things done,
rather than organising activities. Some templates include workshops and slides for
design sprints, product roadmap ideation and training on giving feedback and
performance management. The more Bursts take place, the more we can encapsulate
what worked and then turn them into reusable experiences for other teams.
Takeaways
Gergely here. Thanks very much, James, for sharing all this insight. I highly
recommend getting James’ book, Effective Remote Work: For Yourself, Your Team,
and Your Company, for more practical advice on the journey to full-remote work. You
can also follow James on Twitter for insights on this topic and engineering
management musings.
When I first read James’ article, I was a little surprised he did not jump right into the
practical advice, but instead took time to tell a story about how everything has
changed – yet few actual processes, attitudes and models have. The more I have
thought about it, the more I agree with this observation. This is why I think
transitioning to full-remote work is challenging. It needs to start with a mindset
change, just like this article started by “warming up” to this mindset change with a
relatable story.
Treating everyone as remote is a great piece of advice; but one that’s surprisingly
hard to do if a portion of your team work in-person. And yet, full-remote doesn’t
work without treating everyone as remote.
Being explicit about team norms and communication methods is another thing I
would have never thought about doing in “the old days.” But it’s essential for efficient
remote teams.
For me, “the spectrum of synchronousness” really summarizes the challenge of both
full-remote and full-asynchronous work. It’s not a one-size fits all: even within a
remote setup, doing a video call is more effort and can feel like some time wasted.
But it builds human relationships in a way that collaborating via a document might
not.
If I’d take one thing from James’ advice, it’s that a remote culture needs to be
built intentionally, step by step. Remote cultures need to be more explicit, but each
decision also comes with tradeoffs. And even with full-remote teams, the occasional
get-together in-person, is really important. This latter point is how I see many full-
remote startups and scaleups operate. They bring together people a few times per
year, and focus on building personal connections, strategizing – all while having lots
of fun together.
A guest post by
James Stanier
Subscribe to James
Director of Engineering at Shopify, previously
SVP Engineering at Brandwatch. Wrote two
books: "Become an Effective Software
Engineering Manager" and "Effective Remote
Work".
3 Comments
Write a comment…
Charles Aug 9 Liked by James Stanier, Gergely Orosz
Great article !
However I have to disagree with this part -> « All meetings happen on video call with
individuals dialling in. Even if most participants are in the same room, everyone should
dial in with their own webcam and microphone. This makes the interface of the meeting
identical for those not in the same room, and ensures everyone can see and hear the
same things.»
We tried exactly that at my company (1000+ employees scale up based in France), we

even went further as our new HQ didn’t have VC systems in meeting rooms.
It was an absolute disaster, people were taking calls from their desks (=lot of noise), or
they were each in a room instead of being in the same room. And when they were in the
same room it was hard because of the need to mute/unmute all the time.
In late 2021 we decided to change the policy and we equipped our rooms with VC
hardware, we received wonderful feedbacks. From people based in the office but also
from people working 100% remote.
To finish, I’m working remotely 98% of the time and I prefer when my team uses a VC
system rather than individual computers.
3 Repl Collapse
3 Reply Collapse
1 reply
Tarek 16 hr ago Liked by James Stanier
Overall I enjoyed this article. I do, however, disagree with the following:
> Collaborative drawing software has matured to the point where it is more featureful
and interactive than any physical whiteboard.
I'm curious what tools you're using that beat a whiteboard for collaborative system
design? Neither Miro nor Jamboard approach the ease of use of a physical whiteboard, in
my opinion. To be clear, not as source of truth, but for the live, collaborative design
phase. I've looked far and wide for something that would let me draw on a tablet with
other remote folks, but all of the software tools I've tried coerce my sketches into rigid
shapes and don't embrace the collaboration. Maybe it's me that's rigid?
1 Reply Collapse
1 more comments…
© 2022 Gergely Orosz ∙ Privacy ∙ Terms ∙ Collection notice

Substack is the home for great writing

Efficient Remote Work For Tech Teams - by James Stanier

Uploaded by

Copyright:

Available Formats

Efficient Remote Work For Tech Teams - by James Stanier

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Efficient Remote Work For Tech Teams - by James Stanier

Uploaded by

Copyright:

Available Formats

8/10/22, 10:05 PM Efficient Remote Work for Tech Teams - by James Stanier

Efficient Remote Work for Tech

Q: Help! I'm a tech lead and my whole team is remote.

In this issue, James covers:

1. Everything and nothing has changed since the pandemic.

2. Treating everyone as remote.

3. Setting team norms.

4. The spectrum of synchronousness.

5. Practical tips for remote collaboration.

1. Everything and nothing has changed

We don’t regret a single thing.

We have to unlearn decades of habitual behaviour from location-centric office

2. Treating everyone as remote

We should treat everyone as remote.

Essential information must be purposefully broadcasted to the whole

All collaborative benefits of being in the office must have remote

3. Setting team norms

However, in order to be effective remotely we need to intentionally restore these

The specific software tools used to communicate and whether they

An example output of agreeing on communications norms within a team.

4. The spectrum of synchronousness

What we really need to understand our communication better is a model, so we can

The synchronousness of different methods of communication.

Predominantly asynchronous communication can deprive people of essential

5. Practical tips for remote

Use a structured onboarding program

Onboarding that is relevant to every single new employee, regardless of

Onboarding that is specific to a given craft. Once the general onboarding

The structure of the onboarding program at Shopify.

In order to set new staff up to succeed in a remote environment, we need to have

A centralised system of truth

Decision logs and audit trails

Form mostly synchronous teams with

Managers can typically be more asynchronous than individual contributors, so they

When expanding globally, ensure a plan is in place to gradually grow teams in

Fun needs more intentionality

IRL is still important

Charles Aug 9 Liked by James Stanier, Gergely Orosz

We tried exactly that at my company (1000+ employees scale up based in France), we

Tarek 16 hr ago Liked by James Stanier

© 2022 Gergely Orosz ∙ Privacy ∙ Terms ∙ Collection notice

You might also like