A change of heart regarding employee metrics | Hacker News Reader

A change of heart regarding employee metrics

rachelbythebay.com

650 pointszdw389 comments

>> [Why not build programmer performance measurement tooling?] It's the job of a manager to know what their reports are up to, and whether they're doing a good job of it, and are generally effective. If they can't do that, then they themselves are ineffective, and that is the sort of thing that is the responsibility of THEIR manager, and so on up the line.

Agreed wholeheartedly, but for slightly different reasons. To wit, laziness and Goodhart's law. [0]

In the absence of infinite time, automation will excuse a lack of manager curiosity, as other competing tasks absorb the freed time.

Consequently, most managers with automated dashboards showing performance metrics won't use those dashboards... plus all the person-to-person work they were previously doing. They'll only use those dashboards.

Which then slowly but inexorably turns your employees into dashboard-optimization drones via operant conditioning.

Helping a colleague doesn't show up on the dashboards? Fuck that. Digging into what looks like a security vulnerability isn't on the sprint board? Fuck that.

Which is incredibly corrosive to quality, creative system design.

And then, because this is the work reality you've created, the creative folks you really want working there bail for greener pastures, and you're left with bottom of the barrel talent and retention problems.

[0] https://en.m.wikipedia.org/wiki/Goodhart's_law

> Helping a colleague doesn't show up on the dashboards? Fuck that. Digging into what looks like a security vulnerability isn't on the sprint board? Fuck that.

Managers who are the sort of people who don't value helping your colleagues or being curious/concerned enough about potential security problems, are most likely the sort of people who won't pick up on any of that being a valuable use of your time during one on ones or in standups either.

I think fundamentally you agree 100% with Rachel, shit managers are shit and nobody owes them tooling to make their job of being a shit manager easier.

If you want all the employee loyalty and long tenure institutional knowledge of a micro managed call centre, sure - implement checkin and LOC dashboards, or Jira ticket "velocity" charts. Watch all your talented people leave and don';t be surprised when everybody is only there because they're desperate or comfortable. Your entire dev team will eventually be only working-visa-prisoners, talentless-seatwarmers, or people who've dialled the give-a-shit down so low it doesn't bother them just picking up their pay checks.

> Managers who are the sort of people who don't value helping your colleagues or being curious/concerned enough about potential security problems, are most likely the sort of people who won't pick up on any of that being a valuable use of your time during one on ones or in standups either.

This is not a "sort of people" problem. This is a metrics problem.

It's not only developers who are evaluated by using useless metrics that don't track the value you add to an organization. Low-level managers are too.

Low-level managers need to evaluate the people assigned to them, they need to evaluate them objectively, and they need to give an unbiased and objectively verifiable score. This means something they can measure, such as metrics or verifiable goals.

If low-level managers cannot do this, they will need to answer why they gave X and Y this score whereas poor little Z who outworked them both was scored lower. Not being able to objectively justify a score is a problem that no manager wants to have, as this is a major liability.

Hence the bullshit metrics and absurd goals. They need something on paper to back up their decisions. A manager might be fully aware that you unblocked half your team members throughout the year with critical help, and that you are the go-to guy to solve critical issues. But if your team members close twice the tickets you did, they will have trouble justifying you are contributing as much as them.

> But if your team members close twice the tickets you did, they will have trouble justifying you are contributing as much as them.

The metrics make reporting to higher ups easier, no doubt. But the situation you describe is a classic sign of a shit manager: one who cannot justify their decisions except via reference to made up metrics.

Unfortunately, a lot of things boil down to metrics, even at companies with great engineering cultures.

If you have four L4 engineers on the team, all of whom are performing at the level described in the career profile as L5, but only budget to promote two of them, how do you pick which two? What if they have different managers, all of whom sincerely believe their report is the one delivering essential value?

If you have an organization with forced bucketing where X% of your team need to be given a subpar rating, how do you decide which one? If you don't have an obvious low performer you'd better have metrics.

This system is soul crushing but it exists all over the industry.

> If you have an organization with forced bucketing where X% of your team need to be given a subpar rating, how do you decide which one?

Easy. You quit, and find a better job.

That practice is so toxic that it's sufficient to condemn the organisation as unworthy of any buy-in whatsoever. Just leave.

Nah you make sure X% of your team is staffed with losers. It's a nutty system I know. But I'd imagine that's how things worked at companies that have stack ratings. Managers probably traded low performers like baseball cards.

In defense of stack ranking, it does solve a very common problem -- managers who never fire people who deserve to be let go.

This ultimately rots an organization from the inside, as it leads to attrition of higher performers because they're forced to work with useless people.

You see this a lot in companies that rarely fire people, because managers optimize for accumulating direct report count (whether or not those direct reports are doing valuable work).

companies need to do much better about letting managers go. I get it, they are hard to find. and those that actually have any engineering management skill at all are even harder to find. and every time you hire a new one you're taking a risk that they'll be a absolutely terrible manager. a terrible manager can cause a huge swath of destruction.

but the answer can't be an army of useless middle managers diluting the impact of the people who actually do want to help the company and providing cover for people like them that are just phoning it it.

Absolutely. I'd like to see companies get more serious about driving manager requirement from span of control.

As well as regularly rotating managers, like the military does (e.g. 3 year reassignment).

> This ultimately rots an organization from the inside

Hum... So instead you decide to immediately rot the organization from the inside.

I can see how it avoids that one problem. The important problem is the waiting, right?

Try working for IT in a utility, insurance company, or other stable business. You'd be amazed how high the bar for termination is.

No disagreement here. But you are falling for a very bad logical fallacy.

> how do you pick which two?

You (=hypothetical manager, please excuse second-person tense) use your managerial skills to make a decision, which considers metrics and other contributing factors. Then you write a justification which you defend, to higher ups and to those who weren't promoted. Because that's your job.

Yes, the Nuremberg defense - "I was just following orders" - is one approach.

It's a lot easier than applying back pressure, fighting for your reports, or quitting in solidarity.

"Sorry, Hugo and Maryna, you two only got the Fields medal while Anton and Alain got a Nobel Prize, so we'll have to let you go for your under-performance."

Here's how this works in practice:

* Corporate says "here are the buckets. They should match at the VP level since that's a large pile of people"

* VPs tell their Directors to match these buckets, who recurse further

* L1/2 Manager Alice says "my team is too small, this isn't how statistics work, I want an exception"

    * Problem #1: the teams with actual low performers will often make similar claims

* If the claim actually gets escalated all the way to the VP, the VP says "tough, fit the buckets".

* Alice is now a troublemaker in VP/Director's eyes

* If Alice and everyone who feels the same way quits in protest, nothing changes except that the org is full of yes men, none of whom are even trying to push for changes in the system any more.

So it's better that Alice stays because ... why?

Because Alice is a good manager who cares about their reports and is otherwise supporting them, advocating for them, pushing for changes to team culture, etc.?

The fact that they can't control this one thing does not mean that they should just abandon the whole company. If Alice finds a company where they can get similar compensation for similar workload without the forced bucketing, perhaps that's a good idea for their mental health, but Alice leaving is a large negative for the team.

I wrote 'applying back pressure, fighting for your reports, or quitting in solidarity'. Alice leaving was the third of these.

'advocating for them' and 'pushing for changes' are parts of the first two.

When back pressure and fighting for your reports does not work, what do you do then?

As you wrote it, Alice leaving is a large negative for the company to, making it full of yes men, unable to change away from a collision course.

>When back pressure and fighting for your reports does not work, what do you do then?

Continue fighting the battles you can win. Do your job and do it well. Changing jobs is hard, stressful, unavailable to many people for a variety of reasons, and not guaranteed to improve things. Particularly once you start becoming senior and in management.

If I left a job every time I was faced with a bad situation I would never built up the soft skills or connections to be any good at any connection. Particularly as a first-level manager, where 80% of your job is delivering messages you had no say in but have to own anyway.

The comment I replied to at https://news.ycombinator.com/item?id=42039995 was only about following orders, with zero mention of fighting any sort of battle.

My response was meant to be interpreted as doing something other than appeasement, which includes "fighting the battles you can win."

Nah, it's better on the long term if she goes work somewhere better.

But changing jobs doesn't happen immediately, and "somewhere better" may be very hard to find.

> Then you write a justification which you defend, to higher ups and to those who weren't promoted.

What happens next is this manager gets a low performance rating themselves, for making decisions not backed by metrics. So next year they conform.

This "don't make a decision unless it is 100% derived from metrics" mentality I just don't get. A robot could do that. Why is your company out there trying to hire/promote smart managers with good judgment if they don't let those managers apply their brains and judgment? "If employee's measured results > threshold, then reward employee" can be done by a computer. No need for a human manager.

People create process because of the principal agent problem.

The upper managers do that because they think the lower ones are lying or incompetent. A traceable process doesn't lie.

And yeah, it's stupid, and it makes the problem worse. It's the reason nonetheless.

> And yeah, it's stupid, and it makes the problem worse. It's the reason nonetheless.

While that's true, it's also a difficult problem to solve. In tiny organizations like startups where the CEO personally knows everyone and what they do, it's easy.

But as soon as you grow beyond that (and I've been in a number of startups that cross that gap), how do you objectively but fairly handle this? There is no easy answer.

You could go with fully empowering all managers to do as they wish. Trust them to hire, fire and promote correctly. This is great, until you hire some bad managers. And as you grow, it is 100% guaranteed at some point you'll hire bad managers. So then they ruin it for everyone, hiring and promoting their buddies.

And that's how you end up with more objective metrics. Take away some of that freedom, make everyone measure and justify actions based on metrics. It's terrible, but probably better than the alternative.

> If you have an organization with forced bucketing where X% of your team need to be given a subpar rating, how do you decide which one? If you don't have an obvious low performer you'd better have metrics.

This is a case where you're forced to rate people who are up to par as subpar - the rating system is simply bullshit. You should be allowed to rate people according to their actual performance.

Metrics don't solve the underlying problem which is that the rating system sucks. Having a random number generator called "metrics" to "make decisions" isn't good either.

Dice.

> If you have an organization with forced bucketing where X% of your team need to be given a subpar rating, how do you decide which one?

I think it's Joel Spolsky who has a tale of a manager asking him to do that for his team when everyone had gone all in with overtime to get something shipped on time. To their great credit, the author refused, and the manager saw sense.

Pfff, what kind of problem question is that. Manager promotes the ones who go with him for a smoke or do some other regular informal activity together, obviously. :)

If you’re a manager in this type of system, your job is to reach out constantly and find folks who are low performers and get them into your department. They will fill the bottom of your team rating chart. At that point, they can be managed out (ideally in a humane way) or just held onto to fill that cellar dweller role while not slowing others down (some people are ok with this as long as they get paid).

I would never choose to work in an environment like that, but some people find themselves there without better options (e.g., being location-bound due to family, etc.).

Wow, I never saw this type of advice before, but I like it. In short: If you are required to do stack ranking, where at least one person must get a shitty score/grade, then recruit someone internally who is below average and will take the hit. Brutal, but practical.

Or externally! I posted an idea here a while ago, where I thought I'd start a staffing company called "Scapegoat Consultants" and we would offer your team a "low performer" that you could hire and then fire after a year, to protect the rest of your team from stack-ranking. Our consultant will join your team and do as little as you want, or even nothing at all! We'd guarantee that they will at least not actively make your code base worse, but that's it. After a year of this, you can easily make the case that our recruit was a low-performer and manage them out. Don't worry, he won't mind--his job was to be the low performer, and we'll hire him out to the next BigTech company who struggles with stack ranking.

It used to be tongue in cheek, but maybe the industry actually needs something like this.

Cynical, but probably the most humane take I’ve seen here so far.

That's the standard strategy to survive stack ranking.

Have you heard any story by someone that was hired into some megacorp just to be sent into a PIP or fired by low performance before they had any chance to even do anything? Stack ranking is the most common reason those happen.

“Hire to fire”. Not a new idea. I have been hearing it for at least 5 years now.

>the situation you describe is a classic sign of a shit manager

Well then it means the vast, vast, vast majority of companies with a coherent corporate structure are shit. Welcome to reality

I've had experience with internal "support" that marks tickets as closed without actually fixing the problem. Sometimes the reason for closing suggests they haven't even read the email that opened the ticket.

Think something like "Tool $X is missing on machine $Y. Please can you install it, according to $POLICY it is meant to be on all prod machines." Then the ticket gets closed with "The policy is correct. $X must be on all prod machines, we cannot change this." Without installing the tool.

Then when the annual anonymous "rate your satisfaction with these services" survey came round, they wondered why the ratings were so bad - I made sure in the open text feedback not to go after the poor employee but to raise concerns about the performance of the team manager. I won't take credit for it, but I'm told things at $COMPANY have got better since.

> a shit manager

This isn't about a singular individual, it's about a group of professionals. You have to deploy systems thinking. If you give a cohort a tool that allows and incentives them to do worse at their job, the average person in that group will perform worse.

I like my boss; I have also built a skillset and frugalness where I don't worry about working for someone I don't respect ever again. But I still care about what's going on at large and trends. I don't want downward pressure on the average. Not only will that slowly seep into effecting me, I also care about the lives of the people at points in their career where they don't have employment opportunities that allow them to avoid bad management.

> The metrics make reporting to higher ups easier, no doubt.

It's not about being "easy". It's about being objective, verifiable, and demonstratably unbiased. It's about justifying how you rank the performance in a way that's impossible to refute.

> But the situation you describe is a classic sign of a shit manager:

It's not, and frankly this "shit manager" accusation is an infantile remark that screams a failure to understand what it means to perform well.

It becomes an interesting contradiction : there's no such thing as a good unbiased and objective metric on this.

So good managers (that do their job properly) are bad managers (that get fired for it).

And bad managers are good managers...

Recent-ishly on HN: https://yosefk.com/blog/advantages-of-incompetent-management...

A manager can absolutely describe any value as simply as you just did.

One thing that is always on the table - if you see a person picking up valuable work and they don't have a ticket for it - you as a manager can create that ticket.

