>> [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.
> 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.
> 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.
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.
>> 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.
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.
* 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.
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.
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.
* 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.
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.
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.
> 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.
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.
> 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.
> 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.
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.
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.
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.
> 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.
> 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.
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.
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.
> 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.
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."
* 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.
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.
>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.
> 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.
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.
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.
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.
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.
> 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.
> 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. :)
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.
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.
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.
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."
> 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.
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'"
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.
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.
> 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.)
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.
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.
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?
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.
>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.
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.
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.
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.
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.
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 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.
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.
> 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.
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.
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?
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.
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.
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.
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.
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.
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.
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...
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.
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