Performance Management

This post will summarize my personal learnings for managing performance in both a distributed and non-distributed environment. I recently hosted a discussion on ‘Remote Performance Management’ with engineering and product leads at other companies (through Enrich) and these were some of the topics we covered.

Performance management in a distributed environment is very similar to working in person, except you need to rely more on measuring actual contribution, and more written communication. 

It can be very draining for a team, and for managers in particular, to deal with performance issues on their teams. If these are not dealt with quickly, they can fester and affect the entire team. It is important to have a clear path to gather data, diagnose and solve for the productivity and for the ‘health’ of your team.


Start by gathering data to figure out if there are performance issues.

Your Gut: Most of the time, you know if someone is performing well. Trust your gut and use it as the starting point. Write down examples of issues you observe in a document so you can spot repeated patterns. In a distributed environment, it can take longer to calibrate your gut – you can’t ‘feel’ the energy of a person or a team as easily, so you need to rely on the output of teams. The more teams work out in the open (public by default), the easier it is to understand their output.

Team: Ask for feedback from folks who interact with the person closely – peers, direct reports, other functions. This can be more casual or part of a broader discussion if you don’t want to cause ‘alarm’. You can also ask your HR rep to help gather feedback for you as well. 360 degree feedback tools are also really valuable for managers and teammates to give feedback on each other.

Data: Try and figure out objective measures of output – communication metrics (e.g. Slack stats, public posts and comments), projects delivered, GitHub commits can all help paint a picture of productivity. It’s important not to use these metrics as the starting point for performance management – they are simply a useful tool to help validate or invalidate hypotheses. If people feel like they are being ‘watched’ they will not like it, or try to game the system which is not where you want them to focus.


Once you have established there is a performance issue, the next step is to unpack the why behind the issue.

Capability vs. Effort : I start by trying to understand if there is a capability problem or a motivation problem and use this simple matrix. Folks who are high capability and effort should be rewarded, and folks who are low capability and effort should be transitioned out of the company quickly.

This image has an empty alt attribute; its file name is impact_effort_matrix_brainstorm_-_brainstorm.png

Manager / Team Fit: The individual may just not fit in well with the team culture or have a good rapport with their manager. Once a manager has ‘lost faith’ in someone on their team, it’s very hard to regain faith without a team switch.

Project Fit: The individual may not enjoy or be well suited to the type of work they are doing. This person might have a capability or effort issue, and in most cases this requires a move to a different role or to a different project. 


Once you’ve diagnosed the issue, the next step is to figure out a path forward. Many new managers simply avoid having these hard conversations because they are awkward and can be difficult.

Communicate clearly: Communicate performance issues clearly with the individual and then lay out a clear path forward with areas for improvement and timelines. This step comes before a formal performance improvement plan (PIP) which is more serious to developmental feedback.

Termination: If you have reached the point of termination, then be clear, direct and kind. Schedule a short in person meeting or video call, and get straight to the point. Often HR is involved in this call, and at some companies they are responsible for this meeting.

Team / Role / Project switch: If the individual is new to the company and has performance issues, and you suspect they are in the wrong role, wrong project or have fit issues with their current manager or team then you should allow one switch to give the person another shot. If the performance issues are persistent, then they should be let go from the company.

Permission to leave: Often, an individual was the right fit for the company or for a role at a point in time but given the stage of the company’s growth, or a shift in the nature of the work this person may not be a good fit any more. As a manager, you can give this person the ‘permission to leave’ and they will be able to find a place outside your team or company where their skills are better suited. It’ll be better both for the individual and the company.

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.


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.


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 –