Managing Distributed Teams

At Automattic, I lead a fully distributed product development and engineering team. This post will cover some of my personal practices for managing teams and if/how this is different in a distributed environment. These practices are probably more useful to newer managers running distributed teams for the first time.

I recently listened to Matt (Automattic’s CEO) and Raj Choudhury’s (Prof at Harvard Business School) discussion about the future of distributed work and the ‘Work from Anywhere’ movement which were the inspirations for writing this post.

DISTRIBUTED PRACTICES

The principles of managing a distributed team are the same as managing a team in person, but a few of the practices are different. People are still people, whether they are sitting right next to you or halfway around the world.

Here are a few practices that I’ve found helpful:

Trust: Start from a place of trust. Assume positive intent in written communication, and assume your team is working and trying their best regardless if they are sitting right next to you or they are working from home.
Expect Asynchronous Communication: Don’t expect a response immediately, even over chat tools like Slack. Learn how to use Slack asynchronously, and set the same expectation on your teams. I deleted Slack from my phone (because I would miss things), and close Slack on my computer when I want to remove distractions. I respond to messages in batches, and use the reminder feature if I need to come back to something later.
Focus on Output: Don’t falsely assume someone is more productive because they work longer hours (even when working in person). Focus on the quality and quantity of the work produced by an individual vs. the number of hours worked.
Clear Goals, Roles, Expectations: Develop clear goals and a shared understanding of the ‘why’ behind these goals, roles and responsibilities and what is expected of managers (and their teams) in terms of output. Extreme clarity here leads to more empowerment, not less, in my experience (one of my takeaways from Essentialism, by Greg McKeowen, which I recommend).
Project Kick Off: For new projects, with new groups of people working together or working across different teams it’s good to get alignment right at the start. I suggest experimenting with a kick off call with project stakeholders and participants followed by a written summary. The call may be difficult to schedule, and less conducive to working across time zones. but project kick offs are infrequent enough that I think these calls are worth it.
“Grab a Room”: If you sense a real time conversation is going off the rails in Slack and if it was in person you would ‘grab a room’ to chat it through, do the same over Zoom for 10 minutes. It helps if your team is not inundated with regular meetings so this can happen more seamlessly. I personally also leverage ‘office hours’ to skip level meetings a few times a quarter.
Hiring: When hiring folks who are distributed, put extra weight on the quality of their written communication and their ability to work in a self directed manner. Documentation becomes even more important in a distributed environment.
Feedback: Give frequent, specific feedback both positive and developmental over Slack or in your regular 1x1s (both personal and project related). Write up more thoughtful feedback every 6-12 months. We all have recency bias in the longer reviews, so I keep a record of the small pieces of feedback in a running document. At Automattic, we have a tool called ‘Kudos’ which allows folks to send public thank you messages to a few colleagues a month. It’s a nice way to show appreciation.

MANAGEMENT DURING A PANDEMIC

Managing a distributed team during a global pandemic (Covid-19) requires greater care and empathy. Many folks who are working from home had it forced on them and it may have felt jarring. They may have additional responsibilities of looking after their children, caring for sick/old folks or dealing with loss either directly or indirectly. There is also a psychological toil that is hard to quantify, and simply not knowing when we will return to “normal” can weigh on people. As a manager, simply recognizing these issues explicitly and then being empathetic to their circumstance can go a long way.

I would encourage your teams to take the time they need for self care, and be accommodating to more flexible hours. If individuals or teams are going to experience a productivity hit, adjust goals accordingly (and publicly) as long as your business can afford it. It will pay off in the long term with improved happiness, productivity which will translate to better employee retention.

I’ve noticed extra output from some folks who are now simply working more to fill the extra time they have, and less output from others who are more affected. Teams realize and recognize this asymmetric contribution and much like any small community there are times where we need to contribute more to help out our colleagues. That’s ok, as long as it’s not permanent.

For more on this area check out the companion post around managing performance.

This series from Greylock is excellent as well – https://greylock.com/workfromanywhere-podcast/

