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.
>> [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.
> 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.
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.
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."
* 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.
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.
> 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. :)
> 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.
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.
> 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?
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.
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.
> 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.
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.
> 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.
> 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.
> 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.
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.
>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.
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.
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.
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.
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.
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.
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’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.
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.
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.
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.
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 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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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 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 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.
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.
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.
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.
> 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.
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.
> 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.)
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)
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.
>> 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.
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.
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.
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 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.
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 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.
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.
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.
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.
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?
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.
406 comments
[ 2.5 ms ] story [ 303 ms ] threadAgreed 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
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.
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.
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.
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.
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.
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).
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.
As well as regularly rotating managers, like the military does (e.g. 3 year reassignment).
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?
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.
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"
* 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.
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.
'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.
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.
My response was meant to be interpreted as doing something other than appeasement, which includes "fighting the battles you can win."
But changing jobs doesn't happen immediately, and "somewhere better" may be very hard to find.
What happens next is this manager gets a low performance rating themselves, for making decisions not backed by metrics. So next year they conform.
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.
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.
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.
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.
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.).
It used to be tongue in cheek, but maybe the industry actually needs something like this.
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.
Well then it means the vast, vast, vast majority of companies with a coherent corporate structure are shit. Welcome to reality
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.
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.
So good managers (that do their job properly) are bad managers (that get fired for it).
And bad managers are good managers...
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.
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.
I mean, this is the bread and butter of your job as a manager, right? Getting the best out of your people?
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.)
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.
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.
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.
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.)
Be wary of the hero, “only I can do it”, mentality as a manager. It only leads to burnout.
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.
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’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 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.
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.
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.
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.
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.
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.
* 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.
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.
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.
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."
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.
> 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.
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.
* 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.
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.
I think you're hijacking this thread to make your point regardless if its related or not to it.
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.
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.
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.
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.
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 that the regulators are competent… but for opt in software it’s user beware
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.
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.
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.
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.
Aside from that, they're value neutral to the company. They're not spending money, any more than you buying stocks is.
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.
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.
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.
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.
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."
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/
So I'm saying it is up to the manager to either suck upwards or support peers.
Your job is to create tickets to close them. If you generate productivity along side that, then thats a bonus.
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...
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.
"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 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’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?
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.
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.
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.
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.
[0] https://news.ycombinator.com/item?id=41684082 (Too much efficiency makes everything worse (2022))
>> [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.
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.
- 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 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...
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 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.
God that hits home
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.
Is it actually supposed to be a negative review...
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!
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.
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 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.
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.
In other words, just because the metrics themselves aren't sufficient, that doesn't mean we should take them away completely.
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.
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 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.
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.
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.
I am very glad I left. I have spoken on here before about how it gave me stress induced health issues.
Did you take a salary cut?
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.
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.
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.
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?
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.
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.
> 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.
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.
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
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.
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.
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’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.
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.
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.
Taking the LOC metric too far, in either direction, is trying to read too much into a single metric.
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.
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.
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.
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 ICs could figure out people management, they would have higher pay, less work, and the ability to blame their reports for all their problems.
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.
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.)
> 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.
"When a measure becomes a target, it ceases to be a good measure." Goodhart's Law
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.
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.
https://www.folklore.org/Negative_2000_Lines_Of_Code.html
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.
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.
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.
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.
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
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.)
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 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.
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.
This has to be a joke, right? 60k income for a single income family of four? In the Bay Area or Seattle?
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.
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.
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.
1/√2 + i/√2. We are all on the same boat and I have to pick up your slack if you don't work.
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 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.
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. :)
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.
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).
"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.
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.
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.
Their temperature makes so much more sense now. I encountered that place, crash course in gaslighting. Thanks for probably getting me laid off
"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.
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?
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.
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.
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.
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.
Or maybe there’s a little more to it…?
* 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.