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.

1. GATHER INFORMATION

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.

2. DIAGNOSE ISSUE

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. 

3. IMPLEMENT CHANGES

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.

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/

Manage Energy, not Time

I read the HBR article in 2009 called ‘Manage Your Energy, Not Your Time‘ and it really resonated with me. I’d felt similarly for a long time but did not have a framework to describe it. I’ve since shared this article and this method of thinking with dozens of colleagues and friends and many have found it valuable.

I find that creative individual work or complex problem solving goes poorly when forced into a pre determined time slot. This kind of work is what highly compensated knowledge workers get paid for and we are often forced to do this during 9-5 and in our office environment.

There are three main takeaways for me and how I’ve applied it to my own life:

  • Understand my own energy level before starting a task, and if I’m not in the right mindset switch the task to something that requires lower energy (e.g. submitting my expenses, or other administrative tasks) or take a break to restore energy.
  • Understand what drains energy and what generates energy – a nap, some exercise or a walk with a podcast are all restorative for me personally and so if I’m unable to get something done, instead of staring at my screen I’ll often do one of these and come back more refreshed and ready to complete the task at hand.
  • Work on creative or complex tasks during high energy times – I usually feel most creative and productive in the mornings and try and do most of my IC work during the mornings. In my current job it’s challenging as I work with many folks in Europe so I block out a few mornings a week without meetings.

When you’re a people manager or have meetings that you have to attend for the benefit of others and (not yourself) you often have to compromise on these principles because you’re optimizing for a larger group which is rational but not always pleasant if you’re low energy.