A few Management Frameworks

As a manager or manager of managers of product development teams, it can be hard to focus on the right things and to make sure that you’re making progress on your ever growing list.

To help others overcome the same challenges, I am sharing a few of my personal frameworks that have helped me focus better and be more productive over my career:

1. Understand Product and Team Health

I wrote a separate post about this here but one of the most important things you can do when managing lots of products/teams is to understand the health of both the products and the corresponding teams. I do this by asking the following three questions and tracking this over time.

What do the metrics say? Metrics are impartial measures of how the product is performing on an absolute basis and trending. Having valid, high quality data sources is essential.
What does the team say? Most of your insight will be from the team lead, but make sure and also talk to team members from time to time so you can further validate (or invalidate) the insight from the lead.
What do our customers say? Talk to customers, talk to customer support, get structured data on customer pain points.

Combining the insight from these three sources has helped me improve judgement around what we should build and also help with designing better teams.

2. Segment your work

I segment all of my work into three buckets:

(10-20%) Set of things that only I can do (or want to do) myself
(60-70%) Set of things I can structure and review
(10-20%) Set of things that need zero oversight or someone else can do better

This allows me to spend time on the areas that I can have the most impact while making sure that I don’t drop the ball on all the jobs that need to be done by the organization.

Over time, if your objective is to make yourself redundant you should aim to move more and more tasks from category 2 to category 3. This is also a good sign of a team that both well assembled and performing well.

3. Track your time

Each quarter I write up my personal goals (Primary focus, Secondary focus, Observing) and share them with folks I work with very closely.

As part of this exercise, I reflect back on the previous quarter and break down my allocation of time and highlight anything in my list of goals that did not get done.

I then take all the tasks that I don’t think should be on my plate going forward (not the right priority, or someone can do better) and plan to transfer them to someone else for the next quarter as part of my personal planning process.

This has helped me be more deliberate and focus on the things that matter.

4. Get buy in for projects

People are the most important asset in any product development organization and high performers do not like to be told what to work on. One of the most important things that managers of product development teams have to do is get buy in from their teams on the projects they work on.

In the ideal situation a specific job to be done matches both the interest of a team/person and their capabilities. In other situations you’ll need to get buy in from teams to take on projects, and the best outcomes are always situations the team is motivated to work on the project (ideally it’s even their idea).

Depending on the person or team and their preferences, it’s important to phrase the project in the right terms:

Do it for the Company: This project the most impactful thing you can do for the company’s growth – logic and long term thinking.
Do it for your Team: This is the most impactful thing you can do for your peers or your team – community and selflessness.
Do it for Yourself – This is the most impactful thing you can do for your development/career – drive and growth.
Do it for Me: This is something I need you to do for me – strength of the personal relationship. This line should be used sparingly, because it can be relationship damaging and/or selfish.

These are a small subset of tools that I’ve found personally helpful as I’ve worked with product development teams over the last decade and hope you do as well!

Insight from independent sources

In my opinion, one of the hardest parts of product and general management is drawing insight from the right sources to determine ‘product health’ to identify where to focus, especially when managing multiple product lines.

In my experience I try pull data from three independant, uncorrelated sources to inform where I should focus my effort – the data, the team, and the users:

Data: Design dashboards that give you the metrics at the right level of detail on a daily/weekly/monthly/quarterly basis. Be able to translate data into concrete hypotheses and insights.
Team: The general manager (GM) or product lead of the business is your main source of information, but make sure to spend time with team members and other functional leads as well, so you can validate/invalidate what you hear from the GM. The broader team is also an incredibly strong resource for ideas for new features.
Users & Customer Service (CS): It’s important to maintain empathy/understanding of your customers, even when you’re a step removed from the product.
- On a regular cadence (e.g. weekly), spend time reading user reviews, blogs, forum posts etc.
- Get quantitative and qualitative information from the CS team about what users are saying about your products over customer service channels, either through a short meeting, or a list of top 5-10 issues each week.
- Spend time actually interacting with customers, and responding to them (directly or on forums for example).