Hacker News Reader

Comment by andrey_utkin | Hacker News Reader

A question for all the PEs here. When you want to reflect critically on what you do, and actually measure your performance and/or bottom line contribution, what do you measure and how? What do your bosses measure? Surely warm fuzzy feelings and other placebo effects are not enough. Imagine a situation that some underlings resent about your uselessness or lack of responsibility. What criteria/facts could possibly make you agree with that?

View on HN

As a manager, I’m looking at how my principals are helping the team move past big hurdles. Their ability to write code is a given, and they still do it (though not as much as they did, or at least not the same type of code). But are they mentoring and pair-programming with junior team members? Can they take what the BA/PM ask and turn it into meaningful technical tasks (that’s part of my job too - I try to lead that exercise, but need them as a sanity check and to stay on top of new things I might miss). Can they talk to a customer in a useful way (not too technical, not condescending) and do whatever problem is being discussed? Are they a go-to resource for other teams? Are senior leaders dropping in to ask them questions?

I’m definitely not looking at the raw number of Jura tasks here close. But I’m not looking at that for junior devs either.

Edit - usually, the more junior drive are more in awe of the principals. I’ve never encountered one who outwardly seemed to think the principal wasn’t contributing. More than likely, the principal was actively helping them get their own tasks done.

This. If I’m not helping junior devs get their work done, I am failing as a PE.

Helping is activity, how do you evaluate the outcomes?

Where I work scrum masters are supposed to “help teams improve”. That’s measured, in one way, by looking at the current rate of performance of a team and projecting it out. Then a scrum master needs to improve the team’s performance by some amount that exceeds the cost of having them there.

Some examples, number of on time deployments, number of story points, number of bugs... I’m not saying this is perfect, but that’s how some people are measuring.

So if a PE is responsible for improving juniors, I suppose a PE can be judged on the size and complexity of projects their juniors are able to take on. Maybe the time to promotion and number of juniors getting promoted?

Unfortunately, it tends to be a bit "squishy" - task completion (by the PE or by junior team members), team velocity, etc can all be used, but using them exclusively is just asking for the team to game those metrics. Much better to have regular 1-on-1s with each person and just discuss progress - team progress, individual project/task progress, and any career goals. If somebody is actively seeking promotion, we'll use a job progression matrix (HR puts them together) and talk through the differentiators and what that employee can do to fill the gaps.

Reply on news.ycombinator.com