Now you may need to coach the person on how to do that themselves (can we make the ticket making process more lightweight? Can we make a heuristic like just put story points for the time you've already spent on it plus a buffer for after-the-fact work?)

But managers who really want documentation and truly think people are doing underappreciated work can always make it themselves.

> Managers who are the sort of people who don't value helping your colleagues

Helping, yes certainly one of the core requirements being a manager is unblocking direct reports from whatever they're doing.

But it has limits, because you as a manager have finite time. I've got seven direct reports, three are relatively new hires and so consume most of my "help". Of the remainder another three are great senior devs who can be trusted with getting the broad brush strokes of a problem and going off independently to delve in.

One however, a struggling senior dev with junior dev capabilities, and having major childcare issues at home is totally floundering, pulling sick days and basically failing. As a manager I basically don't have capacity to commit the amount of time required to pull them out of it, and I'm trying to move them off the team.

Have you talked to your "failing" team member about this? Have you worked together to try and identify a path towards improvement? Off the top of my head, perhaps they would benefit from more WFH time? Or perhaps a period of part-time work? Perhaps their duties could be shifted around so that they can contribute in a different way for a while? Could they take over some of your mentoring duties?

I mean, this is the bread and butter of your job as a manager, right? Getting the best out of your people?

> Could they take over some of your mentoring duties?

They wrote that the person has junior skills.

> so that they can contribute in a different way for a while?

Seems to me that this is what they're doing already:

>> I'm trying to move them off the team.

(To another team where the person fits better, presumably.)

I don't read it so charitably. They only see a problem they want to go away. How do I know what they see? Because that is what they said.

whatever else, that major childcare issues comment right there should tell anyone "don't work at that company, because hey your child gets cancer they don't care and will try to figure out a way to fire you. Probably by saying you have 'junior dev capabilities'"

That’s nice and all, but what else do you expect to actually happen?

if someone is underperforming due to those kinds of problems then to say they have junior dev abilities seems somewhat insulting, which is especially contemptible because it is wrong to insult someone that is going through an especially difficult time, especially as the person doing the insulting might not be able to handle the situation any better themselves.

So first off I expect not to insult people in that case.

Then I might expect something like "unfortunately due to the extreme medical situation the family finds themselves in I do not feel this person can fulfill their duties at the company any longer, and will need to be let, following company policy / legal requirements in our area that means the following rights pertain ...."

that is to say instead of moving them out by saying they have junior dev capabilities and are just failing, acting honorably in the firing process and taking whatever hit the company is supposed to take.

In other words I expect the company to pursue its benefit, but honorably and not as a scumbag. Your "what else do you expect to actually happen" suggests that you think it is likely the company will be a scumbag, your "that's nice and all" seems to imply that you think being a scumbag is not just likely but somehow also correct.

on edit: referring to the legal rights and responsibilities of company may also in some cases be that the employee has rights to paid leave and similar things. So it does not necessarily mean that someone will be fired, depending on where this situation is taking place.

This is why if you’re telling someone something they don’t want to hear it’s best to only give one reason.

Senior dev overleveled and performing at junior level is one thing. Personal issues impacting performance is another. They have totally different solutions and just mentioning them together sounds like the manager has an axe to grind.

it may be true that these have different causes in a particular situation, but given the variability and length of employment in most companies and projects for everyone involved (managers and programmers) I would think it more likely that a manager wouldn't actually have enough data to reliably separate the two conditions when dealing with it.

That's a pretty weak excuse that would raise serious concerns if one of my managers said it to me. The job of a manager is to debug these kinds of things, and frankly, distinguishing between technical gaps and personal issues is the easiest form of this. That's not to say you never get it wrong, but you listen, adjust and course correct.

Something similar came up in another HN comment thread I was in a few months ago -- someone hired at senior level, but ended up only having junior level skills.

The root issue, imho, is there's no accepted corporate method of demoting an employee (in the US).

Which is unfortunate, because it would benefit both the company (who retains someone with training and familiarity) and the employee (who isn't fired).

"Lower expectations for lower money" shouldn't be verboten, but it is.

> there's no accepted corporate method of demoting an employee (in the US)

Legally or culturally?

Where I live (Europe), seems it's legally prohibited, sort of, to lower someone's salary, if the employee doesn't agree (which maybe is obvious, there's a job contract agreement after all). The company would need to fire and rehire the person at a lower salary, but firing people isn't easy.

It could be construed as constructive dismissal in the US - reduction in pay, or hours. So essentially the same problem.

Thanks, didn't know about that term. Now I found: https://en.m.wikipedia.org/wiki/Constructive_dismissal

> constructive dismissal ... generally ... grants [the employee] the right to pursue claims against the employer.

> once agreed upon, wages are implicitly locked in by the common-law of contract as an essential term of the employment relationship. In this regard, it is a constructive dismissal if ...

(That last section is about the UK, I suppose it's the same in the US.)

You can give your team members more responsibility. Tech leads, buddies, owners of initiatibmves etc. are things. The juniors shouldn't be sucking too much at just your teet.

Based on what you’ve said, are you confident that you’re delegating enough? I mean, you kind of answered your own questions - you’ve got three seniors. Are they really senior or senior-in-title? If really senior then they should be helping take on some of the junior mentoring.

Be wary of the hero, “only I can do it”, mentality as a manager. It only leads to burnout.

Not to be antagonistic, but just as a practical matter to consider: if your account username is your real name then I would be careful talking about your direct reports like this. People who you work with might see it.

> people who've dialled the give-a-shit down so low

In the age of stock buy-backs, cyclical lay-offs, and record-high executive compensation I sympathize with these folks. It might even be morally correct thing to do.

As someone who's company has gone through the constant cycle of layoffs including one that happened just a few weeks ago, I'm at this point now and I have no qualms of all the other people who are also here at this moment.

I get exactly what is asked of me to do and nothing more, no longer respond to things outside of work hours and collect my paychecks. I still enjoy learning new tech and whatever the next thing is, but my interest in applying myself to my day job is at an all time low.

Oh forgot to mention our execs bonuses and stock went up despite everyone hating it here now.

> I still enjoy learning new tech and whatever the next thing is, but my interest in applying myself to my day job is at an all time low.

I’d say you’re relatively lucky. I found it soul-crushing when my work changed from something in which I took pride to something where I just wanted to coast and no longer cared. Management sucked and I was depressed at my lot in life. I didn’t have much energy to look for and apply to other positions.

Layoffs came twice and getting let go was the biggest favor they could have done for me.

My next (current) job is rewarding, and I’m again having fun learning new things in my downtime instead of vegging out on streaming content after work.

I don't. All you mentioned have zero impact on my daily work. I could as well say that in the age of Tiktokers earning millions, why should I care about my work?

I care about my work because it's my work and I don't want to just collect paychecks. If you're not happy and can leave, just leave. Go do something productive with your life that makes you proud of. Life is too short to play by others' rules.

Its a hard pill to swallow but I just want to point out that if you look around you at most jobs, including highly paid tech jobs - most people do not care about the job itself apart from the fact that it compensates them well - whether that be with salary or with time/benefits.

And not everyone simply has the choice to just find another job when they are unhappy. I know you caveated that with the "if you can" but I'd say the vast majority of people can't.

That and the fact that most peoples work is not actually theirs as you say. Everything you do is part of the company, and managers/execs take credit for the work all the time at many companies.

> I know you caveated that with the "if you can" but I'd say the vast majority of people can't

Most people have a lot more agency than they give themselves credit for. It just doesn’t hurt enough yet to face the cost of making a change.

What’s really the worst that’s gonna happen? You have to do some interviewing while putting in the bear minimum at current job? Oh no.

There's more to life than a job as well. I've stayed at a job for the comfort of not needing to add to my or my families plate while my wife was in grad school. It was absolutely the right choice.

I've also had a job that I left because I wasn't enjoying because of a lack of challenge and lack of management backing for the projects I was working on.

Life isn't purely black and white and my reasoning is pretty simplistic. There are vastly more complex situations than just my wife went to grad school.

Exactly. All of those are choices you have the agency to make. There is no “can’t” unless you are literally a slave (and even then)

>> All you mentioned have zero impact on my daily work.

Are you sure? My GF’s company went through two rounds of layoffs this year and she now has such a heavy workload that she works most evenings and some weekends as well, and her stress level has gone through the roof.

This is happening to me in the trades.

Im in maintenance as an industrial electrician.

New plants came to town paying current market rate and snagged most of the top talent.

Then the company started quiet-firing to avoid layoffs. It killed all motivation.

Then they froze hiring as we kept losing people. We are now short on HVAC, mechanics, and electricians.

Lucky me I'm the only guy who can do all three so im running ragged all day.

We have response times we have to meet but our vehicle (an electric GEM) had the charger die, it's only $2k but they won't let me order it so we all walk everywhere. Huge plant I easily bust 30k+ steps and 20+ stories climbed via stairs.

We then had a mechanic and an electrician take paternity leave so we are even more shorthanded. Still wont let us hire.

We lost the maintenance manager and cant get another one for what we pay and the condition the business is in now.

I love my job andy co-workers but I'm sending out resumes and interviewing because I can't take all the extra workload with no extra pay while our administration keeps getting more money and bonuses.

How do companies keep making the same mistakes over and over expecting different results? They don't, they know what's going on and are getting theirs before the bottom falls out.

If your company:

* needs HVAC, mechanics, and electricians to function and deliver revenue

* your company cannot afford to hire new people, only maintain their current payroll, or are unwilling to raise wages to be able to hire more (not enough talent)

* you are able to do all three, but are being asked to do more than want or are able to do

then there's a simple outcome that to me it seems like you're missing.

you can just say "I can't", or "no, I'm going home at 6" or "cool, that's a great plan but I only have time to do the first half of the tasks you just described today", and most importantly - your company simply won't be able to afford to do anything about it.

What are they gonna do? Fire you and be even more fucked? Seems like if you set firmer boundaries on how much you can work, their best decision is going to just be accepting it. Because their only alternative is to even stupider which would be to fire you and have no work get done at all.

Not really. I just came off night shift and was thrown right back on it. We work 12 hour shifts, they alternate between forced overtime and disallowed overtime at their whims.

When I brought up I have yet to get my float (4x10s considered the 'easy' shift) I was told there was nothing they could do. All I could think was well how will you handle it when I leave?

Management really is that dense.

They care not one whit about objections nor people leaving.

Imho it's merely a matter of time but the younger guys all hold out hope. I've none left.

Many Manufacturing managers hate people and just treat them as an expense to be exploited.

> All I could think was well how will you handle it when I leave?

You mentioned upthread:

> New plants came to town paying current market rate and snagged most of the top talent.

You should totally get a job at one of those plants and let them hang.

So what you're saying isn't you have tried saying "no" and just seeing if they call your bluff and fire you or just let you leave.

Given how common this is with layoffs, it feels like backpressure is needed.

Specifically: task shedding when they exceed available hours

If you're the last one keeping the lights on for a 4 person team, it seems reasonable to let some lower priority things go undone and communicate to your boss that "You don't have time for that."

Trying to ratrace to keep up with an unreasonable amount of work is just rewarding a company for overworking you, by avoiding sending it the hard signal of "too much work."

Fulfilling your obligations under the terms of your employment contract doesn't mean you don't care about your work and aren't acting professionally.

For a lot of people work isn't a passion project, it's literally the only way to have a roof over your head and food on your table. If you happen to enjoy it that's a bonus and not a requirement.

I can't imagine doing a job without having some passion around it. If that were true, i would be ticking of checkboxes in the form of executed jira tickets purely created by others, or fulfilling requirements set by others. I'm sure it would wear me out.

> If you happen to enjoy it that's a bonus and not a requirement.

I know a few people for who this used to be true. One of them got laid off and went back studying, the other changed jobs but is still ill half of the days.

My point being, passionless job is not a sustainable thing.

Then you lack imagination and empathy for those with less opportunity

I think it depends on the kind of person you are. I’ve met some pretty reliable folks for whom their day job was just a job and it didn’t matter if they were being paid to program web applications for processing tax returns or batch processing reports. They were much more passionate about collecting accordions or attending their kids’ hockey games.

They did not give one f for, “the company,” but they were steady and reliable co-workers.

I’ve also worked with passionate “try hards,” that will get upset if they’re not using the latest-and-greatest languages and tools. They’d throw tantrums over architectural decisions. And if they didn’t settle down they’d move on to the next job in a year. Hope they found what they were looking for.

In a single comment you mixed:

* Professional reliability

* People who don't care about what type of job they do

* Hobbies

* Parenting

* People who don't care about the company, but cared about their job

* Tryhards

* People chasing the latest fad

* People that have opinions about software architecture

* Job hoppers

My initial comment was about people caring about THEIR work, not the company or anything else. It was about people not doing something they dreaded for >8h straight and thinking that's what life has for them.

> My initial comment was about people caring about THEIR work, not the company or anything else.

For me, when I say I care about my work, it implies caring about the company at least to some degree. The mix of caring for other things easily emerges. If I review a peer's code, I care about them, about the code quality, about customer satisfaction, and hence about the reputation of the company I work for. This can be selfish in a way as well, since that mix has some reflection towards how I am perceived and how I am judged as a person.

Please re-read the comment I was replying to and see if it was about "fulfilling your obligations under the terms of your employment contract".

I think you're hijacking this thread to make your point regardless if its related or not to it.

Even if my employer doesn’t deserve my dedication, it’s the end-user impact and personal cost of not giving a shit that concerns me.

People building software are often in a position to directly impact significant numbers of people: not giving a shit leads to severe software vulnerabilities, data leaks leading to identity theft, compromised systems, etc. Real disruption to the lives of normal people.

And actively not giving a shit gradually changes the person doing so. I’ve seen this mindset become corrosive and has changed people who I previously respected in ways that I really don’t think could be beneficial or “good” regardless of what the company does or does not deserve.

Not giving a shit is why our industry is increasingly under scrutiny by regulators - for good reason.

I question a moral calculus that only accounts for the problematic business practices of an employer while ignoring the many potential downstream impacts that are unrelated to those practices.

There’s a needle to thread in terms of how one handles their emotional state while working and finding a healthy balance between doing good work and not dedicating one’s life to their employer (which I’m not advocating btw). But I’m increasingly skeptical of the idgaf mindset and frustrated by people who don’t take seriously the privileged position they’re in and the world changing impact of the work they do.

The only truly moral option in many cases may be to quit (if the alternative is not giving a shit). But people want/need that paycheck.

> people want that paycheck

In most cases people _need_ that paycheck. You can talk about morality all you want if you have the privilege to not need a paycheck, but you can't know everything about everyone's lives. You mostly only ever know about the choice someone else makes. You hardly ever know what options they had to choose from or the tradeoffs they need to think about.

That’s completely fair, and I slightly edited my comment to include the word need, because I strongly believe what I said applies to both dynamics.

> not giving a shit leads to severe software vulnerabilities, data leaks leading to identity theft, compromised systems, etc. Real disruption to the lives of normal people.

None of this affects me. The only way to make an employee care about this kind of thing is to pay them, and treat them, well enough to care.

You also need enough free time to care, which isn't nearly as common now that every team at every company is running on a skeleton crew.

> None of this affects me

Frankly, that’s a huge problem.

> The only way to make an employee care about this kind of thing is to pay them, and treat them, well enough to care.

The workforce is absolutely full of people who value their work and its impact on other people above all else regardless of how poorly they’re paid or treated. This is not an endorsement or acceptance of the status quo, but a recognition of the importance of one’s actions.

If you’re a teacher, bus driver, emergency responder, nurse, transit operator, power/gas workers etc. you’re most likely not getting paid much or nearly enough, but would never dream of bringing this “idgaf, pay me” attitude to work.

I suspect it’s because software is so abstract and the people building it are so far removed from its impact, but our industry seems uniquely disconnected, complacent, and entitled when discussing the impact of an individual’s actions.

> The workforce is absolutely full of people who value their work and its impact on other people above all else regardless of how poorly they’re paid or treated.

They're called juniors, and haven't yet been broken by the system.

> If you’re a teacher, bus driver, emergency responder, nurse, transit operator, power/gas workers etc. you’re most likely not getting paid much or nearly enough, but would never dream of bringing this “idgaf, pay me” attitude to work.

Have you seen the state of these professions? That's the prevailing attitude at the moment, and the reasons are obvious.

> They're called juniors

I’m 20 years into this, not a junior. And the people I’m talking about certainly aren’t juniors.

I’m not questioning the existence of people who stop caring. I’m saying that this is a choice, and one that many people can’t bring themselves to make.

> That's the prevailing attitude at the moment

Attitudes and actions are two different things. If people in many of those professions were acting like many do in the tech world, people die as a result.

I’d be careful not to project your own view of this matter on the broader workforce.

> And actively not giving a shit gradually changes the person doing so. I’ve seen this mindset become corrosive and has changed people who I previously respected in ways that I really don’t think could be beneficial or “good” regardless of what the company does or does not deserve.

Ye turning into a cynic is not nice. You can rationalize all you want but the corp is eating your soul, more or less.

A problem I observed is when cynics from bad places move to hardly OK places, and overestimate the amount of badness. People that think the corporation is rotten seems easier to make do rotten things, while others that "don't get it" might protest.

The subset of software that I can’t opt out of is small.

Not that the regulators are competent… but for opt in software it’s user beware

not giving a shit leads to severe software vulnerabilities, data leaks leading to identity theft, compromised systems, etc. Real disruption to the lives of normal people.

Meh, I'd question how much that is actually true. Generally, when people talk about "not giving a shit", it's not literally about half-assing everything. Instead, it's about only doing what you have capacity to do while balancing work with the rest of life....

Boss give's you 60 hours worth of info-sec tasks to complete this week.

You have a social engagement Friday night through Sunday (siblings wedding, and you put it on the on-call calendar months ago).

You remind boss "I can do 2/3 of that list, the rest needs to go to someone else, because 5pm Friday, I'm offline for the weekend".

You do the 40 hours worth of stuff, do it properly, and go to the wedding.

If your boss drops the ball, that's his problem. You did everything properly. Working through your sibling's wedding only justified your boss's under-resourcing of work.

What you describe sounds more like setting healthy boundaries.

But I've worked with a frustratingly large number of people who do literally half-ass everything, and clearly work hard to find the line where they can just barely get away with it. Usually this involves other team members picking up the slack.

The "quiet quitting" movement is a prime example, with people regaling each other with stories of their efforts to do just enough not to get fired, which is something entirely different than finding a proper balance with one's boss and setting reasonable boundaries.

Are you sure the people you work with don't half ass everything because they lack skills and aren't getting proper training, or are trying to do too many tasks and fail at all of them as a result? I'm tempted to assume they bragged about it maybe, based on the rest of your comment, but it's easy to assume wrong.

Quiet quitting reminds me of "greve du zele" (zeal strike) where workers do exactly what their contract requires / work by the book. It is nothing new. Often to protest employers lack of flexibility, to show that the book is absurd or to highlight that all that extra work should be compensated appropriately. I guess the main difference is one is an organised protest while the other is individual decisions.

That said, everything I've read about quiet quitting sounds to me like a marketing ploy to give setting healthy boundaries a bad rep.

I'm sure there is a range from folks who simply stop being proactive to people who put more work into doing the least amount of work they can get away with than they would if they just worked. And sure, that may already mean others need to pick up the slack, but really it means there's probably a systemic issue with that employer.

If quiet quitting is a pain in the workplace, it probably means employers rely too much on employee zeal. Employers fully count on teams picking up each other's slack. Toyota (iirc) first figured out that bonding between team members improved productivity via slack pickupery and peer pressure. (Also that teams could find their own efficiencies and felt more motivated to work if they came up with or were involved in their own exploitation optimizations).

I'd love to see a proper study done to identify causes of quiet quitting, if it is linked to burnout, I wouldn't be surprised.

A simple solution to quiet quitting would be improving the workplace or giving out employment insurance when people quit, so they don't feel trapped in a bad situation. Not everyone can simply move to another job at will.

> In the age of stock buy-backs, cyclical lay-offs, and record-high executive compensation I sympathize with these folks. It might even be morally correct thing to do.

Under capitalist and corporate morals, it's a sin for a worker to fail to give the best part of his efforts to the shareholders.

Stock buybacks are good if you're paid in employer stock like tech companies are.

Aside from that, they're value neutral to the company. They're not spending money, any more than you buying stocks is.

Cash in hand is cash. Framing it as “no money spent” is disingenuous.

Especially when your entire team gets lower bonuses after a successful product launch, while the company spends $8B profit in buybacks with minimal impact on share price. Large funds and executives get rewarded (10% of millions is a nice amount), employees get shafted.

> while the company spends $8B profit in buybacks with minimal impact on share price

Well, there must have been an impact of $8B, so it depends what the counterfactual was. It could've been going down at the time.

> Large funds

Generally speaking large funds are passive index funds, so that doesn't mean someone actually owns a lot of them - they're just in average people's retirement accounts. But it gets reported as if BlackRock (iShares) or Vanguard own the company, which leads to conspiracy theories.

> there must have been an impact of $8B

Buybacks don’t linearly increase share price, the stock is simply exchanging hands. If the company already has a 100B market cap, that amount is not making any huge waves, especially spread around a full year.

Replace “large funds” with “large shareholders”, the point is that employees receiving relatively tiny stock compensation do not benefit much.

> Buybacks don’t linearly increase share price, the stock is simply exchanging hands

Sure they do. Each repurchased share no longer exists, unless they're issuing new ones at the same time. The total value of the company stays the same, or something else might happen to change the price afterwards, but it should indeed be a linear increase.

The shares don’t cease to exist, they are simply not in the market anymore. And the cash used to buy them already belonged to the shareholders in the first place, no value is added other than price pressure from the reduced float. Market dynamics aside, it is a net zero transaction.

>Managers who are the sort of people who don't value helping your colleagues or being curious/concerned enough about potential security problems, are most likely the sort of people who won't pick up on any of that being a valuable use of your time during one on ones or in standups either.

I think in a lot of cases these managers do value those things, but the fundamental issue is that those things aren't reflected on the dashboard.

100%.

At my last org, my eng team (I'm a PM) had no manager for a while, during which leadership instituted metrics that tracked "Planned Points versus Planned Points achieved". My team also handled support escalations and defects. That work is ... unplanned. That was not tracked in their system.

I had to go in and advocate for them... "You have work that they are being required to do that not only doesn't show up on metrics that you are using to evaluate developer productivity, but in fact, you're actually dinging them by flagging that 'planned versus completed points' as unacceptably low. How do you think morale is going?"

They would do things like "The team planned 30 points to be completed in this sprint. They only completed 10 points, 33%, and we expect 90%. Oh? What's that, they actually also completed 25 points in unplanned work due to Sev-0 and -1 bugs and defects? That doesn't count."

Yet the author wrote tools to do that. Part of what I thought from looking at these dashboards is that the author by their own admission[1] arbitrarily doubly prioritized customer communications over internal discussion and gave credit for doing things in the ticketing system when presumably none of the actual work takes place in the ticketing system.

I know those events were over a decade ago and I appreciate the author's willingness to reexamine their beliefs, but that's what's meant by second-order thinking. What I got from reading a few of their writings is that this is a person I probably would avoid interacting with.

[1] https://rachelbythebay.com/w/2011/11/16/onfire/

I would argue that a managers time will be filled no matter what she does. So she could prioritise knowing what her peers do, and acquire the basic knowledge to understand tech maybe? And then fill up the rest of the calendar.

So I'm saying it is up to the manager to either suck upwards or support peers.

Stupid question but when digging into a potential security vulnerability, should that not be a ticket already that can get tracked?

Of course. Same as helping a colleague (unless it’s a few minute task). Whenever there’s something that I can spend my time on, it’s going to be converted into a ticket.

How do you prevent that from recursing infinitely?

If you are measuring tickets, then you can't.

Your job is to create tickets to close them. If you generate productivity along side that, then thats a bonus.

Because we're humans, not robots and a human manager with human managees should be capable of working within a process without abusing the most obvious of edge cases.

When building software you have to be precise to the nth degree but with human processes you can afford some degree of ambiguity and judgment...

you create tickets for helping colleagues? I would understand "add this feature for me", but do you also have a ticket to "take x through this unfamiliar neighborhood of the codebase"?

I've seen tech companies that strongly encouraged that: Open a "task" or "process" ticket describing what you're doing, then do it, then close the ticket. Not all tickets are bugs and features. During review time, if you expended effort not described in a ticket, it's as if you never did it. When in doubt, open a ticket.

that makes sense. I hate Jira enough though I don't really like cluttering it.

I've worked at a tech company that explicitly avoided that. They refused to allow me to even open tickets for things not actively being worked on but were important enough they needed to be looked at in the next six months.

The reasoning? Any internal ticket could be picked for review by the SOC2 auditor so all of our tickets must follow all procedures just like client tickets. It was more important to use templates, follow processes, and resolve tickets quickly than to allow us to use the tools to do our job efficiently.

Why?

"Tickets" are a means to an end, but not the end itself. If it helps you, create a ticket. Otherwise don't.

If there's no ticket, how will anyone know you did anything at all? How will submit your code change without a ticket # to satisfy the validator?

Sarcasm is hard to detect online, but... usually I say I did something and colleagues believe me.

If there's a code change, and I think creating a 'ticket' would be beneficial to provide more context, maybe I might create one, but usually I find it less faff to explain in the PR itself.

I read this something like:

I’m working on a feature, I notice something curious in some adjacent code that could maaaybe let someone bypass the UserAuthorizationAdapter with a carefully crafted request, but I’m not familiar enough with that code to say for sure.

It’ll take me at least half an hour to figure out whether it’s a complete misunderstanding on my part (I’m pretty sure it is…but it might not be…) or a real issue worth raising as a security ticket. Even just pinging someone about it will break my flow. It seems, however, that 100% of the decision making about whether I have a job next quarter and how big of a raise I might get is made based on three metrics on a productivity dashboard my boss is obsessed with. Should I take the time to learn more about the UserAuthorizationAdapter, or just assume it’s fine, finish my feature and move on to the next?

That hits too close to home. Except for us it's all about OKRs. You get one or two tasks for the quarter, and anything that isn't working towards that be damned. Which basically translates to launch your [AI] feature and fix nothing.

Every single place that I've worked at that's introduced any sort of goal based metrics has immediately become, in real terms, unproductive and unsatisfying organizations. As soon as you have a metric, even self-defined, that you will be graded on you optimize for it as the ol' Law dictates.

As soon as that happened support of existing services crumbles. Innovation tanks because risk means you might miss the target. It means the best engineers no longer mentor or build team based expertise. It means everyone becomes solos to hit their number or target and everything else falls away.

I'm sympathetic toward the want to measure employee quality but by doing that you tend to only punish the underperforming engineers, regardless of reasons, rather than rewarding the best engineers or an increase in quality of engineering. It creates hostility when one person's metric may be impacted by another person or org within the company. It sabotages everything the powers that be claim to care about.

That sounds extremely accurate. I'm a little ashamed to admit that I've caved and started to play the game. I haven't been very productive for over half a year but my scores are off the shelf because I'm doing precisely what they've asked of me.

Actual example from my experience:

Trying to figure out the correct AD groups/permissions I needed to use an internal web app to schedule patching for some servers I managed.

After stepping through the app's js, I realized they were doing user group retrieval and validaton client-side (!!).

Wrote a quick POC that patched their check and gave me admin permissions, then sent it and a description over to a friend on the internal app security team.

Not my job, but apparently the service account backing that app had permissions to reschedule patches on any internal server. (including f.ex. domain controllers)

So probably something that it was worth having someone spend a couple hours figuring out and reporting, despite it not showing up in my OKRs.

Based on my experience automated reporting dashboards start to cause damage where they are allowed to become visible by higher-ups in the org. A dashboard is immensely powerful for the immediate manager to know how their team is doing, identify problems and work with the members to resolve those problems. As with many things, the numbers on a dashboard must be read with context and the closer you are to that team, the better.

The moment the dashboard is accessed by higher ups, several things happen: The devs become scrutinized by higher-ups that do not have all the context to make sense of the numbers, the manager is rendered ineffective because the knowledge and power they had while reporting to their superiors is taken away, and upper management will inevitably start caring about the numbers on the dashboard, and nothing else.

There is a level of "managing upwards" that lazy direct managers struggle with, and they just pass on the reporting numbers as-is without really caring what this might result in.

Yep. It's for exactly this reason that I've told potential vendors in the past that not exposing, and preferably not gathering, individual contributor metrics was a hard requirement. I'd rather have individual team leads or scrum masters have to gather their own stats than have people with disproportionate organisational leverage exposed to information they don't know they aren't qualified to interpret.

It's about safe space. We're not just cogs in the machine. We exists as humans with our own sets of fluctuating of emotional and psychological states. Break that at your own peril.

Excellent insight!

Metrics are useful, but only with context. Any metrics reported at skip level by definition lack context: there's no ground-level engagement or time to dig into details. Ergo, the reported numbers are understood as the only numbers.

With the exact solution you offered! Use them, but only at the level in which additional context is available, then report up new numbers that allow for enriching / adjusting the base numbers.

There is an interesting parallel with overfitting [0] which may mean solutions can also resemble each other.

[0] https://news.ycombinator.com/item?id=41684082 (Too much efficiency makes everything worse (2022))

The most interesting thing during COVID was seeing the switch from in-office to remote, followed by a round of redundancies, and the redundancies were fascinating. It was full of people that when in-office seemed gave the impression of hard-working, largely by a combination of 'face time', and just talking to other employees, and not necessarily about work.

>> [Why not build programmer performance measurement tooling?]

I'm pretty sure there wasn't any employee monitoring software other than completion of Jira tickets within individual teams.

The whole sneaky monitoring/measurement software is totally counter-productive, and counter-intuitive. If I'm in an office, no one is going to care if I read the docs or an ebook, possibly on my tablet, but if I'm remote and not jiggling my mouse every few seconds I'm slacking off.

> It was full of people that when in-office seemed gave the impression of hard-working, largely by a combination of 'face time', and just talking to other employees, and not necessarily about work.

Hahah, we all know these people! They walk around the office, sometimes carrying a clipboard or stack of paper, initiating business-y conversations, always making sure they look very serious and busy, deliberately walking past the boss's office frequently so he can see them visibly DoingSeriousBusiness. When promotion time comes around, these social butterflies are always at the top of the list, because naive managers see them buzzing around everywhere, and they at least think they know that these guys are constantly doing work.

These people were panicking during COVID and WFH. Their entire self-promotion vector disappeared overnight.

Now that most companies have returned to in-person work, these hall-walkers are back and once again getting promoted based entirely on their presence and visibility.

I work now for a long history smaller organization that formalized management and organization in the past 4-5 or so years. I joined midway of this - looking my way out now - and the focus on unconnected details only was odd right from the beginning. I attributed this to me being new and can't see the whole picture, digged into discovering my immediate vicinity. But after a year seeing we are still being obsessed only about those plenty of items that fit into a sprint multiple times remained sick to me. I discovered several embarrasing mistake in design of approaches, interaction or implementation that made me scared: how this went through at all, and how it remained there for so many years? Is this used at all actually?! People should desert us not paying for such nonsense (shit, actually). Reported these mistakes in our issue tracking system and those fit into less than half of a sprint landed back on me sooner or later, almost all. Not those first being very serious, but those fit into the schedule (but mixed in seriousity at least, those being serious first). My takeaways:

- Seriousness and functionality is not the primary concern, company management is!

- Others (about 2 dozens of engineers) did not take the effort to report. I am not brighter than them, I was novice in that environment and codebase and the actual technology, also what I was reporting stands out on usage level only, no tecnological knowledge necessary.

- Apparently problems are positioned proactively on blind spot to remain unrecognised. There must be a serious level of ignorance involved.

The company lived through decades of difficulties, never had investors but built and run by the increasing number of enthusiastic loyal people. The company organization was non-existing compared to today's norms meeting contemptuous looks from today'n collaborative organizational ninjas. I am sure several of the problems stems in the casual running of the organization, but the reorganization is not helping but making things worse, preserving, leaving in. The reorganization made the company look much shinier though. It looks much improved.

As I later learned the reorganization was needed for selling the company. The founders pushing retirement age and want to cash out. Even my employement was part of that show, fitting into making the company look similar to trendy ones clueless investors can find appealing based on the facade. We are agile in all sense, we are technologically advanced (AI feature is pushed in for the sake of it), our recruited HR professional is like all other, we are uniquely successful like all others, we are team, we care of employees a lot, we have workplace well-being taken the most seriously (just like everything else in HR), we are family in matching uniforms smiling happily into the camera in a team building excercise, and above all we have top notch marketing with thick flow of photographically illustrated success stories and dynamism.

And practically our backlog does not contain serious bugs.

For the matter of how users stay with us my running theory is that there is no better choice than this. Others are similar (also the lock-in effect to something they learned and invested in is there). I see complaints, I see angry complaints now despite me being disconnected from the client facing report system, I see their efforts for trying to make it work, finding workarounds of workarounds only reporting when the combination of workarounds collapse. They try to use it, they need something like this. I feel their efforts, this is what I am doing in increasing level with Windows, and the various software tools I use. Those look similar on the surface, increasingly so and it deteriorates as we speak.

I used to work for a company that started using Gitprime to measure developer productivity. Gitprime would show a nice dashboard with stack ranked employees based on their git commits. Besides the obvious effect that it had on cooperation (you don’t want to help another developer lest they go before you in the stack rank) it had also funny effect on the code we wrote. For example, replacing old code with new code was penalized as “code churn”, so we had to write something like

  if (false) {
    // old code
  }
  // new code

In Golang projects we avoided pushing the vendors directory in one commit. Instead we had to strategically commit it piece by piece to satisfy “frequent small commits” metric that apparently is a signature of good developers.

I worked in a place where... regardless of what I did in branches, someone else would merge it and their name would be the only thing that showed up in the git metrics, because we only looked at the final 'main' branch. I'd looked at the 'develop' - where feature branches were merged before master - and I think I had something like 75%+ of the commits (over a 14 month period). But to look at the daily dashboard, I was doing nothing, and someone who was barely in weekly meetings for more than 15 minutes was doing 95% of the work.

I didn't particularly care, until people started looking at 'dashboard metrics' to see 'who's doing what'. I wasn't initially wanting visual credit, but when my contributions were effectively erased to the casual viewer, it pissed me off...

> the creative folks you really want working there bail for greener pastures

This is the main reason. Either pay 100k with boni and I work as a code monkey for some years. But even then I will bail after some time. A strategy that cannot be viable for any company, even those that just need a quick software solution to a problem. The knowledge management with changing employees only makes it even more expensive.

If you want to burn money to see the commit log glow, please do so. I am unlikely to take any ownership of the code produced, but probably will come up with a commit here and there.

Not every form of coding requires creativity, there is also a lot of mundane logic that just needs to be given form. But even those developers should not be subjected to such metrics or anyone really.

What we created in other industries like logistics and call centers amounts to slavery aside from the fact that the employees decided to work there at some point. Something that also can be disputed how voluntary that decision was. Managers with such strategies are a liability for any company.

Employee level metrics are a fast slipper slope to encouraging all the wrong behaviors. Most of what you actually want out of a good developer is not captured in metrics easily, but lots of superfluous stuff is.

I recall one of my worst managers was a guy who would nitpick the "how" of every action (email/slack to users, internal runback documentation, etc), but rarely if ever call anyone out for inaction. He was also pretty indifferent to the what (actual functionality delivered to users).

This created a tremendous bias to inaction in the team, and everyone developed slopey shoulders.. He eventually got fired but not before a lot of turmoil and turnover.

As soon as you start rewarding devs based on story points, ticket counts, response times, ticket closure rates you get all sorts of bad behavior. You'd be better served based on quarterly changes in user satisfaction metrics as thats literally all that matters - the end product.

I worked on an internal platform for a large engineering org and was responsible for choosing what features we put in.

We had the technical means to track everything from commits to reviews, jiras, deploys, etc. Some of our most celebrated and impactful features were reporting on Accelerate metrics and related. E.g. deploy frequency, size of changes, duration of stages in the dev cycle and such.

I set a very inflexible red line: we don’t expose data more granular than at team level. Ever. No excuse.

Quite a few line managers would come to me asking for “personal metrics”, and even engineers in the team were super interested in building that (“with all this data we could…”).

My argument was that these metrics are toxic and invite misuse. A second factor was that this misuse would generate mistrust from engs against the platform and damage adoption.

Instrumenting an organization thought of as a system is fine. You want to see where are bottlenecks, you want to have measurable targets for how technical work is done and how it correlates to business goals/KPIs.

You want to offer teams metrics of their delivery my process so they can take the info and implement improvements whenever they see fit, and have a data driven conversation with the business (e.g. about the right setting for the carefulness knob)

But teams are the minimum unit of ownership, we stop the instrumentation there. Sure, a team’s performance ultimately links to individuals, but that is the manager’s job to figure out.

Interestingly:

* only line managers asked for this info, nobody in a director/vp/cxo role * the most annoyed by me saying no were engineers in the team who wanted to do these features

Yes, this is the way. It's better never to gather the information at the individual level.

This is a great comment. My thought, after reading it: Why do line managers want this info? Do you think they have someone in mind for promotion, and they are looking for metrics of accomplishment?

And, cynically, I would say that senior managers don't care... because to them, most hands-on engineers/devs are fungible. What is your view about why the upper levels never ask for it?

As a former line manager, there have been two cases when I use metrics: I'm promoting someone, and I like having numbers that back up how good they are, or I'm firing someone, and I like having numbers that back up how bad they are.

I generally agree with OP, but there are times where as a manager you know exactly what is going on with your team, but numbers are still helpful.

My cynical view is that's it's to find scapegoats especially in companies that have a lot of politics or a lot of PIPs.

You generally scapegoat one level down and then let that level push it further down if it can.

So the Directors need team level metrics to find which managers reporting to them to scapegoat and have data to "prove" it.

Then the Managers need individual level metrics to find which engineers to scapegoat and have data to "prove" it.

Yo dawg, I heard you like throwing people under buses. So I put a bus under yo’ bus so you can scapegoat people while you scapegoate people.

> Why do line managers want this info? Do you think they have someone in mind for promotion, and they are looking for metrics of accomplishment?

Nah, you don't need to assume malice :)

Most times it was managers with good intentions, not realizing that those metrics were either pointless (e.g. how much code / commits does $person do), or toxic, in the sense that it leads the team to game metrics, that it prevents the manager to actually understand why the values are what they are, that it opens the risk to link them to promotions and perf reviews etc.

Explaining them all this was generally enough!

> And, cynically, I would say that senior managers don't care... because to them, most hands-on engineers/devs are fungible. What is your view about why the upper levels never ask for it?

Actually that wasn't the case. AFAIK (I left at some point, but kept a bit in touch with former colleagues) upper management started using some of those metrics to set organizational objectives.

Again, same argument. You don't need to assume malice. Management has a legit interest in engineering productivity. What happens most of the time is that they don't know how to measure it in an effective way, or how to use it to drive organizational change. Providing guidance is part of your job as a Platform eng.

So, it's a bit more than that. Let's say I've identified someone that I can't figure out what they're doing. They're just going slower than I expect given what I understand of the work. (I was a professional programmer for over 15 years before management, so this is based on the expectations of a former practitioner.)

Now, why is that? The first possibility is that they ran into a string of tickets that were just harder than we expected at the outset, and it's a statistical anomaly. A second possibility is that this person takes the hardest of the tickets, and anyone would struggle. A third possibility is they are taking tickets past their capabilities as a developer and aren't getting the help they need. In this scenario, they're a capable performer, but are need help to get to the next level. Maybe they're junior, or they're a new employee. If they keep taking these tickets, they will grow and their performance will jump. In these cases, you just keep monitoring.

In the middle case, they may have transitioned to a team or project that is a bad fit, and would thrive on another team or an adjustment to what they're asked to work on. They may be a front end specialist that was expected to pick up back end tickets and struggled from the start. Or, they may be in a temporary dip due to personal circumstances.

Then, you have the negative cases. Their work ethic might be insufficient. They may just not be good at their job and may not ever be able to match the performance at the pay grade and seniority they were hired. Or, you may have a good bullshitter on your team and your numbers tell a different story.

The numbers will tell you if this is a temporary dip. The numbers will tell you if their current output is in line with the rest of the team. From there, the hard work starts.

If you don't have those numbers, it starts looking like a lot of status updates and micromanagement.

Note: remember I am condensing the real work into a few paragraphs. Of course I know it's much more nuanced than I am making it here. This is a surface level treatment.

Also note: Most managers end up doing a lot of part time jobs, of which performance management is a relatively small part. If my primary job was performance and task management, that would be a very bad use of resources for the company.

Agreed. And "personal metrics" can also end up having a lot of consequences that were not planned for. Incentives are tricky that way. There's always a long tail of things that need to get done on occasion that doesn't show up in these types of metrics and it becomes difficult to find takers when everyone is optimizing themselves around the core metrics as bonuses, promotions, and even keeping your job in today's climate could be determined by those. It also makes allocating load to play to contributors strengths (which is often what they enjoy most) far more difficult.

Yep, this is an important point.

We wanted the metrics to create the right set of incentives to make people improve the right parts of the system.

For example, we did present deploy frequency prominently. This gets people to see it, managers to want their team to be in the upper percentiles, etc. which drives a set of practises that, in general, and backed by research, are beneficial.

One of my favourite features was putting two graphs together: size of PRs vs. time to review. Time to review went up more or less linearly to size of PRs, but past a certain threshold (different per team!) time to review dropped sharply with larger size of PRs. This made for a good conversation to topic with teams that sets the right incentives for smaller PRs, iterative development, etc. (and it happens to correlate with deploy frequency).

Might also suggest a size limit for PRs. Theres always that Golden Child who gets away with things because they are prolific. But they tend to screw up architecture because they make too-big moves that discourage feedback and negotiation.

I’ve helped build out or steer these sorts of systems a number of times and usually management behaves themselves during the adoption and honeymoon phases but then erode the trust later on by trying to use the system to determine PIP or promotion.

Devs who have seen this behavior before tend to push back hard on adoption, and then invest the absolute minimum effort in using these tools. The tools tend to be built wrong often enough to encourage that slide into toxicity. There’s an amount of using a tool where it improves your work experience, and then an additional amount that improves the team experience, and then beyond that it’s doing your manager’s job for them and self-reporting/narcing.

I’m trying to build a tool at the moment that has had three focuses due to different sources of inspiration. First it was going to be Trac (a project management tool and wiki that is so simple it shouldn’t work, but somehow does) with bits of Jenkins. Bamboo has thousands of features and integrations where it should have hundreds. All those integrations make reproducing a failed build locally difficult or impossible. The bones of a build process should be in the build scripts and dependencies, so you can run them locally. The build tool should schedule builds, report status changes, collect some release notes data, and track trends with grafana charts and that’s about it. I also want something running in each dev’s machine to boost system performance and do some of the teamcity features for trunk based dev like push-on-green-build. I just miss how distilled Trac was, but it had some problems with plugins and git support.

That sat on the Some Day Shelf behind two other projects until I read Cal Newport’s Deep Work, and then Slow Productivity. Then it became more user oriented. Atlassian has about three per-user dashboards that I’m responsible for juggling all day, and that is tragicomically stupid. I’m terrible with this sort of juggling but have coworkers who don’t check the PR list ever - you have to pester them to look at PRs, week in and week out. If I’m doing deep work I don’t want preemptions except in specific circumstances (like I broke trunk). But when I come up for air I need a cheap gestalt of what I’ve missed and what people are expecting from me. Show me all the PRs, and my red builds and open tasks in a single view. Allow some low priority alerts through. And that can be facilitated by building a pomodoro straight into the dashboard and information hiding during deep focus moments.

I have some family that was recently diagnosed as neurodivergent, and the thing about YouTube is that your suggested videos get influenced by what other people in the house are watching (particularly if you’re not logged in on a device). ND people of all types have a lot of coping mechanisms to function within other people’s expectations (eg work and responsibilities) and to mask. They get both barrels when it comes to being judged poorly by toxic management tools because their variability is so high. Best performer one day, second worst the next. And this is nowhere more true than with ADHD. And the worst of it is that almost nobody will go harder and farther than an ADHD person during a crisis. They can hyperfocus during rare moments but most reliably due to an emergency (self created, like a paper due tomorrow, or externally driven, like servers on fire). They also innovate by drawing connections nobody else sees between different disciplines.

But they’re the first on the block when toxic metrics kick in. And the productivity tools they objectively need more than anyone else on the team seals their fates, and thus they either don’t use them or use their own, which are similarly poorly integrated, which leads to more plate spinning which they are terrible at.

So what finally got me ass-in-chair in front of a keyboard was realizing that if this is two tools instead of one, you can keep some of the productivity data on the employee’s machine where it can help them with time management and self-improvement but not self-incrimination. Then you can cherry pick and clean up the narrative of your day or week before you self report. Have private tasks on your machine that may look embarrassing to others (like remember to drink fluids, eat lunch, call the dentist, tasks you’re skunkworking).

Redmine is a superior trac I think and still under development, you might like it

there's a scene from the tv show "suits" that has always stuck with me:

the show is set in a law firm, and in this particular episode they needed to lay off some of their associates. a young, newly-promoted lawyer was tasked with drawing up a list of the associates and marking the ones who she felt should get the axe, based on their performance. so she comes up with some metrics, goes through the associates' work, and ranks them based on the resultant numbers, saying that the bottom few could be let go.

there is one employee, brian, who ends up near the bottom of the list. a more senior person takes her aside and asks why she recommended brian be laid off, so she brings out the metrics and rankings and points to him near the bottom. the senior person asks "okay, so who are the top associates in your list? can you point them out on the seating chart?". turns out, the top five associates were all brian's neighbours, and the reason was that he was really good at helping people when they were stuck with something. but of course that affected his own individual contributor numbers, and there were no metrics for "helped someone else out but didn't get credit for it".

I wouldn't be surprised if that was directly adapted from the anecdotes of Harry Nyquist at Bell Labs [1].

""" After crunching a lot of data, they found that the only thing the productive employees had in common (other than having made it through the Bell Labs hiring process) was that "Workers with the most patents often shared lunch or breakfast with a Bell Labs electrical engineer named Harry Nyquist. It wasn't the case that Nyquist gave them specific ideas. Rather, as one scientist recalled, 'he drew people out, got them thinking'" (p. 135). """

1. https://en.wikipedia.org/wiki/Harry_Nyquist

The cynic in me expects someone to read this and come to the conclusion that what they really need is more data to improve their review process. Clearly we need to know who's eating lunch together!

The cynic in me expects poor performers / low contributers who read this come to the conclusion that they are the Harry Nyquist of their organisation.

The cynic in me expects people to read this thread and pat themselves on the back for definitely _not_ a being Harry Nyquist OR a poor performer / low contributor!

This by the way is an excellent argument against home office for professions where innovation plays an important role.

I don’t think we’ll ever see a Wikipedia quote saying “the only thing productive employees had in common is that they were hanging out in a Microsuck Teams chat room”.

Not entirely convinced. The tradeoff is in-office you need to sit next to someone. Remote you can talk to anyone in the world. But it is the role of good WFH culture to avoid siloing of people.

Except you don’t actually talk (as in have a real conversation) with anyone on Teams.

Maybe you don't.

I've never had any trouble having real conversations on online platforms, whether for work or otherwise.

Research shows, that is about as accurate as saying a Twinkie is real food.

Not completely wrong, but…

[Citation needed]?

I've not heard of any research that shows that it's impossible to have meaningful conversations on these platforms.

And please note the distinction between "it is impossible to have such conversations" and "some people (especially less tech-savvy people) have a harder time having such conversations" on these platforms.

Teams/Slack/Discord/etc is just another communication medium. Once our society has, collectively, had more of a chance to get used to them, and once we're no longer dealing with an entire generation who were bad managers before the personal computer even existed (</hyperbole>), I wager you'll see a lot less complaining about the medium itself.

[https://pmc.ncbi.nlm.nih.gov/articles/PMC9771703/]

[https://pubmed.ncbi.nlm.nih.gov/35648039/]

And overview [https://www.psychologytoday.com/intl/blog/the-brain-body-con...]

OK: all three of those are specifically about "Zoom fatigue".

None of them in any way address the issue at hand, which is the ability to engage in meaningful conversations over online platforms such as Teams and Slack.

You’re moving the goalposts quite a bit.

I said they weren’t the same as in person.

The reason for zoom fatigue, as the papers call out, is because zoom or similar is fundamentally different than actual in person conversations.

They are missing something important. Several things which are important, actually.

Just like twinkies vs ‘real food’.

Your post that I originally responded to:

> Except you don’t actually talk (as in have a real conversation) with anyone on Teams.

That is the specific argument that I am refuting: that your experience of not being able to "have a real conversation" on Teams, etc, is universal, rather than just being your experience, which cannot be extrapolated from without gathering significant extra data.

"People get Zoom fatigue from having too many video meetings (especially in the first 2 years of regularly using video meetings after never using them before)" is not the same thing, and does not prove that these technologies are impossible to use as a replacement for in-person meetings on a wide scale.

Did you read the papers? That is literally not what they are saying.

If I have one twinkie, that isn’t a problem - because I have other ‘real food’ to compensate. Same with someone doing zoom periodically.

If all I have is twinkies, that is a real problem, because I don’t have enough real food to compensate. I’m missing some essential vitamins, minerals, and macros that will eventually hurt me a lot. Plus a lot of sugar that causes a lot of load in my body we really don’t handle well.

‘Zoom fatigue’ is exactly because people aren’t having enough real in-person interactions anymore and it’s causing numerous real psychological issues in people because of it.

Because there are actual necessary things in real in person interactions that are not present in video conferencing. And real effects of doing video conferencing our minds don’t handle well.

The insistence on ‘but it’s not impossible!’ is tangential to the fact that it isn’t a good idea to do long term or exclusively.

And depending on the individuals environment or makeup, it could be an immediate major problem, or it could be a slow burn. Everyone will have a different tipping point.

I’m sure there are some 1-in-a-million outliers out there that could stay pretty functional literally eating just twinkies for a decade (somehow).

But either way, having the social interaction equivalent of an all-Twinkie diet is a bad idea.

Near as we can tell.

But ‘this is America!’, with an ongoing obesity crisis, so not like I expect people to just listen.

TBH, I've been on teams where the chat was a constant stream of activity. It works really well and involves a lot of people that might not be involved in decisions otherwise.

I've also seen the room be quiet way too much on some teams. This is always bad, but hard to fix.

The worst is when the team chat rooms are quiet because each member is in several private rooms or group-chat conversations doing the actual work in there.

Regardless of the reasoning, it's toxic to WFH/remote work, even in the short-term. And it's outright sabotage in the long run when it's time for someone who wasn't invited to the "correct" chats to onboard a new hire who ends up needing some context that exists only in someone else's private chat.

I try to move into team chats. If I have a private chat that ends up with useful info I will dump it on Confluence. Keep things searchable!

In my very limited experience this happens when managers (above team leads) insist on being present in chat rooms. No offense to any manager in this topic, I know that you mean no harm in 99.9% of cases and that you do want to make things better, but honestly your presence creates a chiller effect. Jokes are no go, because who knows, maybe this one will be interpreted badly. Local questions are no go, because you can't ask them during work time (he's slacking!), you can't ask anything which can even remotely be treated as improper. Can't show that you lack knowledge in things which should be obvious, can't banter about colleagues or about work in non-positive way. And the list goes on. We have a chat with 100 people which started as a meme and joke one, a lot of people were posting funny stuff there. Now the last meme picture posted there in mid october, and the second to last was in august. And the only people posting there at all, even sirius stuff, are the 3-4 teamleads very close to the management. Same shit in the chat of immigrants, we have a quite a few semi-permanent relocants on the projects, but manager is not one of them and is still present in that chat room. No one posts there, everyone talks either behind the scenes (because there are a lot of questions for people in new country) or in the independent big chats outside of the company.

And again, it's not like our managers are bad, quite the contrary, they are very good professionally and personally. And we don't have layoffs. But people still won't talk in the presence of even mid level management, it's an instinct of sorts I guess :) .

PS: this is only about informal optional chats. All work chats are never hidden or avoided. We divide them by program, Slack for work and Telegram for fluff.

We actually have a "watercooler" channel that specifically doesn't include manager people. It's where all the non-work stuff gets posted and it seems to work out pretty well.

Do we work at the same company? Don't forget the constant stream of meetings where noone takes meaningful notes, and everything just gets stored in a context-free diagram, or someone's head.

It looks like literal sabotage in the long run. Of course, the ones that have the info in their head are more valuable in such a system.

In a past life the room all the programmers was in was quiet as a library. Anything above a whisper seemed like yelling. It was terrible for collaboration and communication. We ended up going for walks in order to talk about stuff, which actually helped in multiple ways. Walking seems to stimulate the brain in weird ways and talking freely was very productive.

That said, I would not trade WFH for anything. Those walking times with co-workers was great but it's not worth being forced to go into an office every day.

Fair enough.

As one potential mitigation, I’ve consistently had deep mentorship conversations over the phone. For me, I think voice-only is actually much better than in person.

    > For me, I think voice-only is actually much better than in person.

This is interesting. Can you explain why? To be clear: I don't doubt you, but I have never seen a comment so specific about this matter. I would like to learn more. For one, I assume you said "voice-only" specifically to exclude video calls, which are a special kind of hell, when compared to in-person discussions. (Staring at yourself and only seeing the other person's head always struck me as a bit weird / artificial / Uncanny Valley-ish.)

Interesting question.

I agree that video calls are a special hell.

I think I am reasonably high functioning in in-person settings, but I suspect I don’t read body language very well. I find eye contact difficult to maintain for reasons I do not know.

On the phone, I feel like conversations can be slower and more deliberate. I feel a freedom in not having to control my expressions and show my interest. I can just focus entirely on their voice, and I feel I have become very adept at this. I love podcasts and audiobooks and such, maybe there is a connection.

My wife describes very differently dynamics. She wants to meet with folks in person to “read” them better. She thinks my preference for phone only makes no sense.

This is a great reply. You are someone who has thought deeply about this matter. Thank you to share!

    > I find eye contact difficult to maintain for reasons I do not know.

Years ago, I asked my mother why she always sits next to my father when they go out to eat, instead of across (face-to-face). She told me: "It's less pressure vs face-to-face." To be clear, I would describe my mother as a social normie (not autistic), but it really struck me. Over the years, I have changed my seating style to sit next to people (even when only two of us). For me, it makes a difference. Side by side, you can kind of talk forward or slightly angled and the other person can hear you very well (assuming no hearing disability!), but you don't need to make constant eye contact. That said, from time to time, you really want to make a point, and you tug on their sleeve or turn your head... you make eye contact, but for a short time. (Also: Without dragging on too long about this topic: You can more easily make physical contact -- touch! -- which can really help to connect, even in non-romantic settings.) I'm not trying to run away from eye contact, but my mother's comment was insightful: In-person need not always be constant eye contact.

Interesting. Yeah I quite like a walking meeting for the same side-by-side kind of thing. I imagine meetings over golf would have similar dynamics, but haven't ever tried that.

Not necessarily. There's no clear indication that you need full time (or even an amount of time measured in "X days per month") to get these benefits.

Did you or anyone else has actually observe any such processes? I mean employees A and B meeting at any place which is not a workplace or any of them (because meeting at workplace means one of the pair has come specifically to another, and that is mostly equivalent to calling that person by phone, on full remote) and there spontaneously talked about work topics generating previously unheard idea useful for the company?

If the and answer is yes, then what was the rate of such encounters per number of employees?

And finally - honestly answer yourself - does this minuscule probability worth the ~30 full awake days in every years of life, of every employee? (2 hours commute per 250 days in a year, then divide by 16 awake hours per day) For me the answer is obvious - it is not even remotely equal in value to such a gigantic time waste. If that super brainstorming even real at all. Personally I've never observed this.

I don’t think about this at all in terms of numbers.

Home office nudges towards isolation and lack of physical activity, while the office nudges towards interaction, moving at least a little bit and face to face interactions. No matter the outliers, the latter are considered universally good.

I’ve noticed that when I am in the office I usually have nice conversations with colleagues at lunch, that are good for my well-being. Sometimes we discuss interesting news from work, or their projects or other technical topics. We’re not Bell Labs of decades ago so the impact is obviously not large, but it exists.

My commute is 15m by bike. Even so I don’t look forward to going to the office because of various factors, but I do usually enjoy it when I’m there.

> Home office nudges towards isolation and lack of physical activity

You say this as if it's a fact, but with an extra 1-3 hours of my day freed up, it's a lot easier to get into the gym or visit my friends and family. Personally, I was more active and less isolated when I worked from home.

I like talking to colleagues in person too, it just doesn't worth 1 month of my life per year. And 1 hour commute was really a median, we had people taking longer commute. Even for me if there was any rain/snow/accident on the route it would jump to 1.5h or more. And that is inside the city, I'm not even mentioning people who commute from the suburbs. 15 min is a really privileged option. Also even if someone wins in the commute lottery, it most likely doesn't transfer to the next job and commute would be much worse.

Anecdata: I work from home and spend about a quarter of my time helping colleagues.

I think you’re wrong, but in an important way that deserves discussion, so please enjoy an upvote. First of all, innovation and productivity are not necessarily connected, and in many cases innovation is not at all what management wants or the business needs. (Using Jira is a sure sign that management does not want innovation, yet we see it in widespread practice.) Second, the quality of the colleagues males a huge difference. Not every workplace is golden age Bell Labs. Most people don’t have a Nyquist down the hall. I used to sit shoulder to shoulder with a guy who had YouTube videos on his second monitor all day long, to help him focus. Evidently it worked for him, he was a very solid contributor, but neither my productivity nor my ability to innovate were helped. (Like Jira, the open plan office is a sure sign that management values observable units of effort over either productivity or innovation.)

Counterpoint: comp.os.minix

There are famous groups/chats that allowed the creation of stupendously important software.

As much as I hate to admit, I agree.

The effort, intent, and practice (for lack of a better term) required to get the same effect in a remote environment is high enough that it just doesn't—and won't—happen for all but an extreme few.

And there's less of a "rising tide lifts all boats" effect on teams, where the growth of one member tends to level up the rest.

It's just way easier and cheaper to get this effect in person than trying to do it remote.

I have been accused by a number of people who like me of “asking good questions” and of asking difficult questions by people who don’t.

I sucked at school until someone opened up the idea for me around third grade that how the curriculum is taught is just the teacher’s opinion, not a law, or a religion. If you can reframe the material in a way that makes sense to you then do so. I ended up spot-tutoring a bunch of people over the years because I would hear them complain about how the material made no sense and I would swoop in and say, “yeah how they teach this is bullshit, have you tried thinking about it this way?” Which validates their frustration and then gives them a life raft.

That kind of reframing to keep up can become reframing to get ahead. I went from Problem Student to grade school “valedictorian”, to polymath. Years ago we were all fixated on the trap of Expert Beginner and I would half-joke that I was instead an Expert Journeyman - able to quickly get to adequate instead of mediocre in a new discipline. And these days I think that may be what “polymath” is most of the time. Just knowing what the next question is to ask to keep going. The big breakthroughs come from people who become experts in most fields, but these same sorts of people also get pretty good at music or painting or writing as a hobby. As good or better than mediocre professionals.

The first time this happened to me in a professional setting, a coworker was stuck on a SQL problem and insisted I pair with them to help debug it. I told her I’ve never touched SQL, just worked on some bespoke data processing. She didn’t care. Come here anyway. And I’ll be damned if I didn’t help her find her problem by just asking her what this part does and that part does. Why does this work that way? And I started writing SQL a couple weeks later, substantially off of just that interaction, bolstered by what first generation search engines could scrape together.

And the thing is when everyone asks you questions and you don’t break their trust, you quickly learn where all the bodies are buried in the project/org. Which is a valuable asset for someone wishing to become a lead or staff engineer. I became lead by popular vote most times, rather than an actual game plan to get promoted. I just did what thought needed to get done and was within my abilities, which looks a lot like leadership, especially if management doesn’t have that quality. Port in a storm, that’s me.

But I’ve never ever completed the most stories or features. I’ve occasionally fixed the most bugs, the most performance issues, or workflow problems. Is calculated I saved forty man hours a week for the team on code-build-test-push ergonomics and my shitheel boss was still made about my productivity those two quarters. I could not show up to work and still be contributing 8 hours a day, dummy.

I have posted a few times here about this issue. Honestly, you need to protect yourself first. If your line manager is anything less than amazing and very involved, then helping your teammates "too much" is an easy way to miss promotions and pay rises due to lower year-end ratings.

As someone who has both built and used different off the shelf tracking tools I've always found that they were terrible for evaluating individuals but great for evaluating teams (and by proxy the manager).

> there were no metrics for "helped someone else out but didn't get credit for it"

Employees should be evaluated, by their peers, their managers, and their subordinates. Wherever possible, the evaluations should be qualitative rather than quantitative.

Trying to automate performance evaluations and boil your employees' contributions down to numbers in a report is both idiotic and inhuman.

Everyone knows the terrible team members, and everyone knows the outstanding team members. If you need information to inform layoffs, promotions, or raises, the best way to get the information is to just ask.

One project I was on someone added a tool and posted the results of the past week of number of lines of code added, my count was -5900 and I had been put at the bottom. This was a legacy project.

Its pretty easy to explain why removing a bunch of complexity and replacing it with something smaller and meeting the customers requirements better is obviously the goal on any project. Everyone that added lines had made things more complex. Its obviously a useless measure for productivity or saying anything of note about the work at all other than the lines of code making up the project and how it is changing over time.

Even if you insist on having these metrics and using them - it's another level of stupid to measure lines of code added instead of edit distance.

“One of my most productive days was throwing away 1000 lines of code” ― Ken Thompson

-2000 lines of code, Bill Atkinson, Apple Lisa Quickdraw developer

https://www.folklore.org/Negative_2000_Lines_Of_Code.html

Removed LoC should count double.

Edit:

But then again, the point is not about individual examples really – the point is that whichever metric you choose, with time you'll see diminishing returns followed by negative ones.

In case of doubling removals, you can easily game it by dumping json files for tests, then removing them ie. in favor of generator etc.

What's interesting is universality of this phenomenon (strong goodhart's law?) – overfitting in llms, using metrics discussed here and why it makes sense to vote on opposite ruling party etc.

That is how you end up with a unreadable code where everything is a oneliner and there is no comment and no documentation :D

Absolutely agree, added edit, should have posted long answer instead of update with clarification, my bad.

Related, research: "Humans solve problems by adding complexity, even when it’s against our best interests"

Article: https://www.washingtonpost.com/business/2021/04/16/bias-prob...

Study published in Nature: "Adding is favoured over subtracting in problem solving" -- https://www.nature.com/articles/d41586-021-00592-0

> A series of problem-solving experiments reveal that people are more likely to consider solutions that add features than solutions that remove them, even when removing features is more efficient.

> ...the authors observe that people consistently consider changes that add components over those that subtract them" -- be it bricks or regulations, so it works like this for real as well as for abstract things.

I reckon that depends.

Coporate culture encourages adding. Half your job is justifying keeping your job. It takes a lot of swagger/social capital/clout to subtract and be loved for it. Or you need to work somewhere (a company or protected team) with a first principles thinking culture (and not a cargo cult one) which is very rare.

In personal life I think people do often subtract. They give up X where X is harmful. They simplify. Not everyone but many. It feels like a natural part of life.

> even when removing features is more efficient

Efficient in what sense ?

> Our conclusion is that people systematically overlook subtraction; it’s not that subtraction is always better

My personal experience agrees with these findings, but I think they missed something more important. People try to change things because they want to see something new in the real world. But from ideas to real world impact there is always at least one level of 'approving' you will have to go through. And adding things will generally have less risk associated.

Besides that, I think our education system doesn't train us to remove things. Everything we learn is incrementally built upon what was already there. So our default mode of thought is to add things.

Now imagine we have 2 developers, one how always solves problems by adding something new and another one that always refactor things to keep things efficient.

My guess is that by only adding things you will end up delivering more features with less bugs. Sure your code will be slower and at some point it will become impossibly complex to manage, but it takes quite a long to time to get to this point.

After writing this message I've realized that 'making things easy to delete' is a pretty important feature.

People try to change things because they want to see something new in the real world

my personal feeling on this is rather, removing someone elses code is like dismissing their work. and generally i don't want to do that. if it is not clearly a bug, then i'd hesitate. someone wants this feature. taking it away would not be nice to them.

it may be similar to the problem of design by committee. everyone wants to get their favorite features in, and we are more concerned about our relationship to our colleagues than the end result. here, we can solve this in a way to make everyone happy, but without stopping to ask if removing that mis-feature would actually make anyone unhappy.

thinking further, i think this is also a problem with personal ownership of code or features instead of team ownership. this feature is owned by X, i can't remove it without his permission, or without a discussion in a meeting. leaving it in and working around it is the path of least resistance

Whether or not removing features might be "more efficient", in nearly all cases, if you remove a feature that's been part of a software package—whether external or internal—some nontrivial fraction of the people using it are going to be angry, because you just broke their workflow.

The only way you can possibly avoid this is if, in addition to removing that particular feature, you add a feature that does the same thing fully automatically, and does so correctly in every instance.

(Even then, some people will complain about it, but at that point you just have to accept that as a cost of progress.)

You probably would enjoy this book "Subtract", about the science of less: https://leidyklotz.com/media/

That's not useless at all, the moment I saw -5900 I knew that was the most valuable contribution to the codebase.

I gave myself carpal tunnel replacing over a hundred copies of the same five lines of code with an n² complexity with a single implementation, so then I could fix the perf issue later. -500 lines over a holiday week, which was nice, but not as nice as landing the changes to the shared function and making 2/3 of the app 10x faster with the test data, which was ultimately going to be a fraction of the real data.

Don’t large scale refactor in vim folks, especially if you haven’t memorized all of the shortcuts (I hadn’t discovered block indent until weeks later. Ouchie)

If vim's macros and the per line ":norm @q" style didn't exist i'd want to stand on the edge of a bridge with one foot on a banana peel.

I've worked at a company for 6 years and still been net negative a thousand lines of code for the project I was on the entire time!

It's the job of a manager to know what their reports are up to, and whether they're doing a good job of it, and are generally effective.

That's true, but it's not what employee metrics tools tell you. If you're using metrics tools to measure productivity then you're not really being a good manager. Metrics tell you are the quantitative details (eg a count of how much output there is), but as a manager what you actually care about in your day to day work is the qualitative details (eg how good the output is), how happy the team is, where the conflict is, etc. Metrics won't tell you that.

But...

Being a manager is about more than just getting people to do their job well. You also need to plan things, you need to know what's changing over time, you need to test whether your processes are working. I use metrics to measure the aggregate impact of my influence on managing my teams, not that of any IC on any of my teams. Employee metrics are useful for a big picture view.

> Employee metrics are useful for a big picture view.

Which "employee metrics" do you find useful for that?

Because in my experience, it's pretty much guaranteed to be someone who isn't anywhere near leading on the type of metrics these discussions are talking about - that's making the biggest impact and amplifies _team_ productivity. Those people don't close a dozen Jira tickets before lunch, they are the people who spend two weeks actually finding and fixing the root cause of that one annoying ticket that 15 other people have closed only to find the problem re occurs. They aren't top of the leaderboard in git commits, because they actually read the RFCs or dependancy source code while working. They sure as hell don't always write the most LOC in a week - I want the "minus 2000 lines of code" guy, not the one who's best at gaming whatever metrics you use.

https://www.folklore.org/Negative_2000_Lines_Of_Code.html

I don't even look at the metrics for ICs. If a team has an underperformer I expect the lead to be handling that, with my support if necessary.

The metrics I find useful are things like trends before and after a change. For example, if lots of PRs are taking a long time to get through review because the descriptions don't get filled in well, I want to look at the time code spends in review before and after updating the PR template. Or before that, I want to see which teams have code in review for less time so I can look at their PR process and suggest changes to slower teams that the faster teams have already implemented. If a team is doing the same stuff as other teams but their typical PR size is much bigger I want to know if they have fewer stories that they should be breaking down further. And so on.

None of this is data I don't have a gut feel for, but having real numbers is useful for making a case for change. People don't always believe instinct. It's harder to argue with a well-designed graph.

It is also super hard to look at trend of "gut feeling" or "instinct".

Seems like lots of people discuss here false dichotomy and I really like onion2k explanation because it is much more nuanced and basically explains the same thing I was trying to convey in other thread on similar topic.

How do you collect & display these metrics, manually, internal tools, or a product?

I'm often asked to provide employee metrics but my product is just an automated time tracker for contractors & devs, who bill by time. I've avoided it being used as employee metrics, but we recently built a separate product for these trends and team insights that you're using.

May I email you to the address listed in your HN profile? Just for an informal chat.

You can reach me at alan@wakatime.com.

I use Jellyfish. Happy to have a chat. Fire me an email. :)

I feel very seen.

I’m at my happiest when being grease or glue; when I unstick the stuck, or stick the unstuck. I like to “walk the property”. Find the bugs that are under rocks.

I’m not at my best as a mere construction drone piling on work for work’s sake. That’s soul-killing, for my soul, at least.

hello my fellow troubleshooter:-D

> it's pretty much guaranteed to be someone who isn't anywhere near leading on the type of metrics these discussions are talking about - that's making the biggest impact and amplifies _team_ productivity

It would be great if everyone on the team had different strengths that contributed to team productivity "A smashes out small features like nobody's business", "B is great at debugging", "C is great at planning and seeing through big long-term features", "D is great at helping teammates" etc.

However in practice I find you have a minority of team members who can do _all_ of A, B, C, and D's tasks well, and a mediocre majority who deliver between 20% and -10% the productivity of the talented minority.

> They aren't top of the leaderboard in git commits, because they actually read the RFCs or dependancy source code while working. They sure as hell don't always write the most LOC in a week - I want the "minus 2000 lines of code" guy

Yes, these engineers are invaluable. But the "minus 2000 LOC" engineer is rare.

In my ~25 years of experience at several top companies, I've seen that --more often than not-- the most impactful coders are writing the most LOC. And they're not gaming it either. They are simply writing a ton of high-quality code: features, bug fixes, optimizations, cleanups, etc. Yes, occasionally there is a crazy heisenbug that takes 3 weeks for a one-line change, but that is rare.

Note that I deliberately use the word "coder" (which I don't usually do) instead of the more generic "engineer." Because I'm not talking about those critical senior engineers whose job is mostly to prevent others from writing bad code.

Agreed. At the end of the day - the end user of the software probably wants something other than technical debt reduction, so it's not surprising impact and LOC can roughly be correlated.

Taking the LOC metric too far, in either direction, is trying to read too much into a single metric.

> Being a manager is about more than just getting people to do their job well. You also need to plan things, you need to know what's changing over time, you need to test whether your processes are working. I use metrics to measure the aggregate impact of my influence on managing my teams, not that of any IC on any of my teams. Employee metrics are useful for a big picture view.

The point of the article is exactly that such metrics don't give you any kind of a good signal unless you are really into the fine details. And if you are, then you don't really need them in the first place.

> quantitative details (eg a count of how much output there is)

For example I recently spent a week producing several thousands of lines of tedious trivial code that parses some configuration out of JSON file in pure C. Then I spent a month writing less 1k lines of very dense low-level packet parsing code and the main loop also in C. So the metrics would show you the big picture of me slacking and my performance tanking which obviously wasn't the case. You can't substitute actually knowing and understanding of what your reports are doing with some tools providing you with trivia like number of commits, lines of code changed or tickets closed.

Being a good manager is taking in all the metrics (+other information), assigning the appropriate weights to them and making informed determinations.

If the worker changing your code style from snake case to camel case does 500 commits in a day they are not a 100x programmer vs the worker solving world peace who did 5 commits. If their commits drop to 1 a day then maybe reach out and see how things are going, solving world peace has a lot of dead ends and bottlenecks.

I'm an Engineering Manager for a large company and have been for a number of years. For our large team we will rank the team based on perception of managers. After that we will then manually collate coding stats from all repos we work on. Unfortunately for the consensus view here and in the article, you get a 100% hit rate on who you think poor performers are and the lowest coding contributors.

For top performers it's more nuanced. In general they will be top of the contribution stats but sometimes if they're doing R&D or hard work then the stats are not very meaningful. But that's why we don't rely on them.

So metrics have their place to inform and color existing perception. But they will rarely change perception completely.

Qualitative and quantitative approaches together inform us best. Probably not the most eye opening of statements.

But I think as you indicate, qualitative generally paints the picture, and quantitative validates it.

> Unfortunately for the consensus view here and in the article, you get a 100% hit rate on who you think poor performers are and the lowest coding contributors.

This is circular logic. If you measure that "coding contribution" nonsense, people's "performance" will be perceived based on that, _especially_ by their direct managers.

I’ve seen cases where folks completely checked out and were contributing nearly nothing, making no commits, writing no code, and faking it at standups. Simple metrics can help surface cases like this.

I agree that it’s something a manager could over-index on. I’m not sure how to avoid that beyond adopting a mindset of “this is noisy data that sometimes gives you important insights.”

> I’ve seen cases where folks completely checked out and were contributing nearly nothing, making no commits, writing no code, and faking it at standups. Simple metrics can help surface cases like this.

Of course we've all seen varying degrees of this - but these kind of people can only exist because of terrible management. Throwing metrics at the problem just introduces a more insidious version of this individual, one that knows how to game whatever metrics are used (managers especially will do this). I've been on teams where such an individual could thrive for years, even with promotions, and on teams where such an individual would be outed within a week.

In one of those cases I was the bad manager. The data was a wakeup call that made me understand the magnitude of the problem.

In another case, I knew the manager well, having been on his team before. He was effective, empathetic, and inspirational. He was also overworked and perhaps a bit naively assumed good intent from everyone. The data let me explain to him that the coworker was not contributing and he had a real problem.

If you need metrics to see an employee isn't doing what you assigned to them, what are you even being paid to do?

Inflating the engineering department head-count, a very important metric for c-level resumes.

You’re being paid to make your whole team as effective and capable as possible while satisfying your leadership and stakeholders. And to help your boss do that with his team by developing your peers. And…

Detecting slackers efficiently is simply never going to be a top priority. You have to trust your people. Usually it’s incredibly rewarding.

> “this is noisy data that sometimes gives you important insights.”

This is called "broken clock shows the right time twice a day."

Also c'mon, fooling commit metrics is silly easy, just _also_ one of the most burn-out and check-out inducing things ever. And at senior level you _HAVE_ to do that these days. You _have_ to inflate them.

Your broken clock isn't free.

Amazing. You just proved her point with data and then drew the exact opposite conclusion.

Companies love to collect their data, and they love their AIs to analyze that data. But they ignore the easiest to collect data and the strongest AIs available; these AIs are so good you could just call them Is.

I've always wanted to see regular anonymous mass surveys of employees, about things like project progress and completion dates.

Do you want to know when a feature will be finished? You can analyze story points and build a fancy burn down chart, or you can just ask the people working on the feature. Allow the entire team to anonymously predict when the feature will be finished and I'll bet you get a better answer.

Anonymity is important because people are easily pressured into changing their answers. We've all been asked "how long do you think this will take?". "Two months" you answer. Then managers pressure you into changing your answer, but usually, no matter what you're forced into saying, you still think it will take two months.

Why did they ask if they didn't want my answer? Therein lies the truth. Companies don't want accurate answers and data, they want to see and hear what makes them happy right now.

I don't think most companies would have the courage to regularly gather data with anonymous surveys.

But maybe, if one clear-headed and high-level executive wanted to force it on the company, they could. They could mandate the use of a software tool to do anonymous surveys, and no matter how much lower-level managers complained, the team could still anonymously say when they actually believe the project will be finished. Etc.

> no matter how much lower-level managers complained, the team could still anonymously say when they actually believe the project will be finished. Etc.

This would result in lower tier managers announcing beforehand they claimed "x time for y project" and if the devs want their sickdays/bonuses/promotions they should claim same.

The survey I'm imagining is just "rate the progress of project X from 1 to 10 (1 being just started, 10 being complete)"[0], and also "rate your happiness from 1 to 10", and "rate the quality of the work done from 1 to 10".

This would be anonymous, the only thing that wouldn't be anonymous is whether or not an employee has updated their survey within the last 2 weeks.

I would absolutely throw that hypothetical lower-tier manager you mentioned under the bus. The surveys could have a "rate your manager 1 to 10" question too.

I think it would be valuable insight to all levels of management. If the team is being death marched, happiness and quality surveys would drop. Or, if you see a team deliver a buggy project, but quality surveys were high all throughout development, then you could tell that the team was incompetent and hire/fire/train accordingly.

[0]: Don't ask people to guess completion dates, have them guess percent completed and then calculate completion dates in the software.

We get supposed "anonymous" surveys where I work and I see the hash at the end of the URL, and we've confirmed amongst a few of us that they're unique, and so the assumption goes that it's actually not anonymous at all. I don't think I would ever trust an "anonymous survey" from an employer to actually be anonymous. Maybe if it was hand written.

If the URLs had all been the same, then would you trust that it was anonymous?

Employees could lie about their own happiness, and satisfaction with their manager, to their own detriment. Employees could also lie about project progress and quality, also to their own detriment, because it looks bad if a team says "everything is on track, quality is great", and then the project runs long and is a buggy mess.

I just think a lot of what a manger does is give progress reports, and it's easy for one person to lie about progress reports, and then when it becomes clear that the progress reports were wrong all along, the manager somehow shifts blame to the workers. These surveys would give everyone a say in the progress reports.

I don't see how any deeply honest, earnest feedback can come from me when I am told "this is anonymous" and there's a 99.999999% chance that it isn't. If it came from a position of mutual respect then maybe I'd reciprocate, but it doesn't.

It's hard for me to take any of this seriously. Industry-wide we're told layoffs have to happen and these same corporations go on to post record numbers, far exceeding internal and external expectations. Executives are lavished with bonuses while many of my colleagues are getting < 2% CoL adjustments while taking on more and more responsibility and accountability. But also, please, tell us what we can do better! We're listening and we care.

So, no, frankly I don't feel like I owe my employer a single fucking thing beyond showing up, doing my work, and leaving. I certainly don't owe the top-level leadership team the truth when they aren't honest with me.

But I want to make it clear, too, that I'm not lying on these surveys. But, they're not getting a full accountability from me, from my perspective, either. And even if I wanted to give that, it'd be pretty hard when the questions are worded in such specific, guided ways and there's very little space for providing direct feedback.

I'm not saying these are the only questions that should be asked, or that this should be the only way of getting feedback. I suggested questions for a 30-second weekly survey. I think longer surveys with more detailed feedback should be done periodically as well.

And, if you decide to just always say things are going well, then that's what management will see, and the status quo will remain. At least until a project goes poorly--delivered late and a buggy mess. Then, if I were a high-level manager, I would look at the surveys and see that the team was happy and believed everything was perfectly okay right up until failure, and I would judge the team as incompetent, because a competent team would see failure approaching long before it happens. I'm not saying I would fire anyone, but clearly a discussion needs to be had with the team manager, and probably the whole team, about reporting problems early.

Of course, if a company wants people to report problems early, then they need a culture that responds well to early warning signs, rather than the shoot-the-messenger culture that is all too common. I do sympathize with your frustration for fucked up company cultures.

I would never treat them as anonymous. Expect that even if told they are that at some point someone could access your answers, for whatever reason they may have. I don't think you need to lie on them but I'd probably hold personal criticisms back and use a gentle touch. In essence, be positive and likeable.

Yes, I don't outright lie or try to sabotage, or otherwise do anything anti-social like that, but I approach it from the position that I am in fact standing in a room with an executive being asked these questions and if I were in that position how would I answer?

The main thing is to be sure to do them and not ignore them. They're "engagement surveys" and the first metric to determine engagement is if the employee engaged with the survey in the first place.

Shopify had this between ~2017 and ~2020 -- every project was expected to complete a "health check" every two weeks where anonymous participants gave a 1-3 score on various metrics including velocity, quality, making good decisions quickly etc. You couldn't see the scores until everyone had answered and there was cultural pressure towards honesty. All that was stored was the average score and optional comments.

If you left comments, it was generally possible to figure out who said what based on idioms etc. but they were kept separate from the scores anyway.

I thought it was a good system but I'm pretty sure it was gone by the time I left in 2023. If nothing else, I don't think a system based on that kind of radical candor can survive the first or second round of layoffs at any company.

This is exactly why deadlines in tech are such bullshit. It's my personal experience that more times than not I'm told the deadline as opposed to us reaching some kind of agreement. It's reasons like that that I have hard time taking it seriously when I'm told we're late. It's more like you're "estimate" was wrong or you demanded completion date was too aggressive.

My GH activity graph[0] is pretty full, but some of the days with the least checkins are ones where I did the most work.

I had a day like that, a couple of days ago. I spent a significant portion of the day, building experimental approaches to handling an issue, but reverted, at the end (the experiment did not yield the results I wanted). That is fairly common.

Also, a big part of my reflective refactoring, is reducing codebase size, like factoring out common functionality into protocol defaults, and/or base classes. That can take quite a bit of time.

So LoC/Time is pretty much a worthless metric.

And if you cloc my codebases, the comments/code ratio is usually about 50%. Documenting my code[1] can take a lot of time, as well, and is actually a fairly important part of refactoring, as I often find issues, when I have to explain what’s going on.

[0] https://github.com/ChrisMarshallNY#github-stuff

[1] https://littlegreenviper.com/miscellany/leaving-a-legacy/

And that's not even starting with the questionable morality of using GitHub in the first place (~ after Microsoft bought them)... (especially for non-US developers)

Eh, I don’t lose any sleep over it. There’s bigger fish to fry.

Yeah, leaving aside other concerns about platforms, Microsoft, and the USA, I too want to stress how GitHub is problematic in GP's «some metrics are bad» sense : the social networking aspect, stars, number of projects, and, as you say, number of contributions and number of lines of code.

Yeah, that stuff is pretty ridiculous, but I think a lot of it predates Microsoft.

There's a big school of thought, that "gamifying" things, brings "engagement" (the holy grail of SV).

I'm old and cynical. It doesn't really do much for me, but it is a well-integrated hosted solution, and that's what I get from it.

well, yeah, they are themselves goodharting the metrics that vcs use. it's fake metrics all the way down

Also, those tools don't show everything. Someone here told/linked to a story about this guy who had like 0/100 on their automated performance scores, because he was sitting down with juniors and asking relevant questions to get them on the right track and generally keeping the ship together. People do a lot of work that isn't legible to automated tools, but which good leaders can and should recognize.

> "Peer reviews actually improve things" is about the biggest crock of shit that people in tech still believe in.

God that hits home

Does the author mean peer review in the performance review context? Or code review?

Performance review, as per the linked post of theirs: http://rachelbythebay.com/w/2021/02/19/perf/

Thank you

Ahh that makes a lot more sense. Peer review was probably some of the best thing's I'd do at workplaces. Helping to point out thorns in my eyes and vice versa. There could be a bit too many LGTM comments, but I always welcomed having a second set of eyes.

It can also help me scope commits. I definitely had a habit early on to bundle maybe 4-5 commits worth of code into one review; I figured it would waste their time a lot less. Fortunately I was taught early how that was a bad practice for multiple reasons.

I took it to mean in the performance review context.

I learned years ago to either give constructive mutually agreed upon ahead of time peer reviews or not give any. I always run this type of stuff by the recipient to make sure that it isn't a surprise. Not too long ago I had one cartoonishly insecure coworker recruit another colleague to their cause of poo-pooing me. The latter wrote something like "they care more about doing things right than delivering quickly" because I surfaced too many obvious architectural issues in my PR comments (actual ones where they departed from our mutually agreed spec, not trite OO pedant nonsense). Thankfully my manager told me of it and dismissed it in much the same manner I did but I didn't feel great about being thrust back to junior high school social behavior.

There's being polite and then there's this. You're throwing the baby with the bathwater. Don't do this. Claim this as an achievement and proof of your integrity instead.

> "they care more about doing things right than delivering quickly"

Is it actually supposed to be a negative review...

> Thankfully my manager told me of it and dismissed it in much the same manner I did but I didn't feel great about being thrust back to junior high school social behavior.

I had an interesting interaction years ago where an engineer in my team shared his fear that a negative peer review would shape his performance review. I made a similar point to him: as the manager, I read all feedback but it’s my judgement as the manager that determines the review.

If I’m just parroting the comments of others and treating the review as just taking the average then I’m no better than Metacritic!

In my experience it's not just the judgement of the manager but the judgement of their whole reporting chain. All of which can read the reviews and may be the ultimate decision makers on promotions/ratings.

Yes, it does depend on the organisation. I do expect my manager to read and have input on my reports, as my team’s outputs indirectly affect my manager’s outputs.

I question the value of this the higher up the chain it goes, as managers get more and more removed from the people doing the work. That said, it does happen and it’s not always a good thing.

In those situations, you can address the comments directly in the review, or summary, but you can’t directly control what other people take out of the reviews.

What you are experiencing, and what is being described is not peer review.

The skill of giving feedback was lost a few days after the skill of recieving feedback was lost. Actual peer review no longer exists.

I agree with the spirit that these metrics shouldn't be used to evaluate employees, but if we expect managers to know what's going on, they do need some signal. Metrics are one of those signals. It's the manager's responsibility to layer on other signals to form conclusions.

In other words, just because the metrics themselves aren't sufficient, that doesn't mean we should take them away completely.

Yeah, I feel the discussion around this is usually "random metrics can be gamed and may not reflect true value of a person's contributions". But neither does unmeasurable gut feeling!

If you use done tickets or whatever metric to _determine_ value that's a bad idea.

If you use it to ask questions or confirm impressions it can be useful.

I think the argument is that if a manager is so far removed from the work being done, that they don’t even know who’s doing what, than they’re a figurehead anyway.

They need some signal, and metrics are not one of those signals.

The metrics tell you one thing, but how to interpret it requires you to know what people are actually doing. And if you do know that then you don't need the metrics.

Add to that, I don't think I know anyone that could be trusted to not misinterpret the metrics. It is a great way to reinforce what you believe, you can take your gut feeling and finding a way to see it in the data. But that isn't helpful either.

I think the idea is that if a manager is just like... in the meetings with team members or also just ambiently participating in the work then they'll know what is happening.

I don't need a metrics dashboard to know what's going on with my spouse. Feels pretty normal for a manager to have a decent idea of what's going on with their reports.

> I don't need a metrics dashboard to know what's going on with my spouse.

You'd be surprised.

It's extremely common for both spouses to think they're doing 75% of the housework. Resulting in a lot of resentment.

Then after couples' therapy they agree to actually make a list. And the truth is revealed, and you can actually figure out how to make it balanced.

It's extremely in common in therapy for both partners to insist they know what's going on with their spouse, when the reality is they don't at all, and therapy is about actually seeing the other person's POV. And believe it or not, metrics can help with that -- particularly around time spent and money spent on things that are obligations vs. recreation.

And it's not so different with managers. I've had managers who just simply disliked one report and didn't think they worked hard enough, and just liked another report and always assumed they could trust their output. With no correlation to the employees' actual performance. Metrics help correct our blind spots.

The main issue with code metrics is that they're easy to game, and they're not necessarily an indicator of anything.

In my day job I just made a big change across many microservices updating a core dependency library, so last week it looks like I've done about 50x more work than I have any other week, but that's because I scripted the update, it's not a reflection of the actual work I did at all.

I stopped working on a tool in this space (https://dev.log.xyz) for a variety of reasons, but the idea that you could really only sell it to incompetent teams who wouldn’t be able to benefit from it is one of them. I agree that management cannot and should not be replaced by software, and good management is fundamentally a human-to-human interaction. That said, I’d use devlog myself in the future — sometimes information gathering takes a lot of time that I’d rather spend on actually talking to people rather than clicking through a million github tabs.

In the late aughts, I became lead developer of a team that had never done any sort of version control. Just nightly backups of a shared SMB server.

I wanted to get everyone using git, but getting people to actually bother committing their work was like pulling teeth.

I built a "git leaderboard" showing how many commits each developer had made that week. It didn't really help and it sure didn't make them resent me any less.

Some things need management to run and say "do this, or else". If you don't have that weight behind your words good luck getting any big changes done.

I was ill suited to be manager in hindsight. I am a good developer, I am not great with people. I wanted it because it seemed like the next logical step in career progression but I was not good at managing people.

I am very glad I left. I have spoken on here before about how it gave me stress induced health issues.

Were you a lead or a manager?

Did you take a salary cut?

Both? I was in charge of our codebase as well as managing our developers.

Is that not how it always is? Everywhere I have worked "Lead Developer" has been a management position, such that your team reports to you.

No, it was actually a pretty significant pay increase. I went from a very small company to a larger one.

About the same time, I looked to see if there was any research on the effectiveness of a version control system like git vs. other methods of versioning (like VMS-style numbered versions, or backup/snapshotted file systems with a temporal browser).

I found nothing.

FWIW, "git leaderboard" is trivially gamed. Not only with pointless auto-commits, but some people commit every few lines while others commit only when things are in a good shape. What you ended up doing was introducing the same sort of resentment as factory workers under Taylorism and observations from the time-and-motion man.

Had our schools taught more about the history of labor rights and struggles, and perhaps less of the success of industrial oligarchs, then perhaps you would have been more likely to expect that resentment and not tried it in the first place.

> trivially gamed

Eh, there were no rewards, so no real incentive to win. The idea was just more to get the act of committing their code into their minds. Like "oh hey, everyone can see I'm at zero, maybe I should commit my work".

This was something I tried after months of poking people to commit their work.

I'd put together a whole training on what git is and why we should be using it. It came up every weekly meeting. I was grasping at straws.

Then no real inventive to lose, so no real incentive to switch, so no real incentive to care about a scoreboard, while making those who might test the waters subject to possible public ridicule.

What do you think the advantage is to 1) using a version control system, and 2) using git, in the aughts?

Version control systems have been around since at least the 1970s (dating from SCCS), so 30 years before your experience. My group was using RCS in 1993. Which means the people you were trying to convince almost certainly know about the concept and possibility before you tried to persuade them.

Frequent backups of a shared file system is a form of versioning. VMS-file filenames.txt;001 is a form of versioning. Moving projects into new directories is a form of versioning. None of them require any special training to get started, and the latter two let you use any normal tools to view and compare different versions of the file.

Some places had conventions about who was allowed to modify a file, while the git model is that anyone can modify anything.

Which means there are clear negatives to switching to git, especially for an organization which has been using another means of versioning.

What did you do to minimize those negatives? What did you do to provide transition system so some people could use the old system and others the new? Why start with git, and not something like RCS/CVS which was structurally more aligned with the centralized model they were used to?

> while making those who might test the waters subject to possible public ridicule.

I mean… No? A board basically showing that you're actually doing your job isn't going to get you ridiculed…? If it is, the person ridiculing you obviously is a moron.

> using git, in the aughts

Even in the late aughts, git was the obvious successor. Anyone who had spent any amount of time with it knew it simple and powerful.

We had our core application from which everything was forked in SVN. SVN was always a nightmare. Conflict resolution in SVN was basically just not going to happen. Blow the repo up and start over. SVN was never a usable piece of software.

This was the very first thing I moved to git, and it was a godsend.

We'd tried SVN for some of our other larger projects and it would always end up in some dumb broken state we couldn't get out of. I remember BerkleyDB corruption being like the name of the game.

> Why start with git, and not something like RCS/CVS which was structurally more aligned with the centralized model they were used to?

The way I was trying to get them to use git was basically no different from how they were already doing their work.

The way we worked there was only ever one developer on a project at a time. I basically just `git init && git add .` 'd the existing directories on the SMB share. The developers would continue to work on the existing SMB share as usual and all I was asking was just commit their work _on occasion_. I wasn't asking for branching or PRs or even sensibly structured commits. Let's just have some history to start with. Anything would have been better than the nothing we had going on.

The big incentives for the developers were:

1. Having an actual history of changes.

  - While we had nightly backups, they only went back maybe a month at most. Something fell out of that time range, it's gone forever. Want to see how something worked six months ago? Too bad.
  - Pulling backups was not an automated process. We had to contact our grumpy IT guy who lived in Juneau Alaska and worked Alaskan hours. Depending on when the problem happened, you simply had to wait for him to wake up sometimes. You almost certainly wouldn't contact him just to casually see how something used to work.

I'm more than certain our need for some sort of solution was obvious to everyone who worked there.

2. Having just any sort of history of who changed what, and ideally why.

It really was the wild west. Anyone could open any folder on the smb server and mess with anything. Then that change was liable to end up on production were it not caught in testing. This was a non-stop issue. Who broke X? No idea.

FWIW, most of the collaborative projects I worked on in the 1990s were with CVS not SVN, so I never dealt with the BDB problems which I assuredly had with other BDB-based tools on networked file systems.

> Having an actual history of changes.

Bootstrap by doing regular commits of the shared directory. Make that history visible and readily accessible. Start with it being a one-way directory->repo thing so nothing changes with the existing process.

Set up a cron job or fs watcher to auto-commit at the temporal resolution you want.

Start it as "just a personal tool to avoid bothering Juneau all the time."

> Who broke X? No idea.

Then the problem isn't that people don't want version control, it's they want the anonymity to write crappy code. There is a long history of 'it compiles so it's done' in programming, so you were exposing an existing fault line.

I don't know how 'only ever one developer on a project at a time' works with 'Anyone could open any folder on the smb server and mess with anything', since the latter implies the former is not true.

I have no suggestions about how to change those dynamics from the position you were in. For your "personal tool" also log the current/last-edited file owner? But you'll be guaranteed to be called a snooper if you do that.

OK, I'll bite. I think if you're a technical team lead in a large organization, it is rather your job to point out what's working and what's not working from a technical perspective. If managers could figure this out, they most likely would not end up being people managers after all (insert if those kids could read meme.jpg). Sadly, nowadays even the most large tech companies have enough red tape and bullshit going on (OKRs, alignments, escalations, Q4 plannings, weekly 1:1s with all reports etc) to keep people managers full-time occupied. Most people managers nowadays neither have the chops to understand the work that's taking place on the ground, nor have the time to track it.

So it falls on a tech lead to point out who are the sailors in the ship that are not rowing (or worse paddling backwards). I'm not saying "go build a git commit counter dashboard" but if you're working with dozens of people and it appears someone isn't delivering a lot of work lately, it helps you double check your assumption. (Again, not saying commits are a good metric.)

This blog post is definitely relatable to most of us because we join teams that are somewhat dysfunctional, and if you have the influence capital and the chops to turn that team into a place where hiring is done properly, people have motivated and the right amount of work and the room to grow, I think you can turn the ship around. Or maybe I'm too naïve and have a lot more to learn.

That just means as a tech-lead you end up not only putting blame on the (broken) tech but also blame the people right with it?

I don't think that is a smart thing to do within office politics.

I do agree that you can elevate people with potential, to build something of value with them, but I would stay away of trying to get people fired or replaced.

> If managers could figure this out, they most likely would not end up being people managers after all

If ICs could figure out people management, they would have higher pay, less work, and the ability to blame their reports for all their problems.

If your job is not to manage people then their performance shouldn’t really matter to you. If the company wants you to care about that they should give you actual management duties (and the pay which comes with it).

It’s obviously cheaper to have technical leads be a kind of pseudo managers where you get them to do most of the middle management, their own work and the reporting. This way you can save a lot of money by keeping the financial parts away from the technical leads, which also means you don’t actually have to listen to what they say about performance. Because one of the major truths about management is that a mediocre performer is usually a good keep since they are cheap labour and less likely to leave. Sure you can do stuff like cutting the poorest 10% and I think this is popular in the US, but that usually doesn’t invoke the best productivity because it hurts morale. This way you can also semi-easily replace your pseudo-middle managers because the hardest part of management isn’t the day to day stuff, it’s balancing the spreadsheets and making your own successes look good.

From a top decision maker perspective the separation also makes sense in terms of not having too many responsibilities tied to a management area which is notoriously hard to get talent for. If your tech managers are too technical, or if your technical leads are too invested in management it’s much more expensive when one of them leaves.

The unfortunate side effect is that it often burns technical leads out. Makes them unhappy when they are passed over for promotions or don’t feel they get credit for the work they do. There is no easy solution though because managers tend to change jobs much more often than most other “more expensive to replace” positions. I suspect a lot of technical leads might also find the corporate politicking between middle management and managers or managers very stressful.

I don't really disagree with anything here, except that I think "not my job, not my problem" is at best a sign of unhealthy dysfunction, and not something to aspire to. Well, for most people; probably certain annoying activist meddlers could settle down and focus more on their own areas. And I suppose it can be a rational self-protective mechanism when you're stuck in a really dysfunctional place, as doing too much "not in the exact letter of my job contract" types of work can quickly lead to burnout, but it'd still be better to look for something new... As the thread's current top comment mentions, when you disincentivize things like "Helping a colleague" or "Digging into what looks like a security vulnerability", that's just incredibly corrosive and makes dysfunction even worse. It doesn't matter whether you disincentive such things with bad management dashboards or with encouraging an attitude of "not my official job duties, don't care".

It's not quite a matter of "professionalism", and I very much don't want programming to turn into something that requires a professional engineer stamp like other engineering disciplines, but professionalism might be the best proxy term. I want to work with people who do good work. Even excepting the cases where someone else's bad performance or work actually can directly impact me or the rest of the team's work or reputation, I'd rather work at a place that discourages bad performance. If management appears blind to a particular instance, it may well be worth saying something to try and correct it, even if performance of the system is ultimately their responsibility. Each place is different, maybe saying something will actually improve things, or maybe it just ends up being another one of the hundreds of cuts that eventually make you conclude the place sucks with management not interested in improving it or themselves, and you go elsewhere.

There's a similar notion with introducing better technical practices like version control. Another comment mentioned struggling to get git adoption, but there are plenty of other stories of the opposite, where you do get a team to adopt something without the threat of management forcing it on everyone. Those experiences are great, I'm glad to have had several of them.

For sure, if you're being asked to be "tech lead", you should at least be getting paid as much as any of the direct managers of the team. In the age of "parallel promotion tracks", there's enough truth to that convenient fiction that this shouldn't be too difficult to achieve. (There is the downside of dumb processes like having to perform "at level" for several months to prove you deserve a promotion. You're basically taking a pay cut for that time, so better argue for sufficient compensation increase/bonuses when that promo comes.. and justifiably ragequit if passed over.)

