Short course on managing remote teams

Hello!

I have not written for a long time and forgot how it is done, but I want to share information that may be useful to many. After all, they constantly bother me with questions like:

• “Is it worth working remotely?”
• “How did you organize the remote work for your team?”
• “It’s hard for us to work with remote developers ...”

The post came out longer than planned - I tried to describe all the points that you need to take into account. In this article I will show the different structures of remote commands, how and why remote commands work differently when it is, and when it’s not worthwhile to work remotely, and, finally, I’ll give you real examples. Thank you for reading.

And one ... two ... three ... Let's go!

Different remote command structures

Remote commands are understood as different:

● Satellite commands
○ Several teams sit in different offices.

● Remote employees
○ Almost everyone is in the office, and only a couple of guys work remotely.

● Fully distributed commands
○ All on the remote.

● According to the remote first principle
○ Essentially, they are fully distributed,
○ but someone works in the office.
○ Try to communicate so that remote employees are aware of everything.

By remote commands, I mean fully distributed and valid remote-first commands. The rest I think are hybrids.

Why is it important to see the difference?

Simply, these are completely different types of teams with different needs.

Process requirements

Remote teams have approximately five times more process requirements than office teams.

For example, meetings

- I love the meeting.

Yes, no one likes the meeting. But for remote teams, this is a particularly expensive, difficult and tedious experience.

How does a remote team of five meet:

• We announce the meeting in advance.
• We are recording everything, because not all have arrived.
• We arrive on time.
• We write the agenda.
• We try not to delay.
• After we write something in Slack, etc.

In an office in a team of five people, you just get up and say: "Everything is here, there is a conversation." Although if there are 20-25 people in the office, you still have to tinker. In the meantime ...

- To say - easy.

In a remote team, you can't just stand up and talk to everyone. Well, no way. Someone is offline, someone is asleep, someone is deep in work.

Meetings are just a good example, but we are talking about any kind of communication or teamwork. In remote commands, processes are five times more complicated.

Need to systematize the interaction and expectations.

I call processes not hard work with a bunch of papers, where every action needs to be confirmed by a seal. I mean systematic interaction and clear expectations.

For example, every morning we celebrate or always do one task before doing another. With such clear rules, people know what to expect, and avoid unnecessary communication.
I do not want to disappoint you, but ... after all, this is work, and you need to behave as if the company you have more than it actually is. You need strict rules. Communication problems will arise constantly - and in large quantities.

People often complain about these communication problems when they think whether to transfer teams to remote and not to hire remote developers. And they decide on hybrids ...

With hybrids is very difficult

Imagine that you are one of the team sitting on the remote. You have very different process requirements. And you suffer.

It is difficult to be a renegade in an office team - you have five times more requirements, and you are forgotten to call for discussion, everything is decided without you, you alone have no idea why you are. In general, life is a pain.

Satellite offices also have problems. There are five times more communication requirements between offices, and in the offices themselves, people work as usual. Unless the offices work almost independently of each other, the connection between them will suffer.

It is difficult to create processes for communication requirements in such teams. This is generally against human nature. I'll go to the kitchen to drink some water and chat with someone in between times. And in Slack, I will not write anything about it, because ... well, because I am in a scrap! Man, or where?

- I'm not that lazy. I just do not care.

By default - remotely or in the office?

I tried all these models. Personally, I advise you to avoid hybrids and strive for fully distributed teams - or completely abandon the distance and sit in the office. Both approaches are suitable.

If you need a small office, do not let the bulk of the team sit in it and let remote employees not be excluded from the discussions.

In such situations, if the default team works remotely, the small office will come down.

Ask yourself:

• Why did you decide to create a remote team?
• Are the benefits worth the effort?
• If so, what will have to change?
• How often will you meet in person?
• If you need a small office, how to connect with remote employees?
  ○ Example Does it bother you if all the people in the office at a conference call sit from their laptops?

Why work remotely?

Many are talking about saving. Like, udalenka goes cheaper. Sometimes this is true, especially if you are accustomed to wages in Silicon Valley. But foreigners expect a world-class salary. You'd be surprised how people have expectations. Are you dreaming about cheap outsourcing? Then the remote is not for you.

- Hello, give a bottle of your best wine.
- From you 1600 dollars.
- Fine, then be so kind to me, the eight-bucksiest one.

Hiring remote employees has four advantages: you hire the best people, wherever they (or you) are; improve the quality of life; manage your productivity; you have a low staff turnover.

“We have a great startup, everyone wants us!” Someone wants. Someone not. And these last ones are a bunch of people you miss.

On the other hand, with the right approach, you can even lure geniuses from Silicon Valley: “Hi, did you think to move from San Francisco? With Google, this number will not work, but we are another matter! You will work with guys from all over the world on an interesting project, wherever you want. Well , discuss ?

As for me, it’s not about expenses, cool specialists and optimizing the quality of life and its productivity. The main thing - the retention of personnel. Do you know how long people work in remote teams? Much longer than in the office.

Iterations vs innovations

You will quickly realize that many human nuances are lost in Hangout or Slack. These are important nuances, especially if you have a creative project.

Suppose you change the direction of development. You have been long and enthusiastically telling you what the team should do, and in response: “Sorry, you have something with the Internet. What did you say now? "

Innovations are better at face-to-face meetings, where even the most silent and inconspicuous employee can take a marker and explain something.

And when you have already agreed to something, everyone sits down to their tasks, and it is easier to do it remotely.

