Managing Remote Teams - A Crash Course
I haven't been blogging for quite some time, so everything is a bit rusty for me, but i thought this article might be useful for a few more people, because about 1-4 times per week i get approached with a question like:
"How did you remote work for your team?"
"Our team struggles with engineers who are remote…"
The post got a bit longer than i planned to, because i tried to cover the outline of all aspects that might be useful for you when you approach this topic. In this article, i will go over the different kind of setups of remote teams, why and how remote teams work differently, when you want to work remotely and when it's better not to and lastly a few tricks that worked for the teams i was involved. Thanks for reading and thanks for sharing. 🙏
For those who don't know me and just stumbled into this post by accident: I am @andreasklinger -among other things - I helped to build up Product Hunt as a fully distributed team. Btw… yes, they are awesome, yes, they hire internationally, and yes, you should consider applying.
COVID-19 Update: I wrote a second article focusesing on how to setup an "emergency work-from-home" scenario that many companies need right now because of COVID-19. You can find this article here.
So here without further ado… here… we… go.
Remote teams - a crash course
Different setups of remote teams
There is a bunch of different setups people call "remote teams".
2 or more teams are in different offices.
most of the team is in an office, but a few single employees are remote
which are "basically" fully distributed
but have a non-critical-mass office
they focus on remote-friendly communication
When i speak of remote teams, i mean fully distributed teams and, if done right, remote-first teams. I consider all the other one's hybrid setups.
Why does the distinction matter?
They are actually something entirely different and need different solutions.
As a remote team, you have roughly 5x the process needs as you would in a co-located team.
Everybody loves meetings… right? But especially for remote teams, they are expensive, take effort and are – frankly – exhausting.
If you are 5 people, remote team:
You need to announce meetings upfront
You need to take notes b/c not everyone needs to join
Make sure it's not overtime
Communicate further related information in slack
In contrast, if you are 5 people co-located you just stand up and say: "everyone over there - we talk now". Once a co-located team reaches 20-25 people they definitely need to do the same steps. But before…
You can't just "get up and talk with everyone all the time" in a remote team… you simply can't. People might be offline, might be sleeping, might be deep focused on other work.
And this is not only about meetings. Meetings are just a straightforward example here. It's true for any aspect of communication or teamwork. Remote teams need 5x the process.
You need to systemize communication and expectations
When i say processes, i don't necessarily mean heavy-handed workflows, piles of paper and someone using a giant stamp confirming every action. I mean "systemized communication and expectations made explicit".
This can be as simple as: "We do check-ins every morning…" "Please before you do X always do Y…" These simple explicit agreements allow other people to expect those actions to happen and avoid unnecessary communication loops.
But… i am sorry to say… this is work… you need to act like a larger company than you actually are… you need to be stricter about best practices, and you will run into communication problems… a lot of them.
These communication problems are often what people complain about when they discuss if they should switch to remote teams or hire remote engineers. So they consider hybrid setups…
Hybrid setups are hard to do
Imagine you are the only person remote in a small team. You have entirely different process needs. You will suffer.
Being the one poor soul remote in a co-located team is hard… you have "5x" the process needs… People will continuously forget to involve you in discussions or decisions, you will be the person not knowing what is happening why - you will suffer.
Similarly problematic are satellite offices. The bridge between the offices has 5x communication needs, but people in each office act like co-located teams. Unless the offices can work mostly autonomously, this communication bridge between them will suffer.
Establish processes for communication needs for these kinds of setups are hard. Because they are against human nature… I will just discuss things with you while getting water in the kitchen… I won't repeat what we discussed in slack because i am… well… as all humans… damn lazy!.
Default remote or default non-remote?
I have tried all the models described. Personally, I'd recommend you avoid hybrid approaches and act as distributed as possible - or just don't do remote at all and be co-located. Both are fine.
If you need a small office, make sure people in it don't have a critical mass in projects and communicate remote-friendly.
In these situations, the question is often "Are we default-remote" or "default non-remote" if it's the first, having a small office might work out for you.
Questions to ask yourself:
Why do you consider doing a remote team?
Are those advantages worth the effort for you?
If yes what would need to change if you would commit to it?
How often do you want to meet in person?
If you need a small office how can you communicate more remote friendly?
Example: Would it be weird if all people in the office would join team calls with their own laptop?
Why would a team want to work remotely?
A lot of people mention costs. "It's cheaper to hire people remotely". This might be sometimes true – and it's definitely true if you are used to San Francisco salaries – but… international talent usually expects international salaries… so you'd be surprised how much many people expect. If you want cheap outsourcing, this "remote thing" won't work for you.
Overall hiring remote is about four things - being able to hire, the best possible people independent of where they (or you) are - optimizing for the quality of life - tuning your personal performance - having long-term team retention
"Our startup is amazing, people will want to move to X"… Some will… some won't. All the "won't" are a lot of people you are missing out.
On the other hand with a good remote-team pitch, you can even (often, not always) approach Silicon Valley top talent: "Hey considering leaving the Bay Area? Google might have an issue with it, we don't - work with global talent on a project that matters – wherever you are. Shall we talk?"
But (imho) what most people are missing… is not the costs… not the untapped talent… nor the ability to optimize your quality of life and own performance. It's a simple fact: talent retention. Ask remote teams how long their people stayed with them. It's years longer than in co-located companies.
One thing you will quickly realize is that a lot of human nuance gets lost when discussing things via Hangout or Slack. This nuance is important. Especially if you work on critical, creative work.
Imagine you need to pivot your product. You make a long passionate speech about what the team needs to do to win the market, just to be followed up with a "Sorry Sarah, your internet connection dropped for a second, what did you say?"
"Innovation" is more natural in person. It's better when even the quiet person in the back can pick up a marker and explain something.
But once you agree on something it's about individual performance… This is usually easier remote.
Innovation easier in person
So even if you work remotely, you will need to define how often you want to meet. I recommend once per quarter or twice per year as a team and whenever required by the individual project teams.
A lot of people mention loneliness as a problem in remote teams. Personally, i never had this an issue be for me, but i saw it with friends and fully understand why people are worried about this.
As company-lead it will be your responsibility to make sure people are happy and healthy. Here is what helped in our team:
Don't work from home but a shared office (coworking spaces tend to be too distracting)
Make sure you meet non-work friends
Optimize for iteration - Optimize for single player
In remote teams, you need to set up in a way people can be as autonomously as they need. Autonomously doesn't mean "left alone" it means "be able to run alone" (when needed).
Think of people as "fast decision maker units" and team communication as "slow input/output". Both are needed to function efficiently, but you want to avoid the slow part when it's not essential.
Questions to ask yourself:
… define strategy clear enough that people can formulate their own decisions without going off-track?
… set goals clear enough that people can benchmark themselves or their decisions?
… setup decisions hierarchies in a way that only non-reverse-able important decisions even bubble up to you?
… create confidence? (speed comes through confidence)
When is it enough that you hear about it and when do you need to involve?
How can you make sure that you are only involved in every 10th decision and only "manager-override" every 100th?
… set up your environment/processes that they can act even in emergencies on their own?
If you hired smart, talented people, why can't you just "let them do their job"? What's missing? Did you hire the wrong people? Did you not communicate clearly? Are you (yourself) uncertain about strategic elements? Solve that instead of micromanaging them.
Apart from these company-wide questions, you will want to ask similar questions also for each specific vertical.
Digging deeper: managing remote engineering teams
Here a few example questions for engineering teams (but you will know similar ones for any kind of function):
How can you or someone in your team…
… troubleshoot alone when it's in the middle of the night for everyone else?
… enable new developers to be able to learn by themselves?
… guide coding best practices?
… avoid making pull requests a slow process?
… prevent meetings that don't create value?
… enable developers to make product decisions on their own?
… avoid worst case scenarios?
And again: How can you increase confidence? (speed comes through confidence!)
At Product Hunt we thought a lot about this! Here a few answers that helped us:
Have a clear strategy and high-level goals
Let engineers take ownership over teams and projects
Let them take ownership over the product they build, but also the goals they commit to (strategy goes top-down, execution bubbles bottom-up)
Making it clear what scenarios require multiple eyes or other people's feedback (e.g., stack changes, security concerns, etc.)
Have strong onboarding documents and employee handbooks
Have new employees improve those onboarding documents
Be explicit in communication
Be explicit which are expected rules and which are not.
Wait for problems before you introduce solutions (esp. processes or infrastructure)
Friday's employees can work on what they think creates value (unless their project is on 🔥) - fixing tech debt, improving UX, trying out new libraries, refactoring infrastructure,…
Share recorded videos instead of live-demos to explain something (e.g., UX prototypes)
Have a strong (but not too big) test suite (focusing on integration for features, unit tests for risky parts)
Focus on reuse of standard components instead of pixel-perfect layouts
Enforce linters for any language you use (even, e.g., HTML/CSS)
Enable autoformatting (to avoid code style discussions)
Enforce complexity scoring in linters (⬅️ biggest win)
No production console access unless for (logged+alerted) emergencies
Make it easy to recreate a production-like state in development (sanitized)
Have one-step-to-reinstall development environments
Have defined times for pull request reviews (first thing every morning)
Make Pull-request +1's a "polite thing to do" but not a "required step"
Enforce pull request +1's for parts that are security risks (via danger.js)
Write comments about why not what
Let me know if you think it would be useful for you if i'd wrote a larger blog-post going into detail here. For now, there is a lot more detail about we worked at Product Hunt in this first presentation of mine: https://www.slideshare.net/andreasklinger/engineering-management-for-early-stage-startups-97402850
TL;DR: The ultimate goal of this setup is that an engineer can figure out, on their own, if they are doing things right or wrong. Have low-level feedback coming from automation and that it's clear when high-level feedback is needed from team members. And most importantly you treat them like capable adults.
But… these are not problems of remote teams
The problems i mentioned are not unique to remote teams, and the solutions are the same thing good co-located teams do. But they don't need to be as strict about them because they face them later of can just monkey-patch around them. Their engineers might not like the typical "let's all get over there and talk…" But i tends to work… so people do it anyway.
co-located teams monkey-patch their process problems with more meetings and micro-managing people.
As a remote team - because of the higher process needs - you just end up facing these knowledge worker management problems earlier and more intentionally.
Because meetings are expensive for you, you need to think about systemizing processes actively.
Because you cannot watch over your employees' shoulders, you have to find ways and boundaries you can fully trust them.
Because you cannot micromanage them, you need to define strategy and goals and treat them as competent adults who make decisions for you.
Aren't you already working in some way?
We can discuss the pros and cons of remote work, but let's be honest…
We are all already working remote… You might be checking your emails on your weekend, you might be reading papers on your way to work, you might finish some project in the evening at home. You already work remote, the question is only how often and how much enabled you are to do so.
The question is no longer if you work remote but how much.
Remote work is the logical evolution of digital work. And the best-practices of remote teams are often learnings for all digital knowledge work teams.
Let me know if this is useful… And if you have experience with remote teams, tell me how i could improve this article! Also last but not least: Please share this article if you think it's of value!
PS: I haven't been blogging for years… I was very nervous about starting to write again and asked for early feedback. Over 100 people offered their help, more than i can mention here, i am still at awe about the fantastic feedback i got. The offer to help means a lot to me. Thanks to everyone.
If you want to help me by feedbacking early drafts of my blog-posts please subscribe here. Thanks in advance