I think we mostly agree. I do think that this part:

> is at best a sign of unhealthy dysfunction, and not something to aspire to.

Should be disclaimed by saying that I’m Danish and we have a different view of workplace authority than people in the USA might.

I don’t know if you’ve worked in a large corporate environment but usually your success depends on others. If you’re a a tech lead, you rely on other individuals to deliver. If the whole project fails, nobody gets their promotions or bonuses anyway. So it’s rather a collective effort to get the teams in a well executing state.

Middle managers do not create value directly. They can only create the conditions for value creation by others. They can do so actively, by understanding their team and making changes, or defensively, by protecting their team from threats.

If they are 100% busy with optics and reporting, the only thing they can possibly be doing is defensive work. At which point the game becomes clear - an organization so addicted to those approaches is actively suspicious of their own employees, trust has broken down, it’s everyone for themselves.

She links to an earlier article, where she determined that some people were "slackers" based on ticket metrics, and then blamed these "slackers" for making people who work incessantly burn out: "Stuff like this is why the people who really cared later burned out."

Assuming the data is correct, the much more likely explanation is that working non-stop for your whole shift is not sustainable over the long term, and that is what makes you burn out.

But the data probably isn't correct. In German, they say "wer misst, misst Mist." I've seen this often enough.

I worked at a major financial supplier whose CEO was super into metrics, and fired hundreds of the "worst performers" every year based on his spreadsheet. Like clockwork, every year, I saw the most valuable people in every team get fired, because those were people who had a deep knowledge of the system, and were often diverted from doing "visible" work by helping less knowledgeable people. They were the ones who trained new hires, who you went to when you couldn't figure out how to debug your problem, who wrote the architecture documentation so people knew how things worked, and so on.