• Iterations - remotely
• Innovations - personally

Even if you work remotely, agree on how often to meet. I advise you to meet once a quarter or twice a year with the whole team. And let the teams for individual projects meet as needed.

Loneliness

Many complain that it’s lonely. Personally, I have no such problems, but I have seen this with friends and understand why people are worried.

The head of the company must ensure that everyone is healthy and happy. Here is what helped us:

• We work not at home, but in offices with joint rentals (in coworking you are distracted all the time).
• We meet with friends not from work.
• We meet regularly in person.

Optimization for iteration - optimization for single player

In remote teams, everything should be arranged so that people can work as autonomously as possible. This does not mean that you need to leave employees alone. Just give them the opportunity to work alone if necessary.

One by one people make decisions quickly, and the team often slows down. To achieve the result, you need to work both ways, but try to avoid team red tape if there is no urgent need for it.

Ask yourself:

• How to define a strategy so that people understand it and make decisions themselves in the spirit of this strategy?
• How to define goals so that people understand them and focus on them?
• How to establish a decision hierarchy so that you solve only the most important issues?
• How to instill confidence in people? (it works faster)
• When can you do without you, and when do you need to intervene?
• How to make you participate only in every tenth decision and annul only every hundredth?
• How to organize the environment and processes so that they work even in emergency cases? "

If you hired smart and talented guys, then why not just give them free rein? What is missing? You hired the wrong ones? You could not clearly identify goals? Are you personally unsure of strategic elements? It is better to solve these problems once and for all, than to deal with the consequences every time.

Ask these questions not only for the whole company, but also for each vertical.

Digging deeper: managing remote development teams

Here are some examples for development teams (it is easy to draw analogies with other areas):

How can you or a team member:

• ... trash alone in the middle of the night?
• ... help new developers learn on their own?
• ... share tips on writing code?
• ... not to turn pool requests into a protracted process?
• ... not to meet without special need?
• ... allow developers to make product decisions themselves?
• ... avoid the worst scenarios?
• And again - how to increase confidence? (it works faster with her!)

We have been thinking for a long time in Product Hunt and this is what we thought up:

• Clearly identify strategies and global goals.
• Let the developers are responsible for their teams and projects.
• Let them be responsible for their product and goals (the strategy goes from the top down, and the execution - from the bottom up )
• Clearly indicate when the opinion of several people is needed (for example, changes in the stack, security problems, etc.).
• You should have thoughtful documentation for newbies and employee manuals.
• Let new employees improve this documentation.
• Use clear language.
• Clearly identify the rules and prohibitions.
• Do not implement solutions until you have problems (especially for processes or infrastructure).
• On Fridays, employees can do whatever they think is useful (if the project is not on fire) - correct technical flaws, improve the user interface, try a new library, rebuild the infrastructure ...
• Record video instead of live demonstrations (for example, for user interface prototypes).
• Get a reliable (but not huge) test suite (for feature integration and unit tests for high-risk parts).
• Try to use the standard components several times, and not pore over each pixel.
• Be sure to use linters for each language (even for HTML / CSS).
• Enable auto-formatting (not to discuss code styles).
• Include in linter counting complexity (️ great idea).
• Do not meddle in the production console if this is not an extreme case (with logs and alerts).
• Let production conditions be easy to recreate in development (without unnecessary data).
• Development environments must be reinstalled in a single action.
• Select a time to view pull requests (first thing every morning).
• “+1” in pull requests is cute, but not necessary.
• If there are security risks, ask for “+1” (using danger.js ).
• In the comments, write why, and not what
• etc

Write me if you want me to paint everything in detail. In the meantime, details can be found in my first presentation on how we worked in Product Hunt: https://www.slideshare.net/andreasklinger/engineering-management-for-early-stage-startups-97402850

If you are too lazy to read a lot of letters: ideally, the developer himself must understand if he is all right and when he needs review reviews from colleagues. And let the details be checked automatically. And most importantly - treat them as adults.

These are problems not only of remote commands.

All these problems concern not only remote commands, and solutions can be used the same as in the office. Just office teams do not need such strict rules - they can always fix something along the way. The developers may not be delighted with meetings and chatter, but it works and everyone does it.

In the office, problems with processes are solved by frequent meetings and constant intervention in the work of team members.

Remote commands are more demanding on processes, so problems with managing employees simply occur earlier and are more striking.

- Rule number 1: do not gab.

Since it is expensive to meet, it is necessary to consider systematization of the processes.

If you can’t stand at the staff over the soul, you need to understand what they can fully trust.

Once you cannot follow each step, you need to define a strategy and goals and treat developers as adults who can make decisions.

Think you're not on the box yet?

You can, of course, discuss all the pros and cons of distant work, but let's be honest.
We are already working this way. We check mail on weekends, read papers on the way to work and finish projects at home in the evenings. You already work remotely, the only question is how often and how many necessary tools do you have.

You work on a remote or not - no longer a question. The question is how much.

Remote work is a logical development of working with digital technologies . And the working methods of remote teams can be applied to all who work in the digital space.

the end

Let me know if I tried in vain. And if you have experience with remote teams, tell us how you can improve the article!

Ps. For many years I did not write anything to the blog ... I was really nervous and asked for feedback in the process of writing. More than a hundred people offered help, I can’t even mention everyone here, and I absolutely love the comments. Such help means a lot to me. Thanks to all.

If you want to help me with draft posts, subscribe . Thank you in advance.