Building (Remote) Team Culture Pt. 2

December 01, 2020

Following up on a previous note, I came across this post listing a set of criteria for fairly comparing in-person and remote work. The criteria are:

Belonging and cohesion
Communication mode
Work life balance
Diversity
Talent availability

Out of these criteria, two that I am working on improving within my own team are numbers 1 and 2. This is not to say the others are not important…I only have so much time.

Belonging and cohesion

The trust that comes with highly-cohesive teams where members feel like they belong is incredibly important. Trust enables team members to ask the challenging architectural questions, to call out a design that needs serious iteration, or to raise sensitive opinions about company processes. In the world of high octane product development, trust is what enables teams to move quickly and to experiment without fear of judgement when failure is encountered.

The author of the above post says to ask “How is a sense of belonging fostered?“.

I am contemplating asking this question of my team every retro - get them thinking of ways to encourage cohesion and trust.

Communication mode

Quality communication ensures context is being disseminated among the team and yields serendipity (what the author from above refers to as “fortunate discoveries”). The more your team is communicating (effectively!) the higher probability one your teammates will stumble upon the solution to a bug that’s been in your backlog for weeks. The more you pair with the junior members of the team, the more context of the codebase and business rules you share, the faster these newer members will be able to contribute to bigger and bigger initiatives.

I have found that setting dedicated time to pair program, discuss architecture, or simply talk shop (outside of regularly scheduled 1:1’s) has been extremely helpful in this case. One teammate and I have 45-minute meetings scheduled at the end of every Monday, Wednesday, and Friday for this exact purpose. Setting these meetings felt awkward at first, but having worked this program for a few weeks, I wish we had implemented it sooner.

As a team, we have also established bi-weekly “dev huddles” where we get together to debate architectural decisions and discuss requirements. This has been great in sharing knowledge among the team. It has helped highlight where we need to improve, and is helping all of us grow. I hope to expand the agenda of these meetings to include technical demos where members do a deep-dive on a PR.