Guess what, none of this stuff showed up in any spreadsheets.

It didn't help that they usually also had worked at the company for longer, and had higher salaries, so firing them "saved" the company more money.

Unsurprisingly, the software product they sell is an absolute mess.

The power of language to lead us down stupid roads is amazing.

"It's the job of a manager to know what their reports are up to ...".

The conceptual framework that is required to read and write this sentence is slave labor. Not collaboration. Inherent in this sentence is the same lack of understanding of how people work that turned the US from being the world's biggest producer of cars to not. The Soviet Union crashed and burned because of this prisoner-guard model of interaction.

Collaboration requires trust and common cause. Prisoner-guard embodies neither of these components.

The need for collaboration is a function of complexity and uncertainty. Or upended, you can only "manage" people for tasks that are certain, known and simple. Which in turn means you can't adapt.

She put it a little strongly (it isn't the only job of a manager) but I don't think it implies everything you're saying.

In a perfectly collaborative team (which can happen in small companies where the goal is very unambiguous), it's still one of the jobs of a manager to know what everyone is doing. Not in an "I suspect you of slacking off" way, but an "I'm making sure we're all coordinated" way.

Do you think a manager shouldn't be aware of what people are doing?

Companies are information processing machines and managers are the data busses that the sub modules communicate through.

Their job is to make sure that the right people know the right things at the right times. Their job isn't to just know what their team is doing, that's a valueless activity on its own.

That is to say, managers need to know things about what's happening all over the place. Their own reports are probably the absolute easiest thing for them to monitor so this focus on it is kind of strange.

The best manager I ever had was someone I had no respect for at first. He was not a tech wizard and at times I suspected he was clueless. (He was not, just focused on his role.

He thought his job was to ensure that his reports knew what OTHER people in the group were doing. And that we, as a group, knew where we were going. The group was astonishingly successful, because WE got things done. Over a period of years.

The silly company hired some very techy guy who decided to do a rewrite with plugins. Wowy Zowy Tech! Over two years that group became larger and larger and never, ever, ever shipped a product. Hmmmm. Then they went under.

It is the WE that is important. This was not an attack on rbb, although I understand how it read like one, and I am sorry for that.

It was however an attempt to point out that even if you drop the only there is no WE in that concept of how people work. Certainly no one argues for a manager not to be aware, but the crucial element is for team members to be aware.

> collaboration requires trust and common cause

Much more fundamentally collaboration requires communication. In a hierarchy, a manager is a fan-in/out point. It is essential that a manager knows what their team members are doing to effectively perform their role.

Trust and common cause are also essential for effective collaboration. However, I’d argue that regardless of whether these are present or not, the statement in question has to be true.

> The power of language to lead us down stupid roads is amazing.

You're taking one part of what the author said and extrapolating it many times further than its original meaning (comparing it to the Soviet Union, really?), ironic.

I wonder whether successful Chinese car companies are currently thriving thanks to their implementation of a collaborative trust and common cause culture?

Or maybe there’s a little more to it…?

There’s this theory that systems often thrive at the expense of its individual parts… I guess this is one of such examples.

I had managers in the past who did not know or care what I was doing. They got nothing done. They didn’t know the product. I remember distinctly that one of my colleagues got mad because our manager proposed a feature that he had implemented a year before and was quite a lot of work. On the other hand, this was the coziest job I ever had. Most of us worked about 1-2 houres a day. For me that was fine, but others really struggled with it.

I did not mean this as a criticism of the author. I understand it reads that way, and apologize. It is an attempt to question the base assumptions inherent in the analysis. As I put in another comment, and as someone else stated, the job of a manager is:

* ensure members of the group know what each other are doing. * ensure members of the team know where the team is going * act as direct report in another team that has another manager that does the same.

Any non-trivial software project will require parallel development. The biggest risk to any non-trivial software project is that when the pieces from parallel development are put together, they will not fit or inter-operate. In my experience.

This is such an on point post.

But I’d add one thing. Peer review is extremely valuable if you use it as a tool for career improvement and not as a tool for performance review.

To do that though you need 2 things, trust between the peers and for it to have no way to impact career progression from the companies perspective.

So when I was a manager I’d have a rule that at 4 times a year my reports would need to do 2 peer reviews with peers of their choice. Preferably over lunch the company paid for. The only thing I wanted to know is if it happened or not.

I got mixed feedback on the method from my reports. I think the ones who saw it as an opportunity to get real unadulterated feedback loved the process, while the rest just got lunch. Which is fine.

extremely valuable if you use it as a tool for self improvement

> "Peer reviews actually improve things" is about the biggest crock of shit that people in tech still believe in.

Hey, it's finally catching on! I stopped writing substantive peer reviews years ago, after I realised folks (including management) were mostly using them to snipe peers for things like caring about infrastructure/security, or just because they were foreigners/women/etc.

I respect the intent behind the article, which as I understand is that managers should work closely with their teams and know first hand how they are adding value, instead of depending on a chart to know that.

However, there are a few problems here:

- There are more manager positions than there are qualified managers. So you will always have people who are simply bad managers. This is generally more true in larger companies where productivity of an individual team is easy to ignore.

- Even good managers are humans and are subject to emotions and biases that they don't even realise they carry around. The only things which bring objectivity is data and good processes.

- Hybrid or remote work is a larger trend that began much before covid, and while back to office mandates might make it seem that the trend is loosing steam, it is not. There will be more remote work in coming years, and that makes understanding your peers' work even more difficult.

So what is the solution? I believe that:

- You should measure events, but you should have the intent that you want to "understand" what is going on, instead of policing people. Data can reveal a lot, like conflicting work patterns, burn-out indicators, problems in communications etc. Not all metrics are bad.

- You should combine objective data with subjective feedback, as well as more context such as life events (marriage, becoming a parent etc) to understand how people work.

- Processes should enhance focus on outcomes, rather than activity. Frameworks such as OKRs are hard to implement correctly, but they do let you focus on business outcomes. The problem with knowledge work is that you cannot measure it with activities alone. Trying to bridge OKRs with activity metrics as well as subjective feedback can be helpful.

For disclosure, I am founder of a platform called Crewnetics, and we are building tools for measuring performance of knowledge workers.

> There are more manager positions than there are qualified managers.

So? Let companies fail, let the world rot. If people want to live indoors they need to learn how to be good at something.

> Even good managers are humans and are subject to emotions and biases that they don't even realise they carry around.

Data doesn't solve this it codifies it. Tracking commits is PERMANENTLY codifying a commit frequency bias to work performance.

> There will be more remote work in coming years, and that makes understanding your peers' work even more difficult.

How? Did managers only understand what was going on by looking over peoples shoulders? What data did they get by people sitting near them? Looking busy and getting stuff done are two things that look the same from the outside.

I read her other post from 2004 and i can't help but think you're throwing the entire thing out, baby and the bathwater and all.

I don't think you should make the metrics the end all be all (Goodhart's law), but that graph is certainly helpful if you can figure out who might be doing literally NOTHING for hours on end vs. someone who is productive at some level. All trying to "figure it out" at that point as a manager is just trying to cut through someone's bullshit when the data is right there.

Maybe it's more like 90% of the cases those metrics shouldn't be used to measure anything, but they can certainly point out "smoke" where there might be someone struggling and then you can be an actual manager and figure it out case by case.

Yea because churning out or changing code is the only imaginable productive thing a software engineer can do ? what about planning, helping others out, researching all this stuff is super difficult to measure. It all depends on the work, the team and the size of the company i guess.

I totally agree with you, but there've been employees I've managed in the past who loved to go off and get distracted with anything they judged "useful", often at the expense of their actual work. That's something to be managed rather than measured by metrics.

did i say that? that's why i said it's an indicator, one of many. if you are producing zero code vs your peers and your job is to program it doesn't mean you are unproductive, but at least someone can talk to you about it and clarify vs. just guessing with zero data.

This punishes the good people, putting them under scrutiny.

Should these tools check up on management too? Maybe sneak in some false direct-report metrics to see if they notice?

Make it game of thrones all the way down to game of peons. :)

