Skip to main content
pcloadletter

Impact-based performance evaluation in big tech is terrible

Office Space scene with printer

My theory is that some performance consultants got paid a lot of money one day for a single word: "impact."

If you have worked in big tech, you're probably all too familiar with this word because your annual performance evaluations are based on your impact.

As an employee, impact-based performance evaluation is a disaster. For companies, I think it still may end up being pretty bad.

Impact? What the f*ck does that mean? #

We all kind of understand what it means to "have impact." Your presence helps move the company in a positive direction in some way (tied to profit, of course).

But from the perspective of "am I good at my job" or "how do I get a raise" or "how do I get a promotion," being told to "have more impact" means nothing. Do you need to ship more features? Better quality? (just kidding). Perhaps you need to lead a new initiative to increase test coverage or improve quality.

If you're lucky, your manager helps you define the things you need to accomplish your next career step. But in my experience they don't have great answers either.

So we thrash.

I have seen this play out in a few different ways:

None of this is healthy. Some of it benefits the company, at least in the short term.

Impact above all else #

When impact is the goal, we optimize for impact (or whatever we perceive to be impact—see previous section).

Often, people believe impact to be about shipping features and new initiatives. So we'll crank out a feature or some new innitiaitve with reckless disregard for (1) it's quality and (2) if it's even needed.

Are you in big tech and wonder why there are twelve nearly identical logging services? Impact, baby! Each of those initiatives was led by an engineer looking to make impact.

Is this really beneficial for big tech companies? To have redundancies all over the place in the name of impact? To ship low-quality features so we can spike the football in an organization-wide email?

No one is measuring the negative impact of all this #

Engineers are leaving massive amounts of tech debt in their wake as they cram high-impact features into their codebases. This isn't always (or often) evident when the feature ships, but will become clear within the next few years. Development speed slows down as the team battles bugs from the slipshod feature implementations.

The engineers who wrote the code already cashed in for that sweet impact and have been promoted or they've fled the scene of the crime to another organization or company.

As the next engineer onboards to organization they can't help but think to themselves, "How can I possibly make an impact in this nightmare codebase?"