The goal of building a healthy remote team culture is to ensure that each team is supported while working for an extended amount of time in different locations. While the technology and tools have existed for some time, the culture and practices do not come easily to most people used to co-located environments. Building a culture of trust in virtual settings takes a considerable amount of intentional effort from leadership to set up these norms virtually.
What is remote team culture?
Once you become a part of a distributed team, you realize that culture does not evolve organically as it seems to in co-located offices. Ping pong tables and nitro cold brew become less important. Culture with distributed teams is about trust, clarity of communication, and how the team works.
Learn more about cultural dimensions and organizational culture types.
Common fears of remote teams
A lot of the resistance I get from leadership and even individual contributors about working remotely is that they will struggle with finding ways to collaborate. The belief is that teams need the ability to naturally collaborate together at all times. Thus, removing the ability to spontaneously share ideas would lead to silos and isolation. The reality is that this results in forcing teams to co-locate in open offices. Collaboration may go up, but distractions will also impede focus time.
Companies rarely have one office in one city
Dig into how open offices affect how UX designers work.
Set expectations for team culture
Work with your team and extended product team on how you need to work. Regularly discuss what is working and what is not working. Give each person and/or team that you are working with the chance to talk about how they want to work with you.
Read about implementing Agile practices for a UX team.
People dictate the process
People come first, and they should determine the process. It is not the other way around. When one team’s process imposes on how you expect to work, then you should re-evaluate it. We have recently gone through this with my extended product team. The design team felt pressure to keep up with all of the demands for designs to support development. The small design team of five supporting a development team of 50 had reached its limits. So, the design, development, and product management leads worked together to re-evaluate how we determined the process for requesting designs and prioritizing requests.
Create a space to communicate needs
If you have a small, co-located team, you can do this quickly. When I was leading a research team responsible for work mostly based in Austin, TX, then we were able to connect within the same blocks of time. Now, that I am leading a team in Dublin that is supporting developers in Canada, we have to be conscious of when we can all meet.
To help with that, design, development, and product management keep a standing meeting called “3-in-a-box” where we discuss things that come out of our retrospectives.
Show your face. We get a lot of cues on communication from our expressions. This makes it easier to connect on a personal level.
Connect face to face
While it may not be possible to meet in the same physical location, apps like Zoom and WebEx make it possible for a lot of people to gather in a virtual meeting room. Turn on your camera. An audio-only conversation leaves out all of the communication cues from one’s facial expressions, posture, and hand gestures. Showing your face will help you connect with the person on the other side of the screen.
Move around
Get up and move your body around. In agile standup, we encourage everyone to stand up and communicate their work status while doing light exercise. People have fun in what would have been a boring meeting.
Add one element of fun
Regular meetings can be routine to the point where people will zone out. We found that bringing an element of fun in each meeting can make the time more rewarding. For our weekly status calls between Austin and Dublin, we have chosen one thing from each team member’s lives to bring into the meeting.
Here are a few examples.
- Show your workspace
- Tell your favorite knock-knock joke
- Show your favorite kitchen utensil
- Devulge one fact about you or the World that would shock people
Standardize how you use the team uses tools
Product teams will have standard tools for email, chatting, project management, file sharing, meetings, design, and code. How different teams or even members of one team use these tools are not always the same. Without modeling behavior, I have seen teams share design files across email, chat, and project management tools, but they will not document any of the conversations or decisions in any consistent way. This leads to confusion over changes, duplicate work, meetings to realign, and wasted time.
Tips on how my research team organized their work for other teams to consume.
Tools exist to help you
A mentor of mine reminded me that tools are useful until they are not. When they are not, then you have to evaluate if you are using them for the right purposes. The example I shared above shows that by not documenting decisions in the right tool negatively affected the work and product release.
Categorize tools and uses
Email: Scheduling meetings, communicating with clients, and reviewing communication from upper management. Use email when you need to document issues or changes with upper management.
Calendar: Schedule meetings with a description and a goal. If someone adds you to a meeting without this information, ask the meeting chair the purpose of the meeting.
Slack: Ongoing discussions on specific topics, quick chats one-on-one, and a place to put amazing gifs.
Zoom: Team meetings, stand-ups, demos, and formal presentations, and one-on-one check-ins.
Jira: Manage epics, stories, and sprints, document priorities, deliverables, blockers, and decisions, hand-offs, and completed work.
Box: Project files, presentations, and meeting notes.
Timing and tools
People on your team expect communication exchange and work updates within a certain amount of time. These expectations vary depending on the tools. Below are estimates for when updates on specific tools
Email: Respond within 24 hours if not on vacation.
Slack: Respond within 10 to 30 minutes if it is a direct message.
Jira story: Update every day and respond within 24 hours if the story directly impacts your work
InVision prototype comment: Respond within one to two days. Add comments to the relevant JIRA issue and tag your stakeholders.
Thinking about communication norms within the perspective of tools helps set expectations for the teams. Ultimately, people do not need to feel pressured to respond to every message immediately as long as communications are consistently in places they expect them.
Read the post on John Challis’ and balancing risks for location independence.
Time differences can be a gift
My design team, our developers, and our product managers are all in different time zones. I am based in Austin, TX and my design team is in Dublin. So, they are five hours ahead of development and product managers. If not managed properly, there could be a lot of waiting around and wasted productivity.
Asynchronous communication
Documenting questions, conversations, and decisions across the tools listed above do not need to happen with everyone present. Most teams embrace them as ways to communicate asynchronously and avoid downtime or needless meetings.
When it makes sense, I record short videos at the end of my day. Then I address the designer(s) that need to watch them. In the videos, I make sure I am clear with my question(s) and what steps the designer(s) need to take while I am asleep. The video exchange has worked well enough that the designers are starting to use them with developers when they have questions. In turn, the developers are making videos to explain their comments and questions on sprint stories.
Find ways to have fun with team culture
Meetings, emails, and Slack messages have their purpose. If you do a thorough job of defining the goals and expectations for your team, then you should also be able to see where the team can relax.
Create safe (digital) spaces
We have a daily team standup and check-in. There are no stakeholders or higher-level managers. So, we give it a fun, internal name like “Design Hootenanny.” This helps the team distinguish it from other more formal meetings. It also is a cue for them to share work, ideas, or issues not ready for a wider audience.
Make a Slack channel dedicated for nonsense
If you have large enterprise teams and multiple projects and initiatives, then you have a lot of Slack channels and conversations. Most of these are dedicated to work-related topics. I have also created a fun channel with every team I have been on. This is dedicated to “safe-for-work” news, movie discussions, TV, and the never-ending stream of gifs.
Closing thoughts
Separately, nurturing team culture and working productively in remote environments have their own set of challenges. Teams and leadership invest a lot of energy into both. Building a positive remote team culture must be a part of an intentional strategy. Leadership should recognize the challenges individuals will face working apart from a team’s physical presence. The team, in turn, should also build awareness of where they can grow with the added time and space for focus.
Sign Up Today
Get insights and resources in your inbox before I publish them!
