Performance enablement

Written on //6-minute read

Performance management is broadly used as a way to plan, review, and reward people for their contributions. For folks who are unfamiliar about how the process looks like in larger tech companies, it usually boils down to:

  1. Expectation alignment. Companies usually have career tracks and ladders – a framework that standardises expected behaviour and scope of impact for a specific seniority level (e.g. senior engineer) through principles and policy. Role-specific expectations are provided by the person's direct manager, such as expectations for a project or goal. The beginning of each performance management cycle usually consists of a joint assessment and agreeing on a plan of what the next cycle should look like.

  2. Systems to continuously get/give support and feedback. Throughout the performance cycle, people need to have the support channels to seek input, give feedback and realign expectations. Besides 1:1s on a weekly/biweekly basis, some companies also have mid-cycle check-ins, which are the mid-point of a performance cycle, with slightly more formal feedback and reflection.

  3. Recognition and reward. At the end of each performance cycle, people are rewarded and recognised for their achievements. Different companies will also have their intricacies, but it is usually a combination of extra compensation (e.g. salary raises, stock/equity refreshers, bonuses) and more scope and responsibility (promotions, taking on more responsibility, and so forth). The outputs of this stage are used as input for the next performance cycle.

While I think big companies require some degree of control to performance, even for fairness purposes, I have seen managers, due to their fair share of responsibility for a person's success in their role, exert too much control. Although, for the vast majority of the time, I find it beneficial to approach my role as a manager in a person's performance as an enablement function rather than a controlling one. To explain my point further, I will borrow two concepts from Radical Candor: growth trajectories and and stability trajectories.

Enabling a growth trajectory

Growths means many different things for different people: some folks are thoroughly ambitious to "climb the ladder" and want "next-level work". Others are more focused on learning and acquiring skills. To others it may mean polish and further mastery to their craft. And the meaning of growth is also circumstantial – it can change over time.

As a manager, enabling growth is fundamentally about matching people to their aspirations. Enablement consists of jointly identifying meaningful opportunities that will stretch people to their target condition.

Enabling growth in the context of "climbing the ladder" is straightforward – promotions are "lagging", so it is all about connecting people with opportunities to do work at their next level. There's very little control in that sense, as the behaviours need to come from the person themselves. As a manager, your role is connecting them with the right opportunities, and improving their ability to be successful in seeing these opportunities materialise.

In the context of growth as further learning and mastery, there's much more nuance – as theoretically both the manager and report have much less control. Generally, there's very little prescription from career tracks and ladders on how to go about moving from backend engineering to machine learning engineering, or how to become a better compiler engineer. Virtually zero control exertion in such cases.

I believe this proves the point made previously for folks seeking growth – a manager's role in a person's growth is fundamentally about enablement, not control.

Enabling a stability trajectory

A stability trajectory is about keeping things as they are. It is only natural that when things are good, no change is good. Sometimes growth comes from outside of work, or there's just a sense of plenitude with work, and that should be ok to be enough too.

Some companies have what are called "terminal levels", which once reached, there's no risk of "up-or-out". In such circumstances, people commonly seek stability once they reach those levels (generally senior engineer on the individual contributor track and any manager roles).

In such scenarios, people already know well the expectations at their level, and they are doing just fine. Again, there's no control – only enablement.

When to control performance?

While most of the performance management seems to be enablement, there are great reasons why controlling performance is a reasonable approach. A manager is ultimately accountable for the team's outcomes, and sometimes consensus with the report isn't possible. There's many examples to draw from, but I believe the following two suffice for the sake of the argument:

  • When an individual growth trajectory risks impacting business goals or commitments. Typical scenarios of it going wrong include losing track of what really matters as a report is too deep into promotion-driven development. Not exerting control and helping people focus on what matters is a case of negligence of the manager.
  • When absence of growth impacts a person's teammates or their team. Especially for people on the verge of performance issues, there's resistance to develop a skill where the lack thereof heavily affects the team. For example, think of a situation where a manager stays away from technical decisions but frequently fails to delegate the responsibility to a staff engineer.

The bottom-line of such situations is two-fold.

Firstly, more than when to control performance, "how" matters a lot. Arbitrary control will come across as micro-management, and so will jumping to conclusions. The best way to exert control is if you agree upfront what are the guardrails. When things start to go wrong, it's harder to find alignment.

Secondly, the extent of control needs to be proportional to the damage a performance issue will result into. I've seen experienced leaders jump to action too fast, and hinder a relationship with a report which becomes unrecoverable due to over-indexing on protection.

When not to control performance

A situation which every manager eventually runs to is misaligned incentives. What I mean by that is that what's "right" for the role at hand is not what's "right" for the person reporting to you. In such circumstances, applying control may leave only two bad options to choose from: bending the role to fit the person in or bending the person to fit into the role.

Such situations are where the enablement framing has helped me the most – a high performing individual in another team is a better outcome for the business than a low performing individual in my team. I've seen folks move internally and get promoted in the next cycle because they were fundamentally ready but lacked opportunities, and folks leave companies because they didn't want to develop their skills in the direction which was needed.

While situations requiring control demand a lot of hard work, performance management is for most of the time enablement.