Originally posted on Standuply Blog.
Contents:
- Intro. The Vector of Remote Work
- Pain #1. Redundant Live Communication
- Pain #2. Lack of Rules and Laws
- Pain #3. Lack of Empathy
- Pain #4. Mentoring in Remote Teams
- Pain #5. Process Consistency
- Pain #6. Time and Goals Synchronization
- Pain #7. Overcontroll
Howdy! My name is Artem Borodin. I've been working remotely as a project and product manager for over 10 years. And just over the past 3 years, I have been working on Standuply, a learning and management platform for remote teams. Over these years of managing products, a lot of thoughts about remote team management haunt me.
So, I decided to share them with you.
Now, I strongly feel that the situation in telecommuting has changed and it's still changing. These initial benefits of telecommuting have been sidestepped as they were superimposed on a specific team portrait, which was suitable then. But now, in response to a question about the benefits of a remote team, the modern market says: "We can run any team remotely because it is profitable and cheaper."
That's it. Costs came to the forefront. If I can hire a developer from another city / country for the same or even less amount, why don't I take the chance?
There are still those companies that did not evolve to the desired level for some reason, are on the contrary encountered additional problems from remote work, such as distance, having no sense of personal involvement in the overall process, etc.
When this is superimposed on teams that are unprepared in terms of methodological approaches, the problem increases exponentially. The modern world turns a blind eye to this because people believe that cost is the answer.
And more and more approaches are emerging that do not correlate with the concept of efficiency. Here's a real example: we interact with a well known startup. Most of their employees work remotely. They give their developers an average of 20 hours of tasks for 20 hours of work, taking into account a forty-hour week.
We understand that due to the telecommuting policy, there are communication challenges for the team. This is a shortcoming because tasks will take longer to be performed due to the time spent on communication. There are a lot of such examples. In almost all large companies, project managers allocate a certain amount of time for each employee.
For example, we've planned 32-34 hours of work for a developer a week. Does it mean that the average office-based developer is more than 50% more effective than the developer that works remotely? Is it because the developer is given 20 hours, and for this 20 hours he/she will deal with the "bureaucracy" of a poorly running process?
No and no.
Although there is a belief that if you list all these problems, then cost savings won't actually be so obvious. In an inefficient remote team, tasks will take longer, and costs will be higher.
In the long run, you spend money, time and resources. Besides, it's not even clear that if you spend more on hiring a co-located team in your office, the cost will be higher than with a distributed team. It turns out that my company has become very popular among distributed teams. This is a project management assistant that interviews team members in Slack. Then it collects answers and sends an aggregated report of team performance. It can be very useful for standups, retros, team pulse surveys, and so on.
So, what do successful distributed teams do?
There should be no time concessions in a distributed team. For successful remote teams, work distribution is not a drawback. But, as was originally planned, an additional advantage, which should increase productivity and efficiency. If, for example, you were co-located and planned tasks for 40 hours, then in remote work you would plan as much and, in theory, be considered even more productive, since you could adopt such a work format.
The time it takes to perform work processes in distributed teams shouldn't differ much from that in a co-located team. Here's an example: in distributed teams, administration processes, such as deploying a test environment or configuring a dedicated server, take a lot of time. This can take a week or two, because there is an administrator who sits somewhere "there" and accumulates many different tasks. He/she has set priorities independently and expects from others clearly formulated tasks to be executed in accordance with their priorities.
You might think: "If he was in an office, he could come up, push things, suggest something, talk about information, and deploy an environment in a day." On the other hand, during standups we are in the same office. When we need to meet, we go into one room, spend 15-20 minutes and return to our workplaces. When the team works remotely, gathering together becomes more difficult: everyone needs to be notified, some don't have a headset, and there may be scheduling issues.
So, if we were in the same office, the processes would not take so much time. However, efficient distributed teams don't take communication issues for granted: they look for ways to address this problem so that processes would take around the same time it would take in a co-located team.
In a distributed team, people spend 1 hour instead of 10 minutes in standup meetings. Instead of addressing this, the team continues to work like that because they believe that this is normal and cannot be otherwise.
Managers provide remote employees more freedom. No employee will agree to work with you for an idea as long as you keep track of their every move. But we'll talk about this in the last сhapter in detail. And now, let's talk about the exact pains many many remote teams face. I've seen it quite often to spot the recurring patterns. Moreover, I think I have some advice on how to overcome these pains.
Pain #1. Redundant Live Communication
A successful remote team wants processes to take the same time as it would take a co-located team to perform. So let me share with you some tips for working remotely and effective remote communication.
One of the tips that can be given to a team planning to become distributed is that more live communications are needed. But I believe it may hurt more than help. Here's why. It leads to higher inefficiency. This is so because if you constantly do live communications with the entire team, then all the problems that we talked about will be repeated and accumulate.
This is why it's much more efficient to use asynchronous processes in the team, such as asynchronous standups. Asynchronous standups was the very first feature of Standuply, we started with three years ago. Today, you can run standups using text, voice, or video and also track team performance automatically.
Split up live communications for up to a maximum of three people, when you can phone a small group of people without much loss of quality. You wouldn't experience technical difficulties with communication, such as poor communication or having to constantly repeat what you said due to poor audio quality. The issue of enhancing such live communications in a distributed team is more focused on solving paired problems.
You just need to transfer general team communications to asynchronous mode, reading summary, reading the problems, you can understand who the solution depends on, and then you try to communicate live with these particular people, instead of communicating via email and instant messengers.
Preferably, there should be many small fractional communications. When a Scrum co-located team holds Sprint meetings, everyone takes on tasks and works as if on a single increment. In a distributed team, this does not always work well. If everyone begins to work on their individual small tasks, even within the framework of a single common increment, the team members would lose a sense of involvement and understanding of the common goal. It feels like you're sitting somewhere alone and other kids don't want to play with you.
In telecommuting, it's good to plan tasks that have 2 link sections that depend on each other so that a team could do the same thing, communicate with each other to solve the problem = no sense of loss, train to solve problems at a personal communication level within small groups.
It is very important to have a very small number of laws or rules that are communicated to all team members. Every minute, you need to be sure that the team not only knows these rules, but also follows them.
Two main points - there shouldn't be many rules and they should be simple.
We'll talk about that later.
In every distributed team, there should be processes for which we kind of say: "We need this process in order to spend time." As in a meeting, we don't place efficiency as a priority in this process, such as "At the end of the day, we need to arrive at something / we must meet a certain short deadline."
No, this is a space for controlled chaos.
Let's look at the example of standups based on information from our users: when people switch to asynchronous processes, it doesn't mean that they're replacing all their standups with text and no longer communicating in voice.
Most of them hold standups for 3-4 days a week, from Monday to Thursday, responding with text to Standuply. On Friday, they hold a scheduled session for two hours in order to phone everyone live and, it might seem, to communicate ineffectively: discuss what was done yesterday, in a week, to be able to flood and chat.
But the difference lies with how frequent this is.
When this happens all the time, it frustrates and the process doesn't proceed. But when it happens once a week and is presented as our place and time, where there are no metrics and restrictions, and where everyone can talk, it strengthens the processes. Once a week they phoned, talked, they would have (by voice) clarified something that was lost in a week in a text, and at the same time retaining the feeling of communication with each other. Even when we're in the same office, the flood factor is still important, since we set up social connections by telling jokes or sharing short off-topic messages with team members.
The tips for remote communication I will be giving here could be obvious, but I need put them into separate categories. Else it would be unclear whether it's meaningful talking about some kind of effectiveness as a whole, because like personal hygiene, these are not things you discuss. Suppose we have a distributed team and I'm paired with someone. Whenever I want to contact him via phone or Zoom (if one of us or both of us work from the office but in different cities), I need to schedule a meeting in some special system and in a special room so that we could hear each other very well.
It is desirable to avoid the need of having to reserve a special room just for a meeting. Of course, there should be meeting rooms for the most private conversations, but not for discussing regular work issues. Such issues should be addressed immediately from the work desk without having to move to another room.
Therefore, when planning workplaces for employees, if you are to manage a remote team, create conditions inside the office that would enable your employees to phone each other when a problem arises (without disturbing anyone) and then return to their work.
It should be a big screen where all remote employees are visible, a good quality microphone that you don't have to reach for. There should be a dedicated device designed specifically for these purposes. No one should touch it just without reason. Let it have a sticker with passwords and a shared account that you use to communicate.
There should be a standard room where the whole team is located, and a dedicated internet access for both the office-based employee and the remote employee. You need to also spend money on this initially, otherwise you will later fall into the category of teams that take these issues for granted and overlook them. There should be a simple rule about being late. We start with those around.
If you agreed that you will be having a call/standup meeting by 12:00, and 80% of employees were present by that 12:00, then you don't wait for the remaining 20%. Records should be kept so that those who come late can quickly get along with the process. If something is not clear, the participants do not ask, they simply wait for the follow-up that will be sent to everyone later.
If the people on your team are not ready and not properly skilled for remote work policy, then all other tips for telecommuting, no matter how correct they may be, will not achieve expected goals. You achieve 80% of success in a team if you have the right people onboard. That's why the recruitment process in a distributed team should be better and more detailed than selection in a co-located team. Who do I call the wrong people? They are people without proper experience, an understanding of the values and methodologies of remote work in general, people without self-control.
Pain #2. Lack of Rules and Laws
In a remote team it's very important to have rules and laws which should be a part of the team culture. These should be the minimal things that people have perceived. They are conveyed not even through a clear language but intuitively: at the level of how the work proceeds – such should be constantly running through everyone's mind.
How does a rule differ from a law?
The law should be called something uncompromising, something that should never be broken: if you are constantly breaking the law, then it is not a law. There shouldn't be many laws; anything that can be relaxed can be called a rule. Rules can be excluded, polished and supplemented much more often than laws. Let me give an example with my own team.
Respond to an asynchronous standup. For example, our remote development team has a law that makes it compulsory to respond to an asynchronous standup. To respond means that if I don't give an answer, then I say "I can't answer or I don't have time", i.e. people should understand what's going on. There shouldn't be a situation where someone writes his standup and doesn't know whether others read it or not. No, if I read, then I should give feedback: discuss it or send some emoji so that everyone would know that the information was received.
You need to indicate your schedule and report any changes in it. This is required not for fixing your working time but for ensuring that other people working with you understand when you will and will not be available so as not to wait for a response from you; so that they can plan all the activities, understanding the schedule of another person.
If you're going to criticize it, then suggest something else. It gives you the opportunity to listen to and hear other people's position on your problem.
There is no individual zone of responsibility, but a common product. Yes, everyone has their own area of responsibility. However, if while doing something, you discover that some things aren't working correctly but you still ignore it just because you are not the one directly in charge of that, then this is a wrong approach. Everything concerns everyone, because everyone is working on one common product. Of course, it's not always possible to do everything perfectly, and it's good when everyone, noticing the problems and challenges, reports them for general discussion in order to come up with a solution. Then comes the rule "If you're going to criticize it, then suggest something else" – that's how the process of grinding and improving occurs.
Detailed answers. If you have much to say, then do so by voice. For example, in our rules, we try to write detailed answers to asynchronous processes, we try not to get off with short messages. If we need to say a lot, we resort to audio and video messages, we try to react to all asynchronous processes, give feedback – understood, accepted; we try to come with a solution.
Come with a solution. We also don't like when someone reason as follows: "It would be great to do like this, then everything would be perfect." We like the paradigm: "Look, it wasn't very good here, I did like this - this is the first version, it's very primitive, but it can solve something and it's effective - let's discuss it". This shows that the employee really cares about the process, he offers solutions and does not just imagine how good things would be.
Be independent. Be independent, you set the task yourself – you control it; you need help – you ask for it, instead of waiting for a solution from above.
If you started something – improve it. If you take up something to work on, then ensure its continuous improvement. For example, if we take up some feature, we make a commitment that we will improve it in the long-term so that our product does not have any functionality that we launched and then abandoned. Rules and laws cannot be universal, that's why I'm telling you about ours: they are exclusively peculiar to each team.
Pain #3. Lack of Empathy
It could just be because these interactions intersect on working issues, and therefore it's important to remind yourself that the person on the other side of the city a priori does no less than you; if you don't know something about other's work, that doesn't mean anything. It's important to always think and remember this. There are ways in which empathy can be developed.
Many integrations are recommended: with support systems and Intercom. Example: our support team is remote. We have a special channel in Slack and where the support team has Intercom integration. When you see that something is happening, you pay attention to it. Without this integration, the developer might have the feeling that there are few requests.
Or, another example: you believe that developer Jake contributes more to the project than developer Mike simply because you communicate more often with Jake than with Mike. The task of a highly organized team properly assembled by you is to ensure that everyone controls himself. Then people will filter by themselves: they will set aside an hour before going to work to see what's happening in notification channels that are not directly related to them.
It is desirable to alternate pairs so that each person could work with everyone and know each other better. It helps a lot for the next point – get your "Champion". When you work remotely and understand that you need to solve some issues more efficiently, one of the main recommendations is to find on the other side the "right" person through whom you will push and work with others.
There is always a person on the team who would be a little more suited to your personality than the rest, someone you have a more natural rapport with than others. Getting yourself a "champion" is also very important for the purpose of conveying information to the entire team. Pair work helps in finding your own champion. This ultimately boils down to improving overall performance.
It is also necessary to do regular offline meetings, organize corporate parties and see each other in person. Offline meetings are necessary for the team to understand that each remote employee could feel like a part of a large team and get to know their office-based colleagues. An individual approach is very important to remote employees. Human factor is still always there irrespective of how automated your business is.
If there is no informal communication, it's impossible to know an employee's ambitions and in what direction he wants to develop. You can quickly understand how to manage a remote team when you delve into the personal problems of your employees. For example, a week before the New year, we invited all our remote staff to work in the office with the team so that they could chat and rub shoulders with everyone at the New Year party.
Anyway, we always expect our remote guys to visit. We help with their tickets and accommodation, etc. This allows them to feel as part of a large team and not cut off from the mainland.
Pain #4. Mentoring in Remote Teams
It is very important to have mentorship in distributed teams. In a co-located team, you somehow observe the employees in terms of their personal development. When people work remotely, it may appear that they aren't working in the full sense of the word but are simply performing tasks. Someone is ready to mentor for free and share this material after that somewhere and create a portfolio. And someone who already has a certain experience and popularity, is ready to share his experience for a fee. By the way, we also use Mentors platform within our team. An employee can ask team leaders any video question. Team leader will in turn record a video answer. All these videos can be saved in Answers Wiki and used to create something like an educational base.
Pain #5. Process Consistency
The effectiveness of a team depends on the sequence and consistency of processes in the team and how difficult it is to maintain consistency in distributed teams. This is difficult to achieve even in non-remote teams. But in remote teams, this should be given special focus because any process that you start stops working once you stop following it constantly.
Your standup will not work if you do it today, you don't do it tomorrow, you miss it for three days and so on – constantly. You will remain in this process constantly, more frustrated than you would receive results. So, if you start any process, you must complete it. For example, you realize that you can't always call up your remote employees for standup meetings, you don't have the right infrastructure. Then you build the process in such a way that, for example, text answers will give you 90% consistency, while you solve other problems via one-time weekly 2-hour phone calls. All activities should be aimed at ensuring consistency of processes.
According to the Pareto Principle, in any process there is something that gives you 80% success. In distributed teams, people are the ones who give you 80% of success. When handling employee expectations, you get 80% success from properly organized one-on-one virtual meetings, which should be held regularly. The main secret and insight of one-on-ones is to ensure its consistency. This process was originally designed for the long term. In many respects, its success does not depend on the mechanics of the process – what questions will you ask, is there any clear check sheet, etc.
This shouldn't be a signal to punish your employee! Any interaction with an employee is a constant search for what he actually wants to do. Yes, we can easily say that since he's doing this or that work, then he likes it. But this is not always the case in most situations — people don't always immediately understand the prospect, they don't see where they want to come from.
You need to find a vector for each person on your remote team. The right vector will eventually increase performance and overall profit for the company as a whole, because when you genuinely love what you're doing, the result will be many times higher. So perhaps you just need to dig deeper sometimes: "If you are not interested, let's search together and solve this problem."
Pain #6. Time and Goals Synchronization
When working remotely people most often perform separate tasks. Folks perform their individual tasks without understanding the common goal. Sometimes it means that these tasks are generally not that needed.
Example: We set the goal of reducing churn rate for our product. Meanwhile, someone is busy with their individual task (because, for example, a manager failed to keep track of happenings, thereby leading to increased churn rate for registrations, which may not be so important in this situation.
So, if each remote team member understands what the company is about and his/her responsibility area, then he/she can prioritize tasks himself. To set up goal synchronization in a distributed team, using weekly records will be very beneficial: you've started a new iteration, a new week. It's better to write it down so that you can resort to it later.
Sometimes you can say it by voice at a general meeting, but there is a chance that someone won't hear or might forget exactly how it was formulated after a week. The weakest advice here would be to choose the maximum amount of time to have a time zone under which you and they could work remotely, so that you could chat.
There are some reservations here. This should not go against common sense. When one of the parties insists on a time zone that is inconvenient for others, then this won't work. Example: My mom works at the head office of a bank. We must remember that banking activity is a contingent, where people normally come to work by 09:00 and leave by 18:00, they come home and spend time with their family.
Now they have been compelled to work under Moscow time as much as possible. This meant that the working day should have begun at 11:00 and ended at 21:00. Of course, everyone was against it since they were not used to working like that.
It's more effective to keep a record, send it to the chat, pin it so that it's always in sight, and occasionally check it. You can run a general survey, "Did you familiarize yourself with the task?" This gives higher success in a distributed team.
We created a whole template Team Goals in Standaply for convenient and effective goal synchronization. Team Goals align team members and the Product Owner on a shared mission for the iteration. Goals provide a sense of the direction and concrete milestones to be achieved during the Sprint. Team Goals are mentioned on every team meeting motivating them to achieve it. I advise not to change a Sprint goal, and if the goal has changed it's better to wrap up the current sprint and start a new one.
People in successful remote teams generally say that if you have the opportunity to organize a comfortable working time for several teams, then you certainly shouldn't neglect that. But if suddenly this is impossible for objective reasons, maybe the time difference is really much (12-13 hours), then you need to push the remote employee in order to find the right time.
We must think in a vector how to solve the problems of effective work without such a time zone. This is the same thing we said earlier: a successful distributed team does not spend 50% of its time on broken communications and doesn't plan tasks for 20 hours only because it is distributed.
A successful distributed team will also plan for 40 hours, and solve problems in such a way that communications are not damaged: "How could we work remotely within this time zone without having a common time?" What matters is the vector of understanding in which direction to go. If there is a common time zone, it shouldn't be neglected, but again the key point here is that this should be in a normal working comfortable rhythm for all parties. If this means overpushing for some parties, then it won't work for a remote team. You'll simply be changing employees, they will burn out, and so on in a circle. Each time you'll have to solve old tasks over and over again.
Pain #7. Overcontroll
Distributed teams that try to limit and control their remote employees as much as possible are unsuccessful teams. In such teams, half the time is spent either on solving communications-related problems or on processes that drag on so much in a co-located team. If there is more freedom in a remote team, there is a greater likelihood of having blunders and other problems in the work. But people who're prepared for this and understand values will cope with it well.
What to control in a remote team and how?
So many modern distributed teams try to control almost everything in the work of their employees. This is most often done through utilities for remote control such as recording screen time. A distributed employee is asked to install a utility that records the screen of his monitor for the entire day of work. The management sends summary graphs of reports showing how much time was spent and in which programs. These reports enable the management to draw conclusions on the performance of a particular employee.
I can say with confidence that only unsuccessful distributed teams act like that. It's very important to know that as soon as you begin controlling a person, he begins to think about workarounds at that very moment.
He may not even need them, but at the level of unconditioned instincts, a person begins to think: "In case I'll need them later, how do I protect myself?" Then, at work, the brain will be thinking not about performing tasks or finding effective solutions, but about how to trick the process. Let me give one of the most striking examples that I have personally encountered several times.
When I first came to the company, Alex told everyone that we all will be using magnetic tokens to gain access to the office. The aim was to record the amount of time you spend in the office. We agreed to observe a couple of days. And literally the next day we start noticing people with this attitude – "If you'll come earlier than me, please take my key, open for me."
Once you start to control people, their brain disconnects from solving real problems and begins to think how to trick the process. This is not because the person is bad or doesn't want to work, but because the original wording implies an infringement on what the person is used to. The problem is not who comes at what time.
If people come to the office for a couple of hours, then the reason might be that they don't have enough work to do or that the tasks or goals are unclear. This should be addressed first to eliminate such consequences. Being in a specific field, you should know how much time a specific task can take. You don't need to have additional tools to record the time spent over a task.
Real reasons, as well as fictitious ones, always become clear. If tasks are not performed, this may be a signal that you did not work out your expectations correctly and that the wrong person is in the team. It is easier to change that person because people are 80% successful. In order to avoid engaging in primitive micro-management, it is better to recruit self-organized people who can calibrate themselves working remotely.
Example: When we started working with outsourcing companies, they offered to send us time reports because we pay them hourly. I said it was unnecessary. They asked why? We replied that since we've been working in this area for a very long time, we can tell whether their price is too high or not. If they overestimate their prices, we will overpay them once, but then we'll simply stop working with them and find other partners. This will take us less time than checking reports every time.
In any case, it will be difficult to push us into a critical amount that would eventually cripple us financially. In fact, they didn't earn as much as they would have wanted because they spent a month studying a task, and they didn't want to include this in the bill, because they already have their own internal evaluation criterion. They will think, "If we charge higher, our customers might find a replacement for us; we want to work with them because they have interesting tasks. We won't get better offers elsewhere so we'll master this task in the future".
We've already had such cases several times. And this is called controlling the task, giving maximum freedom. Distributed teams that try to limit and control their remote employees as much as possible are unsuccessful teams. In such teams, half the time is spent either on solving communications-related problems or on processes that drag on so much in a co-located team. If there is more freedom in a remote team, there is a greater likelihood of having blunders and other problems in the work, but people who're prepared for this and understand values will, of course, cope with it well.
That's all, folks. Thanks for reading.
Top comments (0)