Product Manager's Diary
Working remotely:
collaboration pains no one talks about
Dear Diary,
Here is a collection of my thoughts and conclusions from my experience working remotely for 10 years.
Howdy! My name is Artem Borodin. I'm co-founder and CPO at Standuply.com.
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.
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.
Don't have time to read it right now?
Let me send you a PDF copy so you can read this material when it's convenient for you.
It takes 5 seconds, just let me know where to send it.
It takes 5 seconds, just let me know where to send it.
Pain #1
Intro
Pain #2
Pain #3
Pain #4
Pain #5
Pain #6
Pain #7
Sounds familiar, huh?
If any of the above re-echoes something in you or makes you have flashback memories, then you probably work or have worked in a distributed product team. And therefore, you are very familiar with the so many opportunities and the flexibility that come with remote working.
Just a dream, right?
Just a dream, right?
"We don't have any office. Why should I waste hours in traffic jams when I could work from home?"
"In our city, we don't have the people with the skills we need."
"I can still hire developers from another city with the same money and quality."
"I'll spend this winter in Thailand working remotely. What difference does it make where I work from?"
"The weather is too nice to work. I'll go to the park and will work later in the evening or in the weekend."
"I can't get up so early, can I come to the office and start my working day at noon? I'm an owl anyway!"
We can't agree on this for a week now! He responds to my questions when I'm already asleep."
"Did you understand anything these guys have been explaining to us for 1 hour now? I can't make out a word!
Sorry guys, I'm having some issues with my headset, I can't hear anyone, so you all go on ahead without me, today."
But you're also most likely familiar with the following words
"But what exactly are these Michigan guys doing? Are we even on the same team?
Why didn't anyone say that this was no longer a priority for us? Why are we doing this then?"
"Did the designer take offense at my last edits? Or is it just her writing style?
I don't know, but what are we even discussing? I've lost the point after the 27th email."
This can go on indefinitely. But let's look at those major problems with managing a remote team that no one usually talks about.
I see everywhere articles about team spirit, constant communication, monetary benefits, and yadda, yadda, yadda. We're aware of all that.
But no one talks about the root of the problem. No one discusses the reason why it even exists.
I invite you to take a look at the problem from my angle.
I see everywhere articles about team spirit, constant communication, monetary benefits, and yadda, yadda, yadda. We're aware of all that.
But no one talks about the root of the problem. No one discusses the reason why it even exists.
I invite you to take a look at the problem from my angle.
Intro
Where remote work is heading to?
The following are the current problems: remote work has changed its original vector.
Initially, 3 criteria could be identified in favor of remote work.
Initially, 3 criteria could be identified in favor of remote work.
Search for the talent
The focus was on the ability to find good specialists from anywhere in the world who could be later made to work for the company due to lack of required talents nearby.
When companies, such as Google, Microsoft, Intel, etc. just started emerging at Silicon Valley, they began to greedily absorb all the top talents nearby.
So, at some point when working remotely became possible, startups began to look beyond California and the country.
They began to understand that, although it's difficult to compete in the offline market, they can attract skilled specialists overseas.
So, at some point when working remotely became possible, startups began to look beyond California and the country.
They began to understand that, although it's difficult to compete in the offline market, they can attract skilled specialists overseas.
Cost efficiency
You can find the same top-quality specialists from another location and pay them less / not spend money at all renting huge offices.
For example, instead of hiring a developer in a major city for a huge salary, you can hire a specialist in a province for less amount.
People thought: "Although a provincial developer might be less skilled and will take me longer and easier to develop him, so I'm ready to train him."
This paradigm hogged all the others later.
People thought: "Although a provincial developer might be less skilled and will take me longer and easier to develop him, so I'm ready to train him."
This paradigm hogged all the others later.
Corporate environment shift
"If I don't need to be told about the importance of communication, then I can do this work more efficiently from everywhere I like, without having to waste time moving around."
The industry of remote work has changed dramatically over the past 20 years. This is most noticeable in various methodologies being used.
About 20 years ago, when such approaches as Scrum and Agile were invented, a company's portrait was completely different: people who sat in the same office did not understand the value of communication.
It's been quite a long time when distributed work became popular. By this time, teams had changed considerably: developers themselves now understand the value of communication, people working remotely have become more self-organized and therefore many teams no longer need to be told the value of communication.
So, distributed work has boosted productivity and became the norm today.
About 20 years ago, when such approaches as Scrum and Agile were invented, a company's portrait was completely different: people who sat in the same office did not understand the value of communication.
It's been quite a long time when distributed work became popular. By this time, teams had changed considerably: developers themselves now understand the value of communication, people working remotely have become more self-organized and therefore many teams no longer need to be told the value of communication.
So, distributed work has boosted productivity and became the norm today.
This is a paradigm, which later became the number 1 reason for hiring remote employees.
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, that 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?
These initial benefits of telecommuting have been sidestepped as they were superimposed on a specific team portrait, that 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?
The vector is changing
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.
And more and more approaches are emerging that do not correlate with the concept of efficiency.
Here's a real example: we at 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.
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.
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
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.
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 Standuply has become very popular among distributed teams.
Standuply 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.
Check out Standuply as it may help you with challenges of remote work and save time.
Standuply 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.
Check out Standuply as it may help you with challenges of remote work and save time.
Based on my knowledge and on our interaction with Standuply customers, we understand that in the most successful distributed teams:
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 work format.
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 work format.
There should be no time concessions in a distributed 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 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.
The time it takes to perform work processes in distributed teams shouldn't differ much from that in a co-located team
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.
Managers provide remote employees more freedom
So, what do successful
distributed teams do?
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 how to overcome these pains.
Pain #1
Communication tips for remote teams
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.
To do this, you need to:
To do this, you need to:
Introduce more asynchronous processes
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.
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:
1. Transfer general team communications to asynchronous mode.
2. Reading summary, reading the problems, you can understand who the solution depends on.
3. And then you try to communicate live with these particular people, instead of communicating via email and instant messengers.
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:
1. Transfer general team communications to asynchronous mode.
2. Reading summary, reading the problems, you can understand who the solution depends on.
3. And then you try to communicate live with these particular people, instead of communicating via email and instant messengers.
Split up live remote communications
Pair tasks execution
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 a telecommuting, it's good to plan tasks that have 2 link sections that depend on each other so that a team could:
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 a 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.
Two main points:
- there shouldn't be many rules and;
- they should be simple;
Have a space for controlled chaos
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.
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.
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.
Organizing live remote communications
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.
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.
In a one-on-one virtual meetings, employees should be able to call on the phone from their work desks.
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.
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.
There must be a well-grounded infrastructure for team calls.
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 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.
Start with people who are present, or cancel it altogether
There should be 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%.
We keep records, prepare an agenda, send a follow-up
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.
Hire the right talent
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.
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
Establishing laws and rules when working remotely
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 the Standuply team.
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 the Standuply team.
- Respond to an asynchronous standup
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 a feedback: discuss it or send a some emoji so that everyone would know that the information was received.
- You need to indicate your schedule and report any changes in it
- If you're going to criticize it, then suggest something else.
- There is no individual zone of responsibility, but a common product
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
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 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
- If you started something – improve it
Rules and laws cannot be universal, that's why I'm telling about ours: they are exclusively peculiar to each team.
Pain #3
Save empathy, especially for a remote team
Empathy is an important factor for building a successful distributed team. In the very beginning, you need to recruit people with a high level of empathy.
You need to talk and remind them about it. Because in a distributed structure, you can involuntarily fall into a trap where people working remotely develop a false feeling that their virtual colleagues are doing nothing.
You need to talk and remind them about it. Because in a distributed structure, you can involuntarily fall into a trap where people working remotely develop a false feeling that their virtual colleagues are doing nothing.
Use multiple integrations for remote team collaboration
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.
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.
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.
Alternating pair work in a remote team
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.
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.
Offline meetings
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.
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
Establish mentorship culture in a remote team
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.
It is crucial for any person to develop in what he or she is doing. Achieving this without mentoring will be difficult.
It's important to make people understand that you're working with them in a mentoring capacity.
That is, you aren't just giving them tasks to perform, but you're working in such a way as to make the person realize that you're mentoring and training him so that he too could later become a mentor to someone else.
We recently launched a new Mentors platform in Standuply. The platform features the profiles of people who would like to share their experience with other people. Anyone can ask a question.
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.
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.
It is crucial for any person to develop in what he or she is doing. Achieving this without mentoring will be difficult.
It's important to make people understand that you're working with them in a mentoring capacity.
That is, you aren't just giving them tasks to perform, but you're working in such a way as to make the person realize that you're mentoring and training him so that he too could later become a mentor to someone else.
We recently launched a new Mentors platform in Standuply. The platform features the profiles of people who would like to share their experience with other people. Anyone can ask a question.
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
Ensure process consistency when working remotely
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.
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.
Handling expectations
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 a 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.
In distributed teams, people are the ones who give you a 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.
For example, an employee says: "I would like to develop in the area of marketing."
You reply: "OK, what can we do in the next three months to enable you achieve this?"
"I've long planned to take this course."
"Good. If you need time for this, go for it."
You reply: "OK, what can we do in the next three months to enable you achieve this?"
"I've long planned to take this course."
"Good. If you need time for this, go for it."
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 of 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."
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 of 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."
You meet three months later, and you ask, "Have you taken the course?".
"Oh no, I didn't get around to it."
"Oh no, I didn't get around to it."
Pain #6
Sync time and goals with everyone working remotely
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.
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.
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.
Time synchronization
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.
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 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.
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 remote 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.
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 remote 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
Avoid unnecessary control when working remotely
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.
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.
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.
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.
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 Standuply, 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."
When I first came to Standuply, 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 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 give 80% successful. In order avoid engaging in primitive micro-management, it is better to recruit self-organized people who can calibrate themselves working remotely.
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 give 80% successful. In order 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 paartners. 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.
If they overestimate their prices, we will overpay them once, but then we'll simply stop working with them and find other paartners. 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.
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.
Made by Standuply, a must-have tool for remote work.
Standuply automates management processes via Slack and brings experienced mentors on board for 50,000 teams.
Process AutomationStanduply automates standup and other Agile meetings via Slack.
Check it out.
Team EducationYou can find and talk to industry-leading experts in Standuply. Browse mentors.
Process AutomationStanduply automates standup and other Agile meetings via Slack.
Check it out.
Team EducationYou can find and talk to industry-leading experts in Standuply. Browse mentors.
That's all, folks. Thanks for reading.
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.
Get the whole guide in a PDF file to read it later.
Enter your email where you want us to send it.
Enter your email where you want us to send it.
We never spam or sell your data. By clicking you agree to our Privacy Policy.