Some writing about how I manage remote teams, and what you do if you're starting out remote-working or in a beginner team.
I trust you to do the work we hired you to do. I expect you to behave as a member of a team:—not just a team of developers, but including everyone else involved in the work—and all the frequent communication and teamwork that involves, whether it be meetings, calls, chat or tickets. We are not a group of solo workers, but work in interdependent groups, all with different strengths that make us better than the sum of our parts.
I don’t care particularly where you do the work. I trust if you’re co-located that you take into account the needs of the team, and that if you’re changing expectations (e.g. being home instead of in the office) then you’ve run that by your team. You don’t need my permission, but you need cooperation from your team or you’re not respecting your team.
I expect you to actively communicate—more than you think you do when you are co-located. I expect your enthusiastic investment in all the frequent communication and teamwork involved, whether it be meetings, chat, tickets or writing documentation. This applies whatever your location. We have a cornucopia of excellent communication tools: mobile phones, email, Slack chat and calls, Skype chat and calls, Zoom etc. We also have many task management tools that you can use to communicate about your work. I expect everyone to use the agreed-upon tools to communicate with their team, stakeholders, customers and peers. I expect you to check in with the groups you regularly communicate with, but only as much as I expect it of everyone on the team, as their usual way of working.
In exactly the same way you do now: listen to the feedback of your peers and colleagues. If they’re surprised or disappointed by something you’ve done, take note. Check in with those that might be affected by your remote-working decisions. Check that you are purposefully treating all your colleagues with respect.
If you report to me I will also give you feedback on your behaviour in our 1-1’s, in exactly the same way I would wherever you were working. If your choices are having a negative impact on me, I’ll tell you. If I hear it’s having a negative impact on your team, I’ll tell you. If your needs come into conflict with the team and you haven’t been able to sort it out among yourselves, then there are friendly processes for working that out and we’ll try those.
Working on a remote-supportive team is more challenging than working in a purely co-located team, but there are benefits to working in a remote-supportive way. I expect a default attitude of "remote-supportive" from my teams, whether members are work-from-home-today, fully remote, or visiting another team. In a remote-supportive team, where you are physically located should have very little impact on your way of working.
Despite having high expectations on teams to behave in a remote-supportive way, I acknowledge how difficult it is to start remote working without some experience of it, and nigh impossible to do without a supportive team. Getting a team to that place will take time, practice and support.
Some explanations then:
This can include situations like:
Different situations will mean different amounts of attention being paid to communication (e.g. while travelling it makes sense to skip meetings that you can catch up.) Whereas someone working from home needs a team that includes them in discussion and decision-making, from planned meetings to ad-hoc chats.
If you're just starting out with remote work we'll connect with you someone (or even a whole team) who is comfortable doing it, and talk to you and your team about how it'll work.
There are a few expectations that are common to our remote-supportive teams:
The lengths of time above (and what “reasonable” means) is a shared team understanding. If you aren't sure, make it clear with your team. If you think the team isn't in agreement with what you want, make that clear too—I'm happy to help with clarifying these standards.
If you're working from home on a fixed schedule be sure to ask about:
There are also counter-productive things you should try not to do e.g:
There are some basic expectations to have of your remote-supportive team:
These mostly come down to being in the habit of being both considerate of non-co-located team members, and keeping up co-location-like communication behaviours. Getting this right is difficult though, especially if the team has never worked like this. It takes time, practice and team members openly sharing feedback about improving. This is especially difficult if only some regularly work remote; their voice may need amplifying.
This is a bit of a segue into how healthy team culture supports remote working.
The whole team succeeds by everyone supporting the culture of the team. It is not so much about details like which tools to use and how. The points below apply equally to an entirely co-located team: a healthy team works to maintain a healthy culture.
There needs to be general (even explicit) agreement on how the team communicates outward and at what frequency—to local teams, to stakeholders and customers. From answering questions in chat (or email) to updating tickets (and in what format.) Consistency reduces stress and misunderstanding.
Processes are often discussed in team meetings, retrospectives and 1-1's. It could be useful to document them for your team, and especially help new team members or outside contributors.
Healthy teams promote a culture of continuous inspection and improvement. If you document a set of rules and don’t re-evaluate them they will get stagnant and irrelevant as the landscape changes, while the unwritten rules nevertheless keep changing, causing tension. Continuous Improvement is most effective when seen as a daily part of work and not as a separate activity, and there are ways to support that (like Kaizen boards, CI meetings, etc.)
These discussions are also often had in team meetings, retrospectives and 1-1's.
A remote-supportive team respects all team members (no matter their location) including team members from every other discipline. A team is never really homogeneous, and will include roles like developers, designers, testers, project managers, business analysts, managers etc. Working for the benefit of the team is more important than working for the benefit of one discipline.
This might mean you find yourself writing documents, updating reports, or communicating in methods that are of little direct benefit to you, but benefit other members of your team.
The points above are ones I believe are vital to healthy teams. The team you are in might have different values.