It is much easier to apply these principles a distributed environment (e.g. at Automattic where I work) as we can work from wherever (and mostly whenever) we feel most productive and, in my opinion, is one of the best advantages of distributed work over a traditional office.

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:

  1. (10-20%) Set of things that only I can do (or want to do) myself
  2. (60-70%) Set of things I can structure and review
  3. (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:

  1. Do it for the Company: This project the most impactful thing you can do for the company’s growth – logic and long term thinking.
  2. Do it for your Team: This is the most impactful thing you can do for your peers or your team – community and selflessness.
  3. Do it for Yourself – This is the most impactful thing you can do for your development/career – drive and growth.
  4. 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!

Early thoughts on distributed work

I recently joined Automattic which is a fully distributed company. We have ~900 people (in all functions) working in ~70 countries, with no central office. We are one of the largest, if not the largest fully distributed company in the world.

I wanted to share some of my thoughts about the advantages and challenges of distributed work after two months – both strategically and from a practical implementation/execution perspective.

One very important principle about Automattic is we are set up to be a distributed company and all of our internal process is designed with distributed teams as the default state. This way, folks that are remote are not ‘2nd class citizens’ but are the core of the company.

Advantages

  • Work from anywhere: Our people can live and work from wherever they want, which ultimately leads to happier employees that stick around longer.
  • Work when most productive: People can work when they feel most productive and manage energy, not time (one of my fave articles) taking into account their personal constraints (e.g. family) into their schedule. Managers, however, have a bit less flexibility.
  • Custom work environment: Some folks like others around, others prefer a quiet environment, others like to move around. At Automattic, people can set up their environment to suit their unique style which is very hard to achieve in a traditional office.
  • Everything is documented: We document everything using our internal blog system (called P2) and folks can always go back and find out the ‘why’ behind decisions. This is very powerful.

Challenges

It’s worth noting that these are currently a set of initial observations for challenges, and I’m sure there are a number of good solutions to them which I’ll be actively thinking about as part of my work at Automattic. 

  • Onboarding as a new employee: Onboarding requires getting to know the right people (and building trust), learning the right systems, and developing the right judgment to know where to focus. Doing this remotely can be a struggle.
  • Building relationships: It’s easier to build bonds with people in person. Nuance is lost over Slack and Zoom and there is no substitute for time in person together. At Automattic, we have meetups to help build relationships but it increases the amount of time and ‘deliberate-ness’ required to get to know your colleagues.
  • Finding product-market fit: In the earliest stages of finding product-market fit, iteration can be slowed down because of async, documentation heavy nature of our work especially if vision is shared among different people. This is an area where I feel there are lots of areas for opportunity to improve with more frequent synchronous interactions. 
  • Changing direction: It’s much harder to get alignment and inspire towards a different strategic direction via text and video. It’s harder to recreate ‘energy’ and velocity in a distributed environment.
  • Separating signal from noise: We are a large team (900+ people) and there is a lot of content that is created daily.I’m spending about 15%+ of my day parsing through posts and comments to figure out what I should read, participate in, or make decisions on and as a new person it can be difficult to know where to focus. More experienced distributed workers have similar issues, but they are less pronounced, which shows that this is a somewhat learned skill.
  • Time zone management: It can be difficult to run teams across different time zones but there are also opportunities to increase velocity by folks working over a 24 hr period.

Individual Contributor to Manager

In my last role at Pocket Gems, I transitioned from an individual contributor (IC) to a manager and then to a manager of managers. It was a hard transition as we grew from 5 people to 150 in less than a year and a half, but I learned a lot along the way. I was directly responsible for a team of about 10 -15 product managers and indirectly responsible for a multi-function team of about 120 people.

In order to transition from an IC role to a manager role, it’s important to be a functional expert so that you can win the respect of the people that you manage. If you’re not a top quartile functional product manager it’s very difficult to progress into a management role. When you transition from a management role to a manager of managers the skill set is completely different. Your skills as an IC become less relevant and your role evolves into a strategy, staffing, prioritisation and coordination role vs. being a great IC. You need to create systems to be able to get the right information at the right time through data, people, and process. This then informs strategy, which leads to prioritisation and staffing.

I personally found the transition from IC to a manager of managers role quite depressing. I realised that I gained fulfillment from completing tasks (running analyses, designing features etc) and I was doing very little of these tasks any more. I became much more comfortable in the role after I did a few things:

  1. I read the High Output Management and the Hard Thing about Hard Things
  2. I kept 10-20% of my time to work on IC type projects from running a particular analysis to designing a new feature that I wanted to test.
  3. I gained fulfillment from developing others and seeing them grow as product managers

I do think the best leaders are able to work along all the dimensions of IC, Manager and Manager of Managers. People who perform well at all these dimensions scale particularly well at growth startups and are a great fit for leadership roles at early stage companies.

There are a few other things that I learned, mainly by screwing them up a few times and dealing with the ramifications of my screwups. These mistakes can permanently break trust with people, create really strained working relationships and are hard lessons I learned along the way.

  • Genuinely care about people on your team. There is no substitute for authenticity and your team will be able to tell if you’re apathetic towards them.
  • What you say as a manager is amplified because of your position – you have to be even more thoughtful about what you say as you can distract the team unnecessarily and also affect morale both negatively and positively with even a few words.
  • Never take credit publically for yourself (give it to others) and always have tough conversations 1-on-1 privately. Building loyalty with your team will pay for itself 10x in the long run.
  • Great managers never complain about their team. They understand what the individuals are capable of, set them up for success and then manage expectations upwards.
  • Put yourself in the other person’s shoes – figure out what motivates them, what they care about and manage to those things. This should be one of the first conversations you have with someone new on your team. I often talk about my motivations first in order to break the ice.
  • Make each person feel respected and valued regardless of their role – if someone’s role is sometimes more ‘thankless’ (e.g. QA) it’s even more important to celebrate wins.
  • Focus on process to make things better vs. placing blame on individuals (very easy to do, especially in the heat of the moment). It’s very easy to damage relationships permanently by doing this repeatedly.
  • Deal with personel/performance issues expediently. The person affected and the rest of the team will appreciate this in the medium term (but often not in the short term). Dragging your feet here will lose you respect at all levels of the organisation.
  • Learn how to influence. People respond much better if they feel like they came to the conclusion themselves vs. forcing the outcome onto them. There are lots of levers for influence and using these levers thoughtfully is an art e.g. do it for yourself (own goals), do it for the company, do it for the team, do it for me (manager).
  • Be transparent with your team. If people have context they will perform better. This does not mean sharing noise (information that is not a useful signal or irrelevant) with the team; a common misconception when talking about transparency.

I am learning more every day in this capacity, and writing these learnings down helps me systematise my learning.  I hope that others out there find some of this useful as well.