Ask HN: What does performance management look like at your company?

The problem is that marking a task as finished does not mean that its deliverable is solid. A developer can game the system by leaving technical debt behind for others to fix. In this way, the developer is stealing productivity from others, by forcing them to spend more time reading, debugging, refactoring their half-baked code.

A neophyte manager may buy into this approach to performance, and even encourage it. But after a few iterations of this unsustainable practice of leaving tech-debt behind for no reason, reality sets in: now you need an army of engineers to get things done because the system becomes fragile and complicated. And you also need an endless amount of documentation that is constantly getting out of sync.

In a way, under poor performance management rules, development becomes like a game of pool: it's not only about having a higher score, but also about making it more difficult for others to have a high score. If you want high productivity, recognize this and penalize it.

That said, it isn't too unusual in my experience because people who are good engineers usually get told "you should go into management if you want to keep advancing" but they don't tell them "Oh, and this is a completely different job than you have been doing and none of your skills will apply, kthxbye!"

For a long time in my career I didn't want to be a manager because I didn't trust myself to manage well. And it took a really bad manager at Google to educate me on what the job of a good manager is. I stumbled around a bit but figured out that there are two things a manager must do to be successful; first is to communicate with their team what is expected of them and how that expectation will be measured, and second is to listen to what their employees say to them.

Sounds kind of simple but it's actually kind of hard to get right.

Performance management is drilling down into understanding what is going on with the person who is failing to meet their expectations.

If you both understand the metric for measurement, whether it is lines of code or time to delivery or what ever you have worked out with the employee ahead of time, both of you have to look at the metric, and the action to date, and get to a common understanding of what is going "wrong."

The most common problem I have dealt with are people who claim to be "senior" from a large company but don't really have any idea what that means other than "time spent in the role." I have pretty qualitative definitions of "entry level", "experienced", and "senior" that I work from and right away I try to communicate that to an employee. Sometimes they get hired into a role that is "above" them and they are unable to rise to the challenge, sometimes its just a different work flow than they have been used to.

The second most common problem is ego. An engineer who defines themselves by how good of an engineer they are, has a really really hard time looking critically at their own weaknesses. That conversation usually has a lot of "this doesn't mean you are a bad engineer, it means we have to work out how you can be even better than you currently are." type discussions.

The third one that comes up are people who are doing the job because someone else (spouse, parent, peer) thinks "it's a good job, you should be a ..." rather than the job they really want to do. As a result they put in only enough effort to not get fired and not much more. I'm okay with that if they don't mind being paid at the entry level wage level. If they are in the mindset that "I've got five years of experience and says I should be making $Y at this point." Then we have the conversation about "careers" versus "jobs". There are plenty of people who just want a paycheck and will do the minimum for it. They do fine work and clock in the hours, but they don't add value to the team like someone who wants to be good at what they are doing.

Too many engineering managers try to treat engineers as cogs with the only power of "do it or I will fire you" to motivate them. From my limited experience with this type of management it only works so much, and it doesn't build teams, or good product in the long term.