Hacker News Reader

Comment by lrem | Hacker News Reader

> If you’re going actually to use this, however, you need a way to fairly evaluate the performance of ICs that doesn’t rely on input from their management chain which is itself a hard problem.

Why would you need to decouple that to evaluate managers? TBF at manager level this can be a rather simple and robust “how did the org subtree rooted at this person fare at contributing to the stated business objectives?” Along team performance, this depends on staffing matching the expectations. Negotiating which are core responsibilities of a manager.

Seems much easier than evaluating ICs.

View on HN

> Why would you need to decouple that to evaluate managers?

If a manager’s performance evaluation is based primarily on their reports’ evaluations, then there’s a conflict of interest: The manager is incentivized to inflate their reports’ evaluations because doing so directly improves their own evaluation.

Perfect. Then maybe the managers would be working with their teams instead of just setting up goalposts.

You're approaching your stated problem wrong. See:

> A manager’s job, fundamentally, is to ensure that their reports are delivering appropriate value to the company, so the most direct measure of a manager’s performance is the performance of the ICs that report to them (possibly indirectly).

Now, you're arguing that `sum(evaluate(impact) for each IC)` is absurdly bad. Which it is, because you're compounding errors in individual evaluations. These are hard to do, because you're trying to distribute team's achievements between contributions from particular people. I say that `evaluate(sum(impact for each IC))` is easy and robust. In fact simpler than an evaluation for a single IC, because you don't have to distribute anything and a lot of things that are external distractions for ICs fall into responsibility of managers.

Using functions in text just makes it hard to read.

And shows a poor command of English.

It was the only thing that made me understand his point.

Because he wrote the key points in a function instead of properly explained english.

I only tried this meh notation because hn doesn’t do LaTeX.

> Now, you're arguing that `sum(evaluate(impact) for each IC)` is absurdly bad.

No, I’m not. I’m arguing that it’s unwise to trust someone to do an evaluation who has a personal stake in the result of that evaluation.

Looking at how well a team works together to advance company goals is an important factor in any evaluation system, but using that as the only factor in a manager’s evaluation is as shortsighted as evaluating a software engineer solely on how many LOC they produced.

In practice, overall team performance should be a factor in IC evaluations as it’s reflective of various hard-to-quantify contributions of the team members. It should also be a somewhat larger factor in a manager’s evaluation, with the weight between IC and team performance shifting from mostly-IC at the bottom of the hierarchy to mostly-team at the C-suite level.

I think GPs point is that evaluate(sum(impact of ICs) can be evaluated by the manager of the person-to-be-promoted.

My concern with this is: How do you correct for luck/easy tasks?

It’s hard to compare the performance of departments unless you have been inside and seen the challenges they’ve been facing.

You don't need to use the individual evaluation of ICs, you use the overall success of the team in delivering whatever it's their job to deliver. If nobody but the manager is capable of evaluating that, somebody has really messed up.

Reply on news.ycombinator.com