It is truly a difficult and emotionally exhausting time to be a manager. Even those who are used to managing remotely are having to navigate the shifting expectations and chaos of disrupted lives and disrupted businesses.

Of course, some people deal with that level of disruption by trying to increase control. Surveillance software is becoming increasingly popular, and there are regularly suggestions like just having video on… all the time… as you work. The thought of this gives me nightmares. The amount of time I have spent staring into space while writing this article is bad enough; imagine if there were witnesses.

Instead of trying to reinvent management from first principles, we can turn to other areas with experience navigating distributed teams with individuals managing competing commitments. Open-source software communities—which also are remote communities connected by the internet—have long included the role of community managers. These are the people who tend to the health of the community, by maintaining communication, motivation, efficiency, and engagement. It’s a well-honed practice that remote managers can learn a lot from.

Leslie Hawthorn, a community engagement expert within Red Hat’s office of the chief technology officer, offers tips divided along three main themes: creating community, defining the rules, and making decisions. We spoke not long before the coronavirus pandemic began; there’s no doubt her advice has become all the more widely applicable since then.

Creating community

Leslie says:

When you think of how and where to build community, start with a simple list of goals for that community. Are you trying to help uplevel a project’s visibility and adoption? Keep people better informed so they can be third-party advocates for your efforts? Build connections with collaborators? Sometimes the most important function of a community is to provide like-minded people with a structure in which to get to know one another better so they can best work together.

Managers often build the obvious community: their team. They forget the non-obvious aspect of community. For example, a group of managers should also be a team; they are the people best able to support each other. Then, you need to look outward—the team doesn’t exist in a vacuum. There is overlap with other teams, and other stakeholders. How do you include them in your community? How do you communicate? Make them feel welcome? Connected?

In a remote context, there’s no concept of “the team next to yours” unless you build connections to them. There are no peers you regularly just happen to have lunch with; you need to create those kinds of interactions deliberately. Building connections with other communities within your organization is crucial for giving your team the context it needs to be successful, and recognized as such.

A pandemic is an interesting mix of people who are over-socialized (such as people with families denied their usual down or alone time) and under-socialized (like singles living alone denied their usual social interactions). While there is a certain amount of camaraderie and shared experience that may come from those who navigated the switch from office to remote together, what about new people? Think about the experiences of your team, and outline the goals that you might want to achieve. Then, you can come up with options that might help support those goals. Remember to be deliberate about what should be async, and what should be opt-in (or out).

Defining the rules

Leslie says:

Most groups start off organically and adopt norms as they go along. While that’s natural human behavior, issues can arise when a group’s norms are implicit rather than explicit; relying on tribal lore to keep your group healthy is a great way to make things dysfunctional. If something matters to your team, your organization, your project, write it down and make sure reading it—and contributing to it—is a part of your onboarding processes.

In an office, a lot of expectations about work habits can end up being implicit—we do our standup at 10am and we’re all expected to be around by then—but we never actually say it. We have lunch together every Friday but no one organizes it, it just happens. Norms are much harder to transmit in a distributed context, and so it’s all the more important to communicate them explicitly (as an example, at Automattic we publicly shared our team member expectations).

However it’s important to remember that rules are just a baseline. The minimum. On top of them we build our rituals. For example, yes, we communicate. But how do we communicate? What do we share and when? Clearly defining and sharing team rituals helps people understand what to expect, and why. Rituals might include sprint updates, monthly stats reviews, or the way we welcome a new teammate.

As we accept that the way things are now is likely to be normal for a while, it’s a good time to start writing down the norms and rituals of the team—and considering whether those norms and rituals serve us right now. Perhaps the 10am daily standup was a norm, but now is the time to switch to an asynchronous, text-based standup, as people start their day at more variable times. Perhaps the Friday afternoon show-and-tell was a norm, but it’s time to move to something more flexible, like sharing videos in a thread. Starting a conversation with the team about the way you’re going to work now can help everyone work toward acceptance and support of what is.

Making decisions

Leslie says:

In a community setting, you simply cannot over-communicate the why of a particular choice. Explain the decision that needs to be made, what is prompting the decision to be brought forward, what stakeholders are impacted, how they were consulted in the decision process, what success criteria were chosen, and why the chosen solution was adopted. Make it very clear where the discussions that influence the decision take place, how the decision-makers want to get feedback, and how individuals can air their concerns in a productive manner. It is OK to disappoint people with a decision, but surprising any community with a particular decision leads rapidly to disengagement.

Skewing toward communicating in writing sets a standard for transparency—a lot more people can expect to read a document than can usefully (or even possibly) attend a meeting. It also makes it much easier for people to refer back to decisions after the fact. When people expect that level of insight into what’s happening, they need (even more than usual) to know how decisions are made, and to understand how they can influence outcomes and register their input. People have a universal need to be heard. It’s not enough to listen, you need to make yourself available and accessible. There is no “management by walking around” when presence is not physical; you need to work harder to make your presence felt.

You also need to communicate more and more to build the buy-in. Silence is not agreement. It’s easy for people to ignore things or create an unintentional echo chamber in a remote context. Clearly communicating “the why” in writing helps it work down the chain. When you set that at the manager-of-managers level, you support your managers in communicating inline with that.

If remote management is new and forced upon you, you may not be used to communicating as much in writing. This takes practice and feedback to improve. Ask someone to read your drafts before you share them. Ask questions like “What did you take from this?” and “What would have made this clearer to you?” And then use your 1:1 meetings to understand how the communication landed, and follow up with clarification where necessary. Hold each other accountable. Before scheduling a meeting, ask “what part of this should be in writing instead?” (This has the added benefit of reducing the overall time you ask people to be on video, which is harder to focus on versus an in-person meeting).

Recognize that this is a gradual shift that will take time, and act accordingly, where you try things and accept that not everything will work (at all, but definitely the first time).