i don't understand how this is punishing the good people... i think everyone here has some ptsd with terrible managers or others micromanaging their work. data a good way to look back and ask the questions that might need to be asked, but to not use the data as the final criteria for anything (which is where i think most lazy managers end up).

do companies plan their strategy with zero data? i find it hilarious we devs somehow think we are a special group that can't be measured at all, so just don't bother and let us be. at the same time we don't want managers up in our business all the time either. just because the measurement isn't perfect doesn't mean to not measure at all.

> i don't understand how this is punishing the good people

This is putting the trustworthy people under personalized surveillance/scrutiny.

I just don't think working with someone looking over your shoulder to be that healthy, and might be counter-productive (maybe literally).

i mean i don't considere issues closed or tickets open to be "looking over my shoulder", but i guess we disagree there. these are some metrics that need to be looked at at some point to determine some strategy about the future or reflect on the past.

"trust" to me is knowing that everyone that has access to these metrics are making decisions in good faith. it's knowing that your boss isn't sitting there watching it every hour or using it as some simple metric to axe you. blame the people not the tools.

There are a few exceptions to this, with varying degrees of justification:

1. An underperforming teammate when your personal rating is tied to team metrics. Which is a shit way to run a team.

2. You are a tech lead in a company where the career and level expectations are that you will assist in performance managing ICs on the team. Which is being a manager in all but name.

