Building effective distributed teams: series intro
Audience: Anyone leading or working on a distributed software development team keen to become more effective, motivated and fulfilled.
I’ve spent the last decade working full-time+ on a fully-remote healthcare startup, and stepping away of that particular mad plate-spinning exercise has been surreal. I originally joined the company straight from my own ed tech solo startup, so really, it’s been a very long time since I’ve been able to wake up in the morning without that threatening cloud of so many things to do!! 😱 looming over my head.
Untangling a hard problem triggers an urge to help others avoid it, and so I have scores of essays & articles that I’ve started over the years, but then set aside for more urgent tasks. Over the past few weeks, I’ve been taking time to read & reflect, firstly, and to revisit some of those notes.
Topics are all over the place, circling around remote software dev & management (my life for 17 years, now), branching off into other topics that interest me (technical or not).
But I’ll start with the most important one: building effective remote dev teams, founded on psychological safety & robust human feedback loops.
Why focus on psychological safety?
Everything else is secondary — if your team only functions because everyone thinks pretty much alike (for now), or a couple of powerful people race around forcing everyone else to march to the same beat, or you’re just lucky enough to have a few people who quietly clean up the damage from ongoing clashes & frustrations, then building a healthy, focused team needs to come first. A team’s creativity & energy can be easily burned off in politics, competition, resentment, anxiety, etc., and the scraps that are left won’t move the needle on business problems much.
This isn’t (just) my opinion. Google People Operations started by studying 180+ teams, 5 years ago, and concluded that “psychological safety was far and away the most important of the five dynamics we found — it’s the underpinning of the other four.” They’ve since published related tools and more findings over the past few years. Patrick Lencioni drew the same core conclusion in “The Five Dysfunctions of a Team” back in 2002 (still a relevant read).
Achieving it, though, is genuinely difficult, even more so in a diverse & distributed team.
I had an idea for how they might structure it, but… was I just supposed to interrupt them?
Exactly! Well… if you’re sure it’s a good idea. That call has 12 people on it — random tangents can add up to a lot of lost time.
But you don’t untangle communication snarls by forcing your existing team to use the “right” processes, or carefully following the 10 secrets of how to hire exactly the “right” people to compose a good team.
Here’s what you do need:
- Assume that everyone will make mistakes (leaders & mentors included), miss context, misinterpret… the team must have a clear map back to safe ground when interactions are going wrong, and problems mustn’t stay silent.
- Good problem-solving & root cause analysis is always more powerful (and less harmful to the team) than the mental shortcuts of blame and labeling people & situations.
- Diverse people make up a team, with varying preferences, habits, goals, histories, and strengths; there must be safe, active feedback loops for team members to learn about each other, correct missteps & empathize.
- Team optimization must account for “soft” outcomes and context as well, not just short-term work input/output — loss of trust, conflict, anxiety, stress & distraction even outside of work — but in a way that does not require people to share sensitive personal info, or adopt fake & unnatural new ways to interact.
- A team needs a transparent & respectful plan for the full life-cycle of a member — hiring or rejection, evaluation & ongoing feedback (including navigating disagreement & frustration), career path steps, and even how they leave the team.
- Good remote communication is harder, but crucial— natural social interaction is missing or changed, and active damage can easily pass unnoticed.
This is the baseline: mapping out the living system of the specific team and optimizing it for the real people involved.
A team then builds, together, on this foundation of good communication & psychological safety.
My angle and inspirations
- I read Nonviolent Communication, by Marshall Rosenberg, a few years ago. His base ideas definitely influenced how I think about communication, though I don’t follow the NVC method as-is.
- I’ve just finished reading Camille Fournier’s The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change — this is a great resource (I highly recommend it to everyone following a software engineering career path, even if they’re not interested in a manager track), and it was also hugely validating: there’s a ton of advice she gives that matches up with my own conclusions, some that goes beyond what I’d figured out so far, and I dearly wish I’d had this book 8 years ago, when I stumbled into tech management, with no experience, no mentors or manager, and never having experienced a well-run dev team, myself. 🙄
- Another recent read: Maya Hu-Chan’s Saving Face. This book can serve as a guide for Western companies working with Chinese colleagues & companies, but it certainly goes beyond that, and many of the mental models & suggestions in here would be useful to resolve issues I’ve seen that have no cultural confusion involved, whatsoever.
A note on content: real-life stories are valuable… but I’ll mostly avoid telling stories about other people, so I don’t discomfit past, present or future colleagues. Instead, I’m including realistic but fictional conversations. For example, neither speaker is wrong in today’s dialog, above; but there’s clearly a problem (…more to come on this).
I’m generating faces semi-randomly, with the Open Peeps collection, by Pablo Stanley, on blush.design. (awesome work, Pabs; thank you!)