How to think about performance?
A hard question with no easy answer
A conversation that I have recurrently with leadership in companies is about how to measure performance. In particular, for people outside of the technical teams, it is hard to assess whether the investment they are making in the team, which is usually high, is paying off.
One of the common mistakes I see while looking at this is to try to look at performance as an question with a single answer. I do not think there is one. When you look at your company and the team, performance must be looked at in different dimensions:
Company performance: one must have metrics that translate what they want to accomplish. Examples: a certain EBITDA, or revenue increase, or decreasing churn.
Team performance: how well this group of individuals are working together as a team.
Individual performance: how this one person is contributing to the team performance and perhaps (not always) to the company performance too.
The simplest one to measure is definitely the company performance. A lot of times what the CEO and CFO want to see is a clear number as an output. The question gets a bit more complex when you go down to the next items.
For team performance, I think DORA metrics do an excellent job at having an indication of performance. But there's no single number, there's no on or off switch. There are a few things to look at:
Change Lead Time - Time to implement, test, and deliver code for a feature (measured from first commit to deployment).
Deployment Frequency - Number of deployments in a given duration of time.
Change Failure Rate - Percentage of failed changes over all changes (regardless of success).
Mean Time to Recovery (MTTR) - Time it takes to restore service after production failure.
Translating those metrics to simple english: a high performance team is a team that is able to de facto deliver changes to production quickly and deliver such changes frequently, and when they deliver those changes to production, they rarely break production and when they do break production they recover from those failures very fast.
Having metrics about all this isn't that simple, so the first goal should be to be able to measure those things.
Last, but not least, individual performance. This one could be an article on its own. To simplify, I would split individual performance in three parts: (1) the work the person actually did, then (2) the commitment they've made to their team and manager and (3) the expectations written down at the company about what is expected of a person at that level and role.
Not all companies have (3). That said, (1) definitely happened as the person is working, and (2) as well because usually people do not go on a cave to decide what they should be doing. To make life easier, I would try to always write down (2). Humans have a heavy recency bias and tend to blur or forget things that fell behind in the timeline.
Over time, in particular when you're in a team with over 100 members, having job descriptions for each role, with expectations for each level is very useful, but doing it too soon might be an overkill. Never start from scratch. There are several companies who have done a good job at describing levels and roles and are generous enough to share those, Gitlab being one of those.
What to avoid when thinking and talking about performance?
Avoid making the process so heavy that becomes a burden on your team. The main reason why companies end up starting processes to review performance is because if they do not do it, managers avoid having hard conversations with their employees.
Don't be one of those managers. Have ongoing conversation about expectations, deliver and solicit feedback from your team members.
Avoid assuming you have enough context about things that happened outside of your team.
Never give someone feedback about themselves or their team at a performance discussion meeting for the first time. If you had feedback important enough to share, you should have done it timely beforehand so the other part could have done something to course correct.
When you're talking about performance of your team with other managers, the mindset should be “search for the truth” and not “how to convince everyone I am right”.
Besides that, if you're a manager of manager pay attention to the conversation within the conversation: you will likely learn more about your management team than about the individual contributors of your team in such conversations.
If you do not know how to have a hard conversation without dreading it, read Crucial Conversations. It is a great starting point.