3. You truly care about the personal performance of these "slackers", which is a good sign that you want to be on the management track, but probably shouldn't be.

4. You have some strong external incentive like slackers directly impacting the values of your shares (and you own enough for it to make a difference)

5. You are a petty asshole.

I will never cease to be amazed how many people will fall into number 5 - but will insist they are doing it for other reasons.

Whatever happened to

0. Working with incompetent people that can’t deliver will make you miserable

or the strongly correlated

-1. If you are not learning, you are regressing

Sorry, there are many many reasons to want to work with excellent, strong coworkers.

Or even just:

1/√2 + i/√2. We are all on the same boat and I have to pick up your slack if you don't work.

I think the issue is that while it’s true that the manager shoud know if they are generally effective or not, employees should also have a decent understanding of what the goals and objectives are of the organization.

I feel that there should be an alignment on what the expectations are and how people are graded and these tools should be applied before the evaluation and information should be provided to employess on how they are doing on a regular basis.

I would say that if a manager sucks, it might not be the employees total fault, because they haven’t clearly delineated expectations to the employees.

To just apply analysis retrospectively makes no sense and it should be applied regularly, so that people know where they are and can improve.

I’ve definitely worked at organizations that are totally unorganized and it’s totally unclear what the objectives are and they will just call you up and give you different objectives every day and then the performance review addresses totally different objectives from what we’ve been actually doing the entire period.

> It's the job of a manager to know what their reports are up to, and whether they're doing a good job of it, and are generally effective.

I don't think this is mutually exclusive with building tools that gives a bird's eye view of what various employees are doing. In fact, that sounds like a helpful tool. The ONLY tool? No, of course not. And a healthy dose of interpretation is required - in the same way that an engineer must look at a datadog dashboard and apply the necessary context to interpret anything useful from it. Some level of human interaction and empathy is required to be a manager. But if I can "know what my reports are up to" at a glance rather than interrupting them to ask...seems like a win win.

I will stop complaining about executives measuring my performance with objectives and metrics they define, if I can define my own metrics and objectives for them and measure executive performance, complete with PIPs, layoffs and forced attrition for the lowest 10% of performers. What’s good for the goose is good for the gander.

I will be happy to sit in an office with my VP and HR and explain to them that we have to let them go due to not performing up to $COMPANY standards, but we wish them well and here is 2 months salary and a copy of your NDA and non-compete; can I have your badge please?

Normally Rachel writes well and I am a big fan. In this article, I have a hard time understanding what she is trying to say.

I agree with the general sentiment that metrics are not a panacea. Managers need to put in work to do their job, instead of leaning blindly on tools like metrics. IC's need to do their work instead of expecting managers to prop them up.

I'm guessing that this is what the article is trying to convey. What I read though is a complete 180 flip into "no tools are helpful", and "don' help anyone" territory. I don't agree with that.

I didn’t read it as “don’t help anyone”, I read it as “don’t help managers”. As someone who’s worked both sides I agree, not least because I very efficiency tool I’ve ever been exposed to was bullshit. To me most of these things, including peer reviews and retrospectives and whatever else the pseudo jobbers and consultants have peddled for two decades now don’t work. Then again most organisations could probably get by with half their current middle management staff if we removed all these metrics and audits and actually let them manage. We won’t do that of course.

Somewhat hilariously I was a manager during Covid, and as such I saw the metrics which showed that every worker group in the city I was working for was happier and more productive. Except for middle managers and the various positions they are in meetings all day. Interestingly productivity was way up despite people spending significantly less time at their computers.

> Somewhat hilariously I was a manager during Covid, and as such I saw the metrics which showed that every worker group in the city I was working for was happier and more productive.

I'm curious how productivity was measured for that. I assume happiness was self-assessed, but I'm also surprised that'd be up given how much of a rollercoaster a time that was just in general.

I guess it ought also be pointed out that these days *a lot* of jobs in general are harmful because increasing economic growth, accelerating in the process the destruction of the biosphere and depletion of natural resources (both of which became a concern half a century ago at least).

Yet of course it's extremely hard to make people understand that, when these are things that they, their families, and even their communities or their polities have been doing for generations, and are directly relevant to their short term livelihood (which they see as medium or even long-term livelihood, as "short term" here means decades).

> “don’t help managers”

Managers are people too, despite of what Dilbert will have you believe. They need help, support, and tools.

It's true that many tools and frameworks are sold as magic pills that solve all the problems. Metrics are one of those tools that are often misrepresented. I think that many of the tools are helpful, if used skillfully.

You can't manage what you can't see. You see your team through your direct interactions with them. You see what they do through the artifacts that they produce. You learn about them from others - hear-say, praise, complaints, and gossip. You also get another perspective through various metrics. You need to combine multiple ways of seeing a team to have a more-complete picture. Take any of them away, and you're a little more blind.

I remember when I first transitioned into the manager role. There was so much that I needed to learn. Some of the tools gave me insight into what is happening on the team that I really don't get to observe directly. However, none of the tools did my job for me. I learned by reading, using new tools, and experimenting. Over time I honed my ability to be able to understand what my team is doing well, and where it needs help. If someone took away ALL the metrics-based tools, I would have fewer ways of evaluating my team.

Managers need as much help as anyone else to do their job. This also involved introducing new tools, and teaching managers how to use them. In a large part, that is their manager's job. Sometimes they call me to help.

"Tell me how you measure me, I will tell you how I behave." Eli Goldratt

"When a measure becomes a target, it ceases to be a good measure." Goodhart's Law

"Eli, one unauthenticated metric is sent to https://metrics.corphq.yoyodyne.com/counterincrement in json format {"empid":"<employeeid>","workunit":"1"}, each time you complete a work unit."

Corporations are meant to be well oiled machines that extract money from the sands of humanity. The harkonnen's harvester from Dune would be a good analogy. This machine is meant to be soulless, blindly doing the will of its owner. Today, corporations have to be made of employees, who have their own will, and their will is often not aligned with the will of the owner. It's as if the harkonnens would have to hire freemen to do work that would harm their own people. From the owner's perspective, those employees are defective mechanisms that must be fixed, and the owner creates a control framework that fixes them. That's what metrics do: they reduce employees to small parts of the machine, with well defined functions, inputs, outputs and measurable qualities. This is what makes modern corporations smell so off. One day in their careers, managers realise that they have to make a choice: side with the employees or fuse themselves with the machine.

I an not sure these fairly one dimensional views are useful. Completely agree with the premises that it is the managers job to know what their people are doing. I have also worked at companies where the managers weren't doing their job. I can also completely see how an overfocus on metrics kills an otherwise good company.

I don't agree with the conclusion though: metrics are bad.

In software, in theory, you don't need metrics. You just write good code that does what it needs to do. Add tests to prove it, you are good. In reality though everyone agrees that metrics are a good thing to have. Why do we need them? Complexity and sometimes we just make mistakes. We could write software that is very close to bug free, but then we move at aerospace speed. Not always optimal.

Software metrics come with all the pitfalls of management metrics like over focus on metrics and not seeing the forest for the trees. Yet we still find the metrics useful.

Managers face many of the same problems, so they ask for metrics. I don't think that is bad. Being bad at using metrics is bad.

Blog post is about someone approaching author on "individual employee productivity tooling".

So it is not "all metrics are bad", it is "individual employee productivity tracking is bad".

On team level and across teams having trends and looking at trends before and after some change is helpful and can be done only when you have metrics of course.

> "Peer reviews actually improve things" is about the biggest crock of shit that people in tech still believe in

Peer reviews are what allowed me to break out of imposter syndrome. Realizing that people valued my knowledge, contributions, and demeanor while still acknowledging areas in which to grow was instrumental in me breaking out and realizing I was bringing value

I certainly sympathize with the underlying sentiment, but this post seems to boil down to "managers should be better!" which... yes, definitely. But how?

If you're not going to to use metrics (agree that we are very limited by what can be measured), and not supposed use peer reviews (agree that they can be rife with bias), the only way to reasonably expect the median manager to know the ins and outs of everyone they manage is to have a small ratio of managers to team members. But that means more layers, and people hate that too!

Also let us not forget that the alternative presented ("It's the job of a manager to know what their reports are up to, and whether they're doing a good job of it, and are generally effective.") boils down to "does your manager think you're good" which is it's own giant can of worms.

"does your manager think you're good" which is it's own giant can of worms."

I have bad news. Unfortunately if your manager does not think you're good, literally nothing else you're going to do will matter, no matter what metrics say in either direction. If your manager does not think you're good, you should leave immediately unless you have some trump card in the form of a higher-up manager who does think you're good. It's the only exception (and barely an exception at that).

So, short of that universal caveat, what system is better? I've said this and I'll say it again: EMs should have unilateral power over their reports performance designations. They already basically do, and the delta wherein they don't is by far abused for evil more than it is for good. So just close the gap.

>"managers should be better!" which... yes, definitely. But how?

You fire the bad managers.

Well, the next question would be how do you find out if the managers are bad? One has to talk to peers, subordinates and superiors and do anonymous feedback, in addition to random checks. All that has to be done by the upper management. If the upper management is not doing it it can only mean either of these 2 things: 1)They are not interested 2) They are too incompetent to do it.

> One has to talk to peers, subordinates and superiors and do anonymous feedback, in addition to random checks

But the article claims you can't trust peer reviews, and that managers should just "know" what their reports (in this case line managers) are up to / how good they are...

It's combination of several things, one of them is _talking_ to peers, not some written account ( peer review? ) of what the peers say. This is has to be done by upper management only.

If you ran a company that you founded how would you judge a manager? You don't just sit on your ass and hope that someone will tell you about the new manager that was hired. You actively seek information, you grill people, you hold the them high standard of integrity.

Also worth repeating: If the upper management is not doing it it can only mean either of these 2 things: 1)They are not interested 2) They are too incompetent to do it.

My point is literally everything you suggested "upper" management do to evaluate managers are things the article suggests doesn't work when it comes to evaluating individual contributors.

> It's the job of a manager to know what their reports are up to, and whether they're doing a good job of it, and are generally effective.

Is it wrong to use tools for doing your job? Metrics can be a part of knowing what your reports are up to and how effective they're being.

Over the years I was wondering why management is often so bad to begin with. There are terms like "stupid" that are often used -- I certainly did and still do -- but more often than not the people in question are not really stupid. What I came to realize seems obvious in hindsight: They lack the education to do their jobs right. Question really is, if there is any education that even builds the right foundations for that. If I look at something like [1] I get a chill down my spine, in return I managed to finish my buzzword bingo card (again).

[1]: https://www.wgu.edu/online-business-degrees/management-leade...

Worst manager I had was a software engineer with 8 years of experience as engineer and 2 years of experience as manager. Knew enough about software engineering and so he was involved in almost every technical decision. Knew little about management.

It is a natural desire for upper management to want to know if the people in the company are working hard and effectively.

But that is the job of middle management to know. And if upper management cannot trust middle management to give them honest and good feedback on this, then they have the option to hire and manage better middle management.

> Why? It's surprisingly simple. It's the job of a manager to know what their reports are up to, and whether they're doing a good job of it, and are generally effective. If they can't do that, then they themselves are ineffective, and that is the sort of thing that is the responsibility of THEIR manager, and so on up the line.

One could make the argument that if you need to measure what your employees are doing, your business processes suck or you have the wrong employees. I feel like in a functional business, people will know who is and isn’t getting stuff of value done.

You can't tie employee metrics to comp because of Goodhart's Law. But it can be useful to identify who's in trouble. Metrics exist as a technique of information compression that is valuable because as you go from the farmer inspecting a specific plant to an industrial farmer managing acres of plants you lose sight of the individual plants. That's not because you don't care about the plant. You do. You just also have to care about the other plants. But your scarce resource is attention and time.

If you use the metrics to optimize your systems good for you. If you use it as a punitive/remunerative system, the org will optimize against your metrics.

I agree with this. If commits from a dev suddenly die off, it's worth investigating. But it's still not a metric worth dashboarding.

I have no faith in managers to try to understand or correctly apply any metric. I collected metrics this year that showed I did a lot for the team/company. I still got a shit review because my TL gave me bad feedback. I asked why the feedback was taking precedent over the data. They said that just how it works. The company previously agreed to extra coaching as an ADA accommodation and failed to provide that for 4-5 months out of the year. They refuse to listen to reason, so maybe it's lawyer time.

While there are obvious flaws with metrics as Rachel mentioned, there are equally bad flaws with leaving things to manager. Lot/most of middle managers are dysfunctional and don't at all work or care to provide the best review possible from their side. Should the team suffer because of this?

Aside, I think consistency is at least somewhat a good metric unless totally gamed. Not the number of PR merged or anything, but metric for coding activity time each day with a very low ceiling for completion, say 1 hours a day.

I like this new punk Rachel much more.

> Once again, if management is too stupid to notice what's going on, they deserve every single thing that will happen when it finally "hits the fan". Make them do their own damn jobs. You have enough stuff to do as it is.

Management isn't stupid, it's just a symptom of large companies.

- Yes, peer reviews don't work.

- Yes, peer reviews push the manager's job onto ICs.

- No, it's not the manager's fault. Take that manager and put them in a small company and they'll know their team without peer reviews.

This post is absurd.

Just because people starting measure the wrong stuff, number of PRs, number of lines of code, check in counts, etc, doesn't automatically conclude that the act of measuring is superfluous.

If the act of measuring is the responsibility of someone higher up, who is even higher? Is it manager all the way up? Do we, for instance, conclude that the CEO is ultimately responsible, and every not CEO relinquish the responsibility of knowing any measurement of performance?

Aren't we all CEO of our own life?

In this model of "managers know what their reports are doing" how does one gain insight into overall engineering health from a high enough level (say, engineering manager / CTO)

How does a engineering manager know what their managers are up to in order to get an understanding of what their manager's team members are up to? Even worse if you have a large enough organisation where you may have managers managing leads who manage teams?

Mayhaps the CTO would deign to do their work and ask their direct reports about the status, then compile a report with the desired information? The direct reports would obviously ask their reports, and so forth, until you get to the lowest rung on the ladder.

The only metric that matters is - "is anything getting done". And this is why Scrum exists. Engineers hate scrum because it knocks us out of the zone in the morning, as it's yet another meeting to pop into.

But Scrum is not there for us, it's for the managers to know "what up". It's the visibility overhead SPECIFICALLY for this. I don't know why we have to invent other things on top of it.

There was a time I was running a 10+ team and was executing scrum by the book, not really understanding much of it at start. Meetings felt weird and generally it was very intense time. But after some time a few things clicked in my head: I could plan with some certainty without bothering people, and execution was falling between min/max planned capacity, everyone was aware of pretty much everything, even in 'other places' where they were not actively contributing, everyone learned to estimate their work based on complexity. And above all, after leaving the place and working in a few different shops, when I look at the code quality produced in that place I'm still impressed (not brownnosing myself, really). We executed ~50 2-weekly sprints, I miss that time.

The irony of course being that the official scrum guide, however much weight you out on that, says that managers and PMs only attend standups if they actively contribute to the sprint. I have found daily standups that are mainly for the managers benefit incredibly annoying and unproductive. Maybe in teams with more junior people that don't speak up/actively reach out it makes sense but in my current team we talk all day on slack/meet. It makes much more sense to give the manager a weekly report on how the projects are progressing instead. This is much more outcome focused instead of trying to keep the manager abreast of every small step of solving a ticket.

> it's for the managers to know "what up"

If a manager wastes 30 minutes of their teams time every day because they can't figure out 'what up' from their task management software or quick 1-on-1 meetings, I can confidently assert they're a shit manager.

>> So, my new position on that sort of thing is: fuck them. Don't help them. Don't write tools like that, don't run tests to see if your teammates will take care of basic "service hygiene" issues, and definitely don't say anything substantive in a performance review. None of it will "move the needle" in the way you think it will, and it will only make life worse for you overall. "Peer reviews actually improve things" is about the biggest crock of shit that people in tech still believe in.

I know this is coming from a good place and good heart. However, even in 500 people organization this does not work. Peer reviews, championed by FAANGM and now adopted by everyone, are here to stay. If you don't do the work then someone else is ready to do that and take credit.

Also, god forbid if you sit in Amazon style performance evaluation. Only way to survive is you know someone. I have seen too many things at these evaluations. One quarter someone is HV+ or TT and in six months they are on PIP because manager changed their mind or Sr. Manager or Director asked them to.

Pro tip: Don't work at shit orgs at Amazon (FinTech, Prime Video) and don't work for terrible employers. You won't believe how much fewer stuff we need to get by. I used to think one need 200k+ to survive in west coast VHCOL (Bay Area, Seattle). However, I am surprised how far even 60k gets you with a family of four and one of the spouse staying at home.

Author is mostly right in spirit and I wholeheartedly agree. I just don't see a way for employees escaping peer review culture.

> However, I am surprised how far even 60k gets you with a family of four and one of the spouse staying at home.

This has to be a joke, right? 60k income for a single income family of four? In the Bay Area or Seattle?

I am not joking. I don't know why do you say that. Granted, not everyone is equipped to pull it off but trust me $60-$80k are good if you manage your expenses well. Here is the breaddown:

Rent: $2400 (East South of Seattle, quiet and safe area 3B2Ba SFH)

Groceries: $800 per month

Kids school: $200 per month (public school)

Kids activities: $200 (for 4-6 months). We play at home.

Electricity, Gas, Sewer - $400 per month

Gas: $100 per month (I mostly do WFH)

Emergency: $300 per month

Fun: $100 month

Healthcare: $1200 per month (through marketplace)

Childcare: None since one of the spouse stays at home.

We could lower it if we moved to an apartment but we love the place. We live happily and I get to see kids everyday rather than leaving them with strangers with cookie cutter upbringing. You can't outsourced parenting when you decide to have kids. But, most people never grow up. They want to party every weekend. They can't keep up with jonasses. We are different. This is how my family built the wealth. I will follow their teachings and path and will build my own destiny.

It is manageable with $60k to $80k. Granted, we are not contributing to retirement but this won't be forever situation.

Somehow, people have build expectation that you need $150k - $200k to live descently. It is utmost corporate and media brainwashing one could imagine.

Employee metrics is just a tool, as with any tool's metrics can be used for good or for purposely evil. So, it is how you use it to improve that matters- In a workplace everyone has a responsibility to support and make a good work environment and to ensure what you are doing is profitable, ethical, sensible.

HN death hug in effect.

https://archive.is/pYG8C

If you're at the point that you need 360 reviews (mind you that many companies do them but don't need them), because you don't trust middle management to not play politics for themselves, then your company culture is already rotten and will not get fixed by doing 360 reviews.

I agree with the premise that numbers aren't a replacement for actually knowing what's going on, I think there's a false equivalency the author has that if you're a manager wanting metrics on your people that it's because you don't know what's happening.

Metrics are like supporting arguments for a whatever narrative a manager is telling. I've used employee metrics to help support the case for promotion or supporting my case to HR for why they should be fired (I've never fired someone because of metrics). It reinforces observation. The time metrics get toxic is when a manager starts telling ICs their performance is their metrics. A whole host of bad things happen then.

And if you're telling me bad managers will suddenly become good managers if you take away their employee metrics, you've got a surprise coming.

Are there any tools to measure the performance of managers?

Wait so this person used to say people should be measured on output using tools, and people listened to them then? Why is anyone still listening?

Collary, only lazy and ineffective managers need employee productivity metrics. A good manager wouldn't even trust those metrics.

It hurts me that my coworkers literally do nothing. Managers need a metric, which one, its a secret ;-)

Hope you are doing ok, Rachel. I know you’ve been doing this a while, and likely don’t need my advice, but if any of what you’re writing is about current personal experience then maybe it’s time to GTFO. The mistake I’ve repeatedly made is not getting the fuck out at the first sign of this kind of trouble.

Can anyone steelman the case for employee metrics and if so what are the best ones?

idk if this is steel, but I think the basic counterpoint is that humans are biased. No matter what, you are going to be compared against your co-workers sometimes (think layoffs or raises). Say your manager has 10% of budget to allocate to raises. How do they allocate? What is fair? OP seems to advocate for the manager to just know who is high impact and be fair. But even if the manager is good and their team is happy and productive, there's probably not consensus on what this should look like. So it's attractive to codify this process and try to remove human bias.

The straw man is usually that employee metrics should be used as the primary factor in performance reviews. Well, I guess it's hard to call it a straw man because some companies, allegedly, really do operate like that.

The steel man argument would be that employee metrics can provide a couple data points that a manager doesn't take action on by themselves, but can help a manager know where to look. Metrics can flag unusual situations. Sometimes there's a great explanation behind employee X making 80% fewer commits than the average employee. Like less rework, making more impactful changes, or simply bundling more changes together. Other times, it can be a sign that someone is having trouble onboarding or simply not performing at the necessary level. When you see that a metric is different than what you expect, it's your responsibility as a manager to figure out why.

> I know that if you go back far enough in these posts of mine, you will find some real crap in there. Sometimes that's because I had a position on something that turned out to not be very useful, or in some cases, actively harmful. This sucks, but that's life: you encounter new information and you are given the opportunity to change your mind, and then sometimes you actually do exactly that.

followed by

> So, my new position on that sort of thing is: fuck them

I always found rachel's articles (is she called rachel? Idk) way too opinionated. It doesn't get better with experience apparently.

I mean, don't "fuck them"... Maybe, just maybe, there's some tool out there in the blue void of ideas, that could potentially help managers UNDERSTAND what's going on.

I, for instance. As an individual contributor, I will accept everything that is thrown at me. Yet, there are specific tasks I totally suck at, and I will slack a lot to avoid doing them. I don't like going to my manager and tell them: "I actually suck at this, and if you give this task that sounds relatively easy to anyone else, I will slack the shit past the deadline for sure." So if there was a may that my manager could learn this by himself. That would certainly help everyone on the team.

I am not very proud of that particular aspect of my psychology, but you know, that's the way it is. I'm highly capable in other aspects, so I don't think my employment is questionable in any way. There is just this specific psychological thing that maybe a tool could help fixing.

I like that Rachel has clearly expressed opinions.

What I love is that Rachel is aware of them, revisits, and explains why a new opinion has been formed.

being able to say "I was wrong, because" followed by "here is my new opinion based on what I have learnt" is much more valuable than opinion disguised as fact.

Knowing _why_ an opinion has changes is often very valuable.

> Maybe, just maybe, there's some tool out there in the blue void of ideas, that could potentially help managers UNDERSTAND what's going on.

Maybe, but what the article points out is that slapping a metric on something and saying "this is performance" leaves you with a massive quantisation error. If you have a simplistic metric, then people will optimise for it, often simplistically.

The other thing the article points out is that "peer feedback" is often not a useful way to help people. If you were to put your point about those specific tasks in your own feedback, or someone wrote it about you, it would form an indelible mark on your record. Because it'll probably be the only tangible and actionable bit of information, you manager will overindex on that.

I agree. It is always commendable to face the realisation that our previously held actions or opinions are limited. Even more so to do so publicly with the hope the experience can help someone else.

On the other hand, we are told that these previous actions were actively harmful. Perhaps given this some degree of apology to those that might have been impacted would be in order.

The final sentence of the article is quite illuminating. I wonder whether that would have changed were the metrics useful in identifying relative work performance.

It's a courageous and commendable article either way.

Rhis hits a spot for me that I call "millionaire problems": The owners of the company are millionaires. They're just as smart as the workers, and vastly more well-resourced. You, as an employee, shouldn't cry for their challenges or break your back helping take on their burdens. Their job is "managing", their job is dealing with unions, fundraising, assessing productivity etc. - so step aside and let them do their job. You focus on doing yours.

A bunch of very different things conflated from perf reviews to tools for counting commits (i guess?).

Tools: sure, some metrics are either misleading or gameable to the point of being useless. But you'd imagine some tools might be actually useful for a manager? Then the perf reviews. Obviously everyone hates them. I hate them. But how do you keep large orgs of thousands of people with varying motives, moods and ability from descending into chaos?

Managers don't spike on technical problems of unpredictable depth and don't do code reviews. (I've seen wishful thinking that they did, but in practice, they don't). How can they tell if someone is genuinely stuck on a harder-than-expected problem or is simply full of shit? Verbally ask around for opinions from ICs closer to the subject matter? But that's the same or worse as an informal 360, or a perf review.

fwiw i'm currently and thankfully not a manager but i kinda see why they do what they do.

The best managers never speak or think about KPIs.

I agree with the manager-knows mentality for people management evaluations of productivity focused on bonuses & firing... they should know! ...

... but disagree from the high-performing engineering org notion of individual & team productivity. It's hard to improve technical processes when you can't see them. Is some person a 10X'er because they write shit code that other people have to refactor & fix, rely on other people to take their code to production, and don't do their share of code reviews? Is the team slowing down because PRs and deploys are slow, testing is manual, and everyone is used to it? Are calendars too packed or fragmented? Etc.

Any individual item can seem ok, but a lot easier when you can see the issues, reflect as a team, & see how chiseling away works/doesn't.

Engineering manager here...

I understand the sentiment around that managers should do a better job and many metrics based tools miss out on people performing necessary tasks that won't show up in the metrics. The people I have managed who fit those criteria were very obvious and it was known their code delivery was suffering because they were helping others. The good players always stood out.

The areas where I had wished we had comprehensive people metrics were frequently for remote employees on drastically different time zones where daily regular interaction was difficult or where there was some clear under-performance but the WHY was unclear.

It can be very tricky being a manager and to getting to the bottom of WHY someone isn't performing. Should a PIP be necessary, it's very important to identify specific behaviors that need improvement.

During 1:1s, under-performing employees will provide the most vague explanations, copious excuses, blame other factors. Even when I've cross checked with their peers, no one wanted to really give any clear answers as to why something was late, had abnormal amount of issues, or development was standing still altogether. People were clearly avoiding the questions.

Everyone here seems to assume direct reports are always honest, open and transparent. They are not, and especially when things are not going well.

Manager need a way to verify what they are hearing. Do the metrics support the claims, or is someone who's slacking just BSing you. It's not where you get your primary information on performance, it's what you use to verify your own suspicions or find supporting evidence.

For example, an employee who has a history of not testing their code and has in their development plan to improve on that. During 1:1s, the question comes up and invariably, every time I've been positively assured they are making great progress and everything is being tested.

I now have 3 options: 1. perform my own review of their code to verify their claim 2. get a high level metric that testing has improved 3. trust what they are saying, move on and throw the dice that everything will be fine

Option 1 is obviously the best but very micro-managerial and will clearly demonstrate I don't trust their word, further demotivating the individual

Option 2 would be a good place to start unless employee gives me further reason to go with option 1

Option 3 is what shitty managers do

Oh my, they did that kind of performance work at the cultiest of cults, Rackspace?

Their temperature makes so much more sense now. I encountered that place, crash course in gaslighting. Thanks for probably getting me laid off

I read the article and frankly I'm not sure what she means by it.

I have a bunch of thoughts on those in general. I agree, a good manager should know who is doing what and if not, why. It could be laziness, it could be that the rest of the team is completely insufferable and they are only doing the bare minimum until they find a better job(I've been guilty of that one) or 20 other factors, who knows.

But all the associated tooling that has been created over the years for figuring out who is doing what are insanely counter-productive. Assume you work in a large corporation and you are tasked with "implement and deploy X". Fine. But in order to deploy it, you need to rope in a dev ops, sec ops, 3 other people to sign it off and 10 other tickets being tossed around between a dozen people which are nearly impossible to track. All while your manager is sitting there, looking at this one ticket assigned to you and be like "tf?"

So no only do you have to effectively manage a process involving 10 people but you also need to find a way to show that you are in fact trying your best to make progress. Keep in mind that everyone else working on your problem are also involved in 4 other things in each given time.

For a manager to be able to work through that, they must be ready to put the needs and comfort of the people they manage before their own and be ready to make some internal enemies in the process. So far I've had two such manager in my whole life and it was a genuine pleasure to work with both of them - everyone was doing the absolute best they could 100% of the time. In both instances, we had 0 tools to monitor who is doing what - the only tool we used was gitlab with merge requests, even if the company enforced Jira. What the managers did was manage Jira on their own completely and not bother developers at all with it. As a tech lead, I did not even know where to access Jira. And when we got asked how come we get everything done a month and a half before anyone else, the simple answer was "f-bureaucracy". Even when it came to dev ops and stuff, we had become friends with some of them and had an internal rule: "Before sending an email, send me a message in the chat so I know what's needed and I can prepare myself, send us an email and send me the ticket id you get. We love working with you cause you come with clear instructions and no bs". This is an exact quote from a devops in Ukraine who had around 150 words in his English vocabulary. And whether it was a kubernetes cluster, network configuration, upgrades, downgrades, backups or anything else, the most we've ever had to wait was less than an hour. You don't need Jira to know when someone is slacking, whether you are a manager or someone else - you can't hide that and we've had such people on those teams, it's up to the manager to address those.

This is of course large corporations. In smaller ones, it's less straightforward and even more in the hands of the managers. The first question you need to answer is whether those companies aspire to be large corporations while having 50 employees(in total, I don't mean in the tech departments). If that is the case, then it's the same as what I described above and if you pull she short straw(the way I did at my old job), end up with an absolutely insufferable, egocentric team and a manager who's policy was "don't start conflicts, no matter what, sweep any confrontation under the rug as fast as possible".

The second type is the Jira(and jira-like) obsessed managers in small companies where acting as a developer, dev ops, infosec, network admin and hardware admin are the same thing for everyone involved. This is fine to my mind, but we get back to "implement and deploy X". Do you want me to log every action I do, while doing a ton of R&D, setting up a redis cluster, kafka and 3 other things or should I focus on getting it done asap because those things are mutually exclusive.

And the last type, which appears to be my current job - "0 nonsense", "nothing will ever be perfect", "we know we are fixing our car while driving it" are all 100% acknowledged by everyone, management included. A small board with what is needed, "whenever you have time, figure it out". It may sound bad, but it works astonishingly well.

Sometimes the content is decent. But this post, and this line, hits me as very tone deaf. It’s like no deeper reflection occurred.

Argument from "fuck you, I got mine", basically. Notice that the article doesn't claim the tools don't "work", merely that if they work it's because some layer of management is incompetent (maybe sufficient, but not necessary), and if so the company deserves to fail (what?).

It's actually even stronger than that: in the very last paragraph, the concern is that you'll uncover slackers and make enemies.

I really don't think you can measure output and understand value for anyone but the most junior of engineers who basically need to churn out code to be valuable in the short term (and that's for those who do not have a questioning mindset to understand why they need to build what they are asked to). 6 months in and it becomes useless even for them as they acquire domain knowledge.

I don't share that view.

To me the article reads that simplistic metrics do no accurately assess performance of employees.

Managers need to work out what their reports are working on, and base an opinion on performance using more than just "number of tasks closed" etc.

by creating these simplistic metrics, it means that the management chain has a false sense of what make the company tick. That confidence is the rot, not the poor performers. Simply because they do not actually know who the poor performers are.

Software engineers are constantly investing their expertise into the product.

Measurement (if any) should be on the realised gains in the short and long term, not the visible investment. LOC, tickets closed, hours spent etc can all have negative payoffs.

Unfortunately that is hard to measure, as Rachel points out.

This misses "negating realized losses", which I believe is a very important area for engineers to perform in.

Perhaps I am wrong.

I guess my point was that the value of a days work is realised later, over months or years, rather than on the day.

So indeed, corrective and maintenance work have payoffs.

This would also be true of managers - their work should pay off over time, so measuring it in "meetings attended" is not a good metric.

Reply on news.ycombinator.com