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.
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"
* Problem #1: the teams with actual low performers will often make similar claims
* 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.
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.
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.
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.
if (false) {
// old code
}
// new code
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.
- 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.
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.
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 [email protected].
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.
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.
[1]: https://www.wgu.edu/online-business-degrees/management-leade...
I don't agree with the conclusion though: metrics are bad.
In software, in theory, you don't need metrics. You just write good code that does what it needs to do. Add tests to prove it, you are good. In reality though everyone agrees that metrics are a good thing to have. Why do we need them? Complexity and sometimes we just make mistakes. We could write software that is very close to bug free, but then we move at aerospace speed. Not always optimal.
Software metrics come with all the pitfalls of management metrics like over focus on metrics and not seeing the forest for the trees. Yet we still find the metrics useful.
Managers face many of the same problems, so they ask for metrics. I don't think that is bad. Being bad at using metrics is bad.
So it is not "all metrics are bad", it is "individual employee productivity tracking is bad".
On team level and across teams having trends and looking at trends before and after some change is helpful and can be done only when you have metrics of course.
Hey, it's finally catching on! I stopped writing substantive peer reviews years ago, after I realised folks (including management) were mostly using them to snipe peers for things like caring about infrastructure/security, or just because they were foreigners/women/etc.
In my day job I just made a big change across many microservices updating a core dependency library, so last week it looks like I've done about 50x more work than I have any other week, but that's because I scripted the update, it's not a reflection of the actual work I did at all.
followed by
> So, my new position on that sort of thing is: fuck them
I always found rachel's articles (is she called rachel? Idk) way too opinionated. It doesn't get better with experience apparently.
I mean, don't "fuck them"... Maybe, just maybe, there's some tool out there in the blue void of ideas, that could potentially help managers UNDERSTAND what's going on.
I, for instance. As an individual contributor, I will accept everything that is thrown at me. Yet, there are specific tasks I totally suck at, and I will slack a lot to avoid doing them. I don't like going to my manager and tell them: "I actually suck at this, and if you give this task that sounds relatively easy to anyone else, I will slack the shit past the deadline for sure." So if there was a may that my manager could learn this by himself. That would certainly help everyone on the team.
I am not very proud of that particular aspect of my psychology, but you know, that's the way it is. I'm highly capable in other aspects, so I don't think my employment is questionable in any way. There is just this specific psychological thing that maybe a tool could help fixing.
What I love is that Rachel is aware of them, revisits, and explains why a new opinion has been formed.
being able to say "I was wrong, because" followed by "here is my new opinion based on what I have learnt" is much more valuable than opinion disguised as fact.
Knowing _why_ an opinion has changes is often very valuable.
> Maybe, just maybe, there's some tool out there in the blue void of ideas, that could potentially help managers UNDERSTAND what's going on.
Maybe, but what the article points out is that slapping a metric on something and saying "this is performance" leaves you with a massive quantisation error. If you have a simplistic metric, then people will optimise for it, often simplistically.
The other thing the article points out is that "peer feedback" is often not a useful way to help people. If you were to put your point about those specific tasks in your own feedback, or someone wrote it about you, it would form an indelible mark on your record. Because it'll probably be the only tangible and actionable bit of information, you manager will overindex on that.
On the other hand, we are told that these previous actions were actively harmful. Perhaps given this some degree of apology to those that might have been impacted would be in order.
The final sentence of the article is quite illuminating. I wonder whether that would have changed were the metrics useful in identifying relative work performance.
It's a courageous and commendable article either way.
Management isn't stupid, it's just a symptom of large companies.
- Yes, peer reviews don't work.
- Yes, peer reviews push the manager's job onto ICs.
- No, it's not the manager's fault. Take that manager and put them in a small company and they'll know their team without peer reviews.
Tools: sure, some metrics are either misleading or gameable to the point of being useless. But you'd imagine some tools might be actually useful for a manager? Then the perf reviews. Obviously everyone hates them. I hate them. But how do you keep large orgs of thousands of people with varying motives, moods and ability from descending into chaos?
Managers don't spike on technical problems of unpredictable depth and don't do code reviews. (I've seen wishful thinking that they did, but in practice, they don't). How can they tell if someone is genuinely stuck on a harder-than-expected problem or is simply full of shit? Verbally ask around for opinions from ICs closer to the subject matter? But that's the same or worse as an informal 360, or a perf review.
fwiw i'm currently and thankfully not a manager but i kinda see why they do what they do.
Assuming the data is correct, the much more likely explanation is that working non-stop for your whole shift is not sustainable over the long term, and that is what makes you burn out.
But the data probably isn't correct. In German, they say "wer misst, misst Mist." I've seen this often enough.
I worked at a major financial supplier whose CEO was super into metrics, and fired hundreds of the "worst performers" every year based on his spreadsheet. Like clockwork, every year, I saw the most valuable people in every team get fired, because those were people who had a deep knowledge of the system, and were often diverted from doing "visible" work by helping less knowledgeable people. They were the ones who trained new hires, who you went to when you couldn't figure out how to debug your problem, who wrote the architecture documentation so people knew how things worked, and so on.
Guess what, none of this stuff showed up in any spreadsheets.
It didn't help that they usually also had worked at the company for longer, and had higher salaries, so firing them "saved" the company more money.
Unsurprisingly, the software product they sell is an absolute mess.
... but disagree from the high-performing engineering org notion of individual & team productivity. It's hard to improve technical processes when you can't see them. Is some person a 10X'er because they write shit code that other people have to refactor & fix, rely on other people to take their code to production, and don't do their share of code reviews? Is the team slowing down because PRs and deploys are slow, testing is manual, and everyone is used to it? Are calendars too packed or fragmented? Etc.
Any individual item can seem ok, but a lot easier when you can see the issues, reflect as a team, & see how chiseling away works/doesn't.
We had the technical means to track everything from commits to reviews, jiras, deploys, etc. Some of our most celebrated and impactful features were reporting on Accelerate metrics and related. E.g. deploy frequency, size of changes, duration of stages in the dev cycle and such.
I set a very inflexible red line: we don’t expose data more granular than at team level. Ever. No excuse.
Quite a few line managers would come to me asking for “personal metrics”, and even engineers in the team were super interested in building that (“with all this data we could…”).
My argument was that these metrics are toxic and invite misuse. A second factor was that this misuse would generate mistrust from engs against the platform and damage adoption.
Instrumenting an organization thought of as a system is fine. You want to see where are bottlenecks, you want to have measurable targets for how technical work is done and how it correlates to business goals/KPIs.
You want to offer teams metrics of their delivery my process so they can take the info and implement improvements whenever they see fit, and have a data driven conversation with the business (e.g. about the right setting for the carefulness knob)
But teams are the minimum unit of ownership, we stop the instrumentation there. Sure, a team’s performance ultimately links to individuals, but that is the manager’s job to figure out.
Interestingly:
* only line managers asked for this info, nobody in a director/vp/cxo role * the most annoyed by me saying no were engineers in the team who wanted to do these features
And, cynically, I would say that senior managers don't care... because to them, most hands-on engineers/devs are fungible. What is your view about why the upper levels never ask for it?
I generally agree with OP, but there are times where as a manager you know exactly what is going on with your team, but numbers are still helpful.
You generally scapegoat one level down and then let that level push it further down if it can.
So the Directors need team level metrics to find which managers reporting to them to scapegoat and have data to "prove" it.
Then the Managers need individual level metrics to find which engineers to scapegoat and have data to "prove" it.
Nah, you don't need to assume malice :)
Most times it was managers with good intentions, not realizing that those metrics were either pointless (e.g. how much code / commits does $person do), or toxic, in the sense that it leads the team to game metrics, that it prevents the manager to actually understand why the values are what they are, that it opens the risk to link them to promotions and perf reviews etc.
Explaining them all this was generally enough!
> And, cynically, I would say that senior managers don't care... because to them, most hands-on engineers/devs are fungible. What is your view about why the upper levels never ask for it?
Actually that wasn't the case. AFAIK (I left at some point, but kept a bit in touch with former colleagues) upper management started using some of those metrics to set organizational objectives.
Again, same argument. You don't need to assume malice. Management has a legit interest in engineering productivity. What happens most of the time is that they don't know how to measure it in an effective way, or how to use it to drive organizational change. Providing guidance is part of your job as a Platform eng.
Now, why is that? The first possibility is that they ran into a string of tickets that were just harder than we expected at the outset, and it's a statistical anomaly. A second possibility is that this person takes the hardest of the tickets, and anyone would struggle. A third possibility is they are taking tickets past their capabilities as a developer and aren't getting the help they need. In this scenario, they're a capable performer, but are need help to get to the next level. Maybe they're junior, or they're a new employee. If they keep taking these tickets, they will grow and their performance will jump. In these cases, you just keep monitoring.
In the middle case, they may have transitioned to a team or project that is a bad fit, and would thrive on another team or an adjustment to what they're asked to work on. They may be a front end specialist that was expected to pick up back end tickets and struggled from the start. Or, they may be in a temporary dip due to personal circumstances.
Then, you have the negative cases. Their work ethic might be insufficient. They may just not be good at their job and may not ever be able to match the performance at the pay grade and seniority they were hired. Or, you may have a good bullshitter on your team and your numbers tell a different story.
The numbers will tell you if this is a temporary dip. The numbers will tell you if their current output is in line with the rest of the team. From there, the hard work starts.
If you don't have those numbers, it starts looking like a lot of status updates and micromanagement.
Also note: Most managers end up doing a lot of part time jobs, of which performance management is a relatively small part. If my primary job was performance and task management, that would be a very bad use of resources for the company.
We wanted the metrics to create the right set of incentives to make people improve the right parts of the system.
For example, we did present deploy frequency prominently. This gets people to see it, managers to want their team to be in the upper percentiles, etc. which drives a set of practises that, in general, and backed by research, are beneficial.
One of my favourite features was putting two graphs together: size of PRs vs. time to review. Time to review went up more or less linearly to size of PRs, but past a certain threshold (different per team!) time to review dropped sharply with larger size of PRs. This made for a good conversation to topic with teams that sets the right incentives for smaller PRs, iterative development, etc. (and it happens to correlate with deploy frequency).
Devs who have seen this behavior before tend to push back hard on adoption, and then invest the absolute minimum effort in using these tools. The tools tend to be built wrong often enough to encourage that slide into toxicity. There’s an amount of using a tool where it improves your work experience, and then an additional amount that improves the team experience, and then beyond that it’s doing your manager’s job for them and self-reporting/narcing.
I’m trying to build a tool at the moment that has had three focuses due to different sources of inspiration. First it was going to be Trac (a project management tool and wiki that is so simple it shouldn’t work, but somehow does) with bits of Jenkins. Bamboo has thousands of features and integrations where it should have hundreds. All those integrations make reproducing a failed build locally difficult or impossible. The bones of a build process should be in the build scripts and dependencies, so you can run them locally. The build tool should schedule builds, report status changes, collect some release notes data, and track trends with grafana charts and that’s about it. I also want something running in each dev’s machine to boost system performance and do some of the teamcity features for trunk based dev like push-on-green-build. I just miss how distilled Trac was, but it had some problems with plugins and git support.
That sat on the Some Day Shelf behind two other projects until I read Cal Newport’s Deep Work, and then Slow Productivity. Then it became more user oriented. Atlassian has about three per-user dashboards that I’m responsible for juggling all day, and that is tragicomically stupid. I’m terrible with this sort of juggling but have coworkers who don’t check the PR list ever - you have to pester them to look at PRs, week in and week out. If I’m doing deep work I don’t want preemptions except in specific circumstances (like I broke trunk). But when I come up for air I need a cheap gestalt of what I’ve missed and what people are expecting from me. Show me all the PRs, and my red builds and open tasks in a single view. Allow some low priority alerts through. And that can be facilitated by building a pomodoro straight into the dashboard and information hiding during deep focus moments.
I have some family that was recently diagnosed as neurodivergent, and the thing about YouTube is that your suggested videos get influenced by what other people in the house are watching (particularly if you’re not logged in on a device). ND people of all types have a lot of coping mechanisms to function within other people’s expectations (eg work and responsibilities) and to mask. They get both barrels when it comes to being judged poorly by toxic management tools because their variability is so high. Best performer one day, second worst the next. And this is nowhere more true than with ADHD. And the worst of it is that almost nobody will go harder and farther than an ADHD person during a crisis. They can hyperfocus during rare moments but most reliably due to an emergency (self created, like a paper due tomorrow, or externally driven, like servers on fire). They also innovate by drawing connections nobody else sees between different disciplines.
But they’re the first on the block when toxic metrics kick in. And the productivity tools they objectively need more than anyone else on the team seals their fates, and thus they either don’t use them or use their own, which are similarly poorly integrated, which leads to more plate spinning which they are terrible at.
So what finally got me ass-in-chair in front of a keyboard was realizing that if this is two tools instead of one, you can keep some of the productivity data on the employee’s machine where it can help them with time management and self-improvement but not self-incrimination. Then you can cherry pick and clean up the narrative of your day or week before you self report. Have private tasks on your machine that may look embarrassing to others (like remember to drink fluids, eat lunch, call the dentist, tasks you’re skunkworking).
But that is the job of middle management to know. And if upper management cannot trust middle management to give them honest and good feedback on this, then they have the option to hire and manage better middle management.
> Why? It's surprisingly simple. It's the job of a manager to know what their reports are up to, and whether they're doing a good job of it, and are generally effective. If they can't do that, then they themselves are ineffective, and that is the sort of thing that is the responsibility of THEIR manager, and so on up the line.
Just because people starting measure the wrong stuff, number of PRs, number of lines of code, check in counts, etc, doesn't automatically conclude that the act of measuring is superfluous.
If the act of measuring is the responsibility of someone higher up, who is even higher? Is it manager all the way up? Do we, for instance, conclude that the CEO is ultimately responsible, and every not CEO relinquish the responsibility of knowing any measurement of performance?
Aren't we all CEO of our own life?
the show is set in a law firm, and in this particular episode they needed to lay off some of their associates. a young, newly-promoted lawyer was tasked with drawing up a list of the associates and marking the ones who she felt should get the axe, based on their performance. so she comes up with some metrics, goes through the associates' work, and ranks them based on the resultant numbers, saying that the bottom few could be let go.
there is one employee, brian, who ends up near the bottom of the list. a more senior person takes her aside and asks why she recommended brian be laid off, so she brings out the metrics and rankings and points to him near the bottom. the senior person asks "okay, so who are the top associates in your list? can you point them out on the seating chart?". turns out, the top five associates were all brian's neighbours, and the reason was that he was really good at helping people when they were stuck with something. but of course that affected his own individual contributor numbers, and there were no metrics for "helped someone else out but didn't get credit for it".
""" After crunching a lot of data, they found that the only thing the productive employees had in common (other than having made it through the Bell Labs hiring process) was that "Workers with the most patents often shared lunch or breakfast with a Bell Labs electrical engineer named Harry Nyquist. It wasn't the case that Nyquist gave them specific ideas. Rather, as one scientist recalled, 'he drew people out, got them thinking'" (p. 135). """
I don’t think we’ll ever see a Wikipedia quote saying “the only thing productive employees had in common is that they were hanging out in a Microsuck Teams chat room”.
I've never had any trouble having real conversations on online platforms, whether for work or otherwise.
Not completely wrong, but…
I've not heard of any research that shows that it's impossible to have meaningful conversations on these platforms.
And please note the distinction between "it is impossible to have such conversations" and "some people (especially less tech-savvy people) have a harder time having such conversations" on these platforms.
Teams/Slack/Discord/etc is just another communication medium. Once our society has, collectively, had more of a chance to get used to them, and once we're no longer dealing with an entire generation who were bad managers before the personal computer even existed (</hyperbole>), I wager you'll see a lot less complaining about the medium itself.
[https://pubmed.ncbi.nlm.nih.gov/35648039/]
And overview [https://www.psychologytoday.com/intl/blog/the-brain-body-con...]
None of them in any way address the issue at hand, which is the ability to engage in meaningful conversations over online platforms such as Teams and Slack.
I said they weren’t the same as in person.
The reason for zoom fatigue, as the papers call out, is because zoom or similar is fundamentally different than actual in person conversations.
They are missing something important. Several things which are important, actually.
Just like twinkies vs ‘real food’.
> Except you don’t actually talk (as in have a real conversation) with anyone on Teams.
That is the specific argument that I am refuting: that your experience of not being able to "have a real conversation" on Teams, etc, is universal, rather than just being your experience, which cannot be extrapolated from without gathering significant extra data.
"People get Zoom fatigue from having too many video meetings (especially in the first 2 years of regularly using video meetings after never using them before)" is not the same thing, and does not prove that these technologies are impossible to use as a replacement for in-person meetings on a wide scale.
If I have one twinkie, that isn’t a problem - because I have other ‘real food’ to compensate. Same with someone doing zoom periodically.
If all I have is twinkies, that is a real problem, because I don’t have enough real food to compensate. I’m missing some essential vitamins, minerals, and macros that will eventually hurt me a lot. Plus a lot of sugar that causes a lot of load in my body we really don’t handle well.
‘Zoom fatigue’ is exactly because people aren’t having enough real in-person interactions anymore and it’s causing numerous real psychological issues in people because of it.
Because there are actual necessary things in real in person interactions that are not present in video conferencing. And real effects of doing video conferencing our minds don’t handle well.
The insistence on ‘but it’s not impossible!’ is tangential to the fact that it isn’t a good idea to do long term or exclusively.
And depending on the individuals environment or makeup, it could be an immediate major problem, or it could be a slow burn. Everyone will have a different tipping point.
I’m sure there are some 1-in-a-million outliers out there that could stay pretty functional literally eating just twinkies for a decade (somehow).
But either way, having the social interaction equivalent of an all-Twinkie diet is a bad idea.
Near as we can tell.
But ‘this is America!’, with an ongoing obesity crisis, so not like I expect people to just listen.
I've also seen the room be quiet way too much on some teams. This is always bad, but hard to fix.
Regardless of the reasoning, it's toxic to WFH/remote work, even in the short-term. And it's outright sabotage in the long run when it's time for someone who wasn't invited to the "correct" chats to onboard a new hire who ends up needing some context that exists only in someone else's private chat.
And again, it's not like our managers are bad, quite the contrary, they are very good professionally and personally. And we don't have layoffs. But people still won't talk in the presence of even mid level management, it's an instinct of sorts I guess :) .
PS: this is only about informal optional chats. All work chats are never hidden or avoided. We divide them by program, Slack for work and Telegram for fluff.
That said, I would not trade WFH for anything. Those walking times with co-workers was great but it's not worth being forced to go into an office every day.
As one potential mitigation, I’ve consistently had deep mentorship conversations over the phone. For me, I think voice-only is actually much better than in person.
> For me, I think voice-only is actually much better than in person.
I agree that video calls are a special hell.
I think I am reasonably high functioning in in-person settings, but I suspect I don’t read body language very well. I find eye contact difficult to maintain for reasons I do not know.
On the phone, I feel like conversations can be slower and more deliberate. I feel a freedom in not having to control my expressions and show my interest. I can just focus entirely on their voice, and I feel I have become very adept at this. I love podcasts and audiobooks and such, maybe there is a connection.
My wife describes very differently dynamics. She wants to meet with folks in person to “read” them better. She thinks my preference for phone only makes no sense.
> I find eye contact difficult to maintain for reasons I do not know.
If the and answer is yes, then what was the rate of such encounters per number of employees?
And finally - honestly answer yourself - does this minuscule probability worth the ~30 full awake days in every years of life, of every employee? (2 hours commute per 250 days in a year, then divide by 16 awake hours per day) For me the answer is obvious - it is not even remotely equal in value to such a gigantic time waste. If that super brainstorming even real at all. Personally I've never observed this.
Home office nudges towards isolation and lack of physical activity, while the office nudges towards interaction, moving at least a little bit and face to face interactions. No matter the outliers, the latter are considered universally good.
I’ve noticed that when I am in the office I usually have nice conversations with colleagues at lunch, that are good for my well-being. Sometimes we discuss interesting news from work, or their projects or other technical topics. We’re not Bell Labs of decades ago so the impact is obviously not large, but it exists.
My commute is 15m by bike. Even so I don’t look forward to going to the office because of various factors, but I do usually enjoy it when I’m there.
You say this as if it's a fact, but with an extra 1-3 hours of my day freed up, it's a lot easier to get into the gym or visit my friends and family. Personally, I was more active and less isolated when I worked from home.
There are famous groups/chats that allowed the creation of stupendously important software.
I sucked at school until someone opened up the idea for me around third grade that how the curriculum is taught is just the teacher’s opinion, not a law, or a religion. If you can reframe the material in a way that makes sense to you then do so. I ended up spot-tutoring a bunch of people over the years because I would hear them complain about how the material made no sense and I would swoop in and say, “yeah how they teach this is bullshit, have you tried thinking about it this way?” Which validates their frustration and then gives them a life raft.
That kind of reframing to keep up can become reframing to get ahead. I went from Problem Student to grade school “valedictorian”, to polymath. Years ago we were all fixated on the trap of Expert Beginner and I would half-joke that I was instead an Expert Journeyman - able to quickly get to adequate instead of mediocre in a new discipline. And these days I think that may be what “polymath” is most of the time. Just knowing what the next question is to ask to keep going. The big breakthroughs come from people who become experts in most fields, but these same sorts of people also get pretty good at music or painting or writing as a hobby. As good or better than mediocre professionals.
The first time this happened to me in a professional setting, a coworker was stuck on a SQL problem and insisted I pair with them to help debug it. I told her I’ve never touched SQL, just worked on some bespoke data processing. She didn’t care. Come here anyway. And I’ll be damned if I didn’t help her find her problem by just asking her what this part does and that part does. Why does this work that way? And I started writing SQL a couple weeks later, substantially off of just that interaction, bolstered by what first generation search engines could scrape together.
And the thing is when everyone asks you questions and you don’t break their trust, you quickly learn where all the bodies are buried in the project/org. Which is a valuable asset for someone wishing to become a lead or staff engineer. I became lead by popular vote most times, rather than an actual game plan to get promoted. I just did what thought needed to get done and was within my abilities, which looks a lot like leadership, especially if management doesn’t have that quality. Port in a storm, that’s me.
But I’ve never ever completed the most stories or features. I’ve occasionally fixed the most bugs, the most performance issues, or workflow problems. Is calculated I saved forty man hours a week for the team on code-build-test-push ergonomics and my shitheel boss was still made about my productivity those two quarters. I could not show up to work and still be contributing 8 hours a day, dummy.
Employees should be evaluated, by their peers, their managers, and their subordinates. Wherever possible, the evaluations should be qualitative rather than quantitative.
Trying to automate performance evaluations and boil your employees' contributions down to numbers in a report is both idiotic and inhuman.
Everyone knows the terrible team members, and everyone knows the outstanding team members. If you need information to inform layoffs, promotions, or raises, the best way to get the information is to just ask.
But all the associated tooling that has been created over the years for figuring out who is doing what are insanely counter-productive. Assume you work in a large corporation and you are tasked with "implement and deploy X". Fine. But in order to deploy it, you need to rope in a dev ops, sec ops, 3 other people to sign it off and 10 other tickets being tossed around between a dozen people which are nearly impossible to track. All while your manager is sitting there, looking at this one ticket assigned to you and be like "tf?"
So no only do you have to effectively manage a process involving 10 people but you also need to find a way to show that you are in fact trying your best to make progress. Keep in mind that everyone else working on your problem are also involved in 4 other things in each given time.
For a manager to be able to work through that, they must be ready to put the needs and comfort of the people they manage before their own and be ready to make some internal enemies in the process. So far I've had two such manager in my whole life and it was a genuine pleasure to work with both of them - everyone was doing the absolute best they could 100% of the time. In both instances, we had 0 tools to monitor who is doing what - the only tool we used was gitlab with merge requests, even if the company enforced Jira. What the managers did was manage Jira on their own completely and not bother developers at all with it. As a tech lead, I did not even know where to access Jira. And when we got asked how come we get everything done a month and a half before anyone else, the simple answer was "f-bureaucracy". Even when it came to dev ops and stuff, we had become friends with some of them and had an internal rule: "Before sending an email, send me a message in the chat so I know what's needed and I can prepare myself, send us an email and send me the ticket id you get. We love working with you cause you come with clear instructions and no bs". This is an exact quote from a devops in Ukraine who had around 150 words in his English vocabulary. And whether it was a kubernetes cluster, network configuration, upgrades, downgrades, backups or anything else, the most we've ever had to wait was less than an hour. You don't need Jira to know when someone is slacking, whether you are a manager or someone else - you can't hide that and we've had such people on those teams, it's up to the manager to address those.
This is of course large corporations. In smaller ones, it's less straightforward and even more in the hands of the managers. The first question you need to answer is whether those companies aspire to be large corporations while having 50 employees(in total, I don't mean in the tech departments). If that is the case, then it's the same as what I described above and if you pull she short straw(the way I did at my old job), end up with an absolutely insufferable, egocentric team and a manager who's policy was "don't start conflicts, no matter what, sweep any confrontation under the rug as fast as possible".
The second type is the Jira(and jira-like) obsessed managers in small companies where acting as a developer, dev ops, infosec, network admin and hardware admin are the same thing for everyone involved. This is fine to my mind, but we get back to "implement and deploy X". Do you want me to log every action I do, while doing a ton of R&D, setting up a redis cluster, kafka and 3 other things or should I focus on getting it done asap because those things are mutually exclusive.
And the last type, which appears to be my current job - "0 nonsense", "nothing will ever be perfect", "we know we are fixing our car while driving it" are all 100% acknowledged by everyone, management included. A small board with what is needed, "whenever you have time, figure it out". It may sound bad, but it works astonishingly well.
I agree with the general sentiment that metrics are not a panacea. Managers need to put in work to do their job, instead of leaning blindly on tools like metrics. IC's need to do their work instead of expecting managers to prop them up.
I'm guessing that this is what the article is trying to convey. What I read though is a complete 180 flip into "no tools are helpful", and "don' help anyone" territory. I don't agree with that.
Somewhat hilariously I was a manager during Covid, and as such I saw the metrics which showed that every worker group in the city I was working for was happier and more productive. Except for middle managers and the various positions they are in meetings all day. Interestingly productivity was way up despite people spending significantly less time at their computers.
I'm curious how productivity was measured for that. I assume happiness was self-assessed, but I'm also surprised that'd be up given how much of a rollercoaster a time that was just in general.
Yet of course it's extremely hard to make people understand that, when these are things that they, their families, and even their communities or their polities have been doing for generations, and are directly relevant to their short term livelihood (which they see as medium or even long-term livelihood, as "short term" here means decades).
Managers are people too, despite of what Dilbert will have you believe. They need help, support, and tools.
It's true that many tools and frameworks are sold as magic pills that solve all the problems. Metrics are one of those tools that are often misrepresented. I think that many of the tools are helpful, if used skillfully.
You can't manage what you can't see. You see your team through your direct interactions with them. You see what they do through the artifacts that they produce. You learn about them from others - hear-say, praise, complaints, and gossip. You also get another perspective through various metrics. You need to combine multiple ways of seeing a team to have a more-complete picture. Take any of them away, and you're a little more blind.
I remember when I first transitioned into the manager role. There was so much that I needed to learn. Some of the tools gave me insight into what is happening on the team that I really don't get to observe directly. However, none of the tools did my job for me. I learned by reading, using new tools, and experimenting. Over time I honed my ability to be able to understand what my team is doing well, and where it needs help. If someone took away ALL the metrics-based tools, I would have fewer ways of evaluating my team.
Managers need as much help as anyone else to do their job. This also involved introducing new tools, and teaching managers how to use them. In a large part, that is their manager's job. Sometimes they call me to help.
I understand the sentiment around that managers should do a better job and many metrics based tools miss out on people performing necessary tasks that won't show up in the metrics. The people I have managed who fit those criteria were very obvious and it was known their code delivery was suffering because they were helping others. The good players always stood out.
The areas where I had wished we had comprehensive people metrics were frequently for remote employees on drastically different time zones where daily regular interaction was difficult or where there was some clear under-performance but the WHY was unclear.
It can be very tricky being a manager and to getting to the bottom of WHY someone isn't performing. Should a PIP be necessary, it's very important to identify specific behaviors that need improvement.
During 1:1s, under-performing employees will provide the most vague explanations, copious excuses, blame other factors. Even when I've cross checked with their peers, no one wanted to really give any clear answers as to why something was late, had abnormal amount of issues, or development was standing still altogether. People were clearly avoiding the questions.
Everyone here seems to assume direct reports are always honest, open and transparent. They are not, and especially when things are not going well.
Manager need a way to verify what they are hearing. Do the metrics support the claims, or is someone who's slacking just BSing you. It's not where you get your primary information on performance, it's what you use to verify your own suspicions or find supporting evidence.
For example, an employee who has a history of not testing their code and has in their development plan to improve on that. During 1:1s, the question comes up and invariably, every time I've been positively assured they are making great progress and everything is being tested.
I now have 3 options: 1. perform my own review of their code to verify their claim 2. get a high level metric that testing has improved 3. trust what they are saying, move on and throw the dice that everything will be fine
Option 1 is obviously the best but very micro-managerial and will clearly demonstrate I don't trust their word, further demotivating the individual
Option 2 would be a good place to start unless employee gives me further reason to go with option 1
Option 3 is what shitty managers do
How does a engineering manager know what their managers are up to in order to get an understanding of what their manager's team members are up to? Even worse if you have a large enough organisation where you may have managers managing leads who manage teams?
I had a day like that, a couple of days ago. I spent a significant portion of the day, building experimental approaches to handling an issue, but reverted, at the end (the experiment did not yield the results I wanted). That is fairly common.
Also, a big part of my reflective refactoring, is reducing codebase size, like factoring out common functionality into protocol defaults, and/or base classes. That can take quite a bit of time.
So LoC/Time is pretty much a worthless metric.
And if you cloc my codebases, the comments/code ratio is usually about 50%. Documenting my code[1] can take a lot of time, as well, and is actually a fairly important part of refactoring, as I often find issues, when I have to explain what’s going on.
[0] https://github.com/ChrisMarshallNY#github-stuff
[1] https://littlegreenviper.com/miscellany/leaving-a-legacy/
There's a big school of thought, that "gamifying" things, brings "engagement" (the holy grail of SV).
I'm old and cynical. It doesn't really do much for me, but it is a well-integrated hosted solution, and that's what I get from it.
For top performers it's more nuanced. In general they will be top of the contribution stats but sometimes if they're doing R&D or hard work then the stats are not very meaningful. But that's why we don't rely on them.
So metrics have their place to inform and color existing perception. But they will rarely change perception completely.
But I think as you indicate, qualitative generally paints the picture, and quantitative validates it.
This is circular logic. If you measure that "coding contribution" nonsense, people's "performance" will be perceived based on that, _especially_ by their direct managers.
I agree that it’s something a manager could over-index on. I’m not sure how to avoid that beyond adopting a mindset of “this is noisy data that sometimes gives you important insights.”
Of course we've all seen varying degrees of this - but these kind of people can only exist because of terrible management. Throwing metrics at the problem just introduces a more insidious version of this individual, one that knows how to game whatever metrics are used (managers especially will do this). I've been on teams where such an individual could thrive for years, even with promotions, and on teams where such an individual would be outed within a week.
In another case, I knew the manager well, having been on his team before. He was effective, empathetic, and inspirational. He was also overworked and perhaps a bit naively assumed good intent from everyone. The data let me explain to him that the coworker was not contributing and he had a real problem.
Detecting slackers efficiently is simply never going to be a top priority. You have to trust your people. Usually it’s incredibly rewarding.
This is called "broken clock shows the right time twice a day."
Also c'mon, fooling commit metrics is silly easy, just _also_ one of the most burn-out and check-out inducing things ever. And at senior level you _HAVE_ to do that these days. You _have_ to inflate them.
Your broken clock isn't free.
Measurement (if any) should be on the realised gains in the short and long term, not the visible investment. LOC, tickets closed, hours spent etc can all have negative payoffs.
Unfortunately that is hard to measure, as Rachel points out.
Perhaps I am wrong.
So indeed, corrective and maintenance work have payoffs.
This would also be true of managers - their work should pay off over time, so measuring it in "meetings attended" is not a good metric.
However, there are a few problems here:
- There are more manager positions than there are qualified managers. So you will always have people who are simply bad managers. This is generally more true in larger companies where productivity of an individual team is easy to ignore.
- Even good managers are humans and are subject to emotions and biases that they don't even realise they carry around. The only things which bring objectivity is data and good processes.
- Hybrid or remote work is a larger trend that began much before covid, and while back to office mandates might make it seem that the trend is loosing steam, it is not. There will be more remote work in coming years, and that makes understanding your peers' work even more difficult.
So what is the solution? I believe that:
- You should measure events, but you should have the intent that you want to "understand" what is going on, instead of policing people. Data can reveal a lot, like conflicting work patterns, burn-out indicators, problems in communications etc. Not all metrics are bad.
- You should combine objective data with subjective feedback, as well as more context such as life events (marriage, becoming a parent etc) to understand how people work.
- Processes should enhance focus on outcomes, rather than activity. Frameworks such as OKRs are hard to implement correctly, but they do let you focus on business outcomes. The problem with knowledge work is that you cannot measure it with activities alone. Trying to bridge OKRs with activity metrics as well as subjective feedback can be helpful.
For disclosure, I am founder of a platform called Crewnetics, and we are building tools for measuring performance of knowledge workers.
So? Let companies fail, let the world rot. If people want to live indoors they need to learn how to be good at something.
> Even good managers are humans and are subject to emotions and biases that they don't even realise they carry around.
Data doesn't solve this it codifies it. Tracking commits is PERMANENTLY codifying a commit frequency bias to work performance.
> There will be more remote work in coming years, and that makes understanding your peers' work even more difficult.
How? Did managers only understand what was going on by looking over peoples shoulders? What data did they get by people sitting near them? Looking busy and getting stuff done are two things that look the same from the outside.
I don't think this is mutually exclusive with building tools that gives a bird's eye view of what various employees are doing. In fact, that sounds like a helpful tool. The ONLY tool? No, of course not. And a healthy dose of interpretation is required - in the same way that an engineer must look at a datadog dashboard and apply the necessary context to interpret anything useful from it. Some level of human interaction and empathy is required to be a manager. But if I can "know what my reports are up to" at a glance rather than interrupting them to ask...seems like a win win.
But I’d add one thing. Peer review is extremely valuable if you use it as a tool for career improvement and not as a tool for performance review.
To do that though you need 2 things, trust between the peers and for it to have no way to impact career progression from the companies perspective.
So when I was a manager I’d have a rule that at 4 times a year my reports would need to do 2 peer reviews with peers of their choice. Preferably over lunch the company paid for. The only thing I wanted to know is if it happened or not.
I got mixed feedback on the method from my reports. I think the ones who saw it as an opportunity to get real unadulterated feedback loved the process, while the rest just got lunch. Which is fine.
The steel man argument would be that employee metrics can provide a couple data points that a manager doesn't take action on by themselves, but can help a manager know where to look. Metrics can flag unusual situations. Sometimes there's a great explanation behind employee X making 80% fewer commits than the average employee. Like less rework, making more impactful changes, or simply bundling more changes together. Other times, it can be a sign that someone is having trouble onboarding or simply not performing at the necessary level. When you see that a metric is different than what you expect, it's your responsibility as a manager to figure out why.
I've always wanted to see regular anonymous mass surveys of employees, about things like project progress and completion dates.
Do you want to know when a feature will be finished? You can analyze story points and build a fancy burn down chart, or you can just ask the people working on the feature. Allow the entire team to anonymously predict when the feature will be finished and I'll bet you get a better answer.
Anonymity is important because people are easily pressured into changing their answers. We've all been asked "how long do you think this will take?". "Two months" you answer. Then managers pressure you into changing your answer, but usually, no matter what you're forced into saying, you still think it will take two months.
Why did they ask if they didn't want my answer? Therein lies the truth. Companies don't want accurate answers and data, they want to see and hear what makes them happy right now.
I don't think most companies would have the courage to regularly gather data with anonymous surveys.
But maybe, if one clear-headed and high-level executive wanted to force it on the company, they could. They could mandate the use of a software tool to do anonymous surveys, and no matter how much lower-level managers complained, the team could still anonymously say when they actually believe the project will be finished. Etc.
This would result in lower tier managers announcing beforehand they claimed "x time for y project" and if the devs want their sickdays/bonuses/promotions they should claim same.
This would be anonymous, the only thing that wouldn't be anonymous is whether or not an employee has updated their survey within the last 2 weeks.
I would absolutely throw that hypothetical lower-tier manager you mentioned under the bus. The surveys could have a "rate your manager 1 to 10" question too.
I think it would be valuable insight to all levels of management. If the team is being death marched, happiness and quality surveys would drop. Or, if you see a team deliver a buggy project, but quality surveys were high all throughout development, then you could tell that the team was incompetent and hire/fire/train accordingly.
[0]: Don't ask people to guess completion dates, have them guess percent completed and then calculate completion dates in the software.
Employees could lie about their own happiness, and satisfaction with their manager, to their own detriment. Employees could also lie about project progress and quality, also to their own detriment, because it looks bad if a team says "everything is on track, quality is great", and then the project runs long and is a buggy mess.
I just think a lot of what a manger does is give progress reports, and it's easy for one person to lie about progress reports, and then when it becomes clear that the progress reports were wrong all along, the manager somehow shifts blame to the workers. These surveys would give everyone a say in the progress reports.
It's hard for me to take any of this seriously. Industry-wide we're told layoffs have to happen and these same corporations go on to post record numbers, far exceeding internal and external expectations. Executives are lavished with bonuses while many of my colleagues are getting < 2% CoL adjustments while taking on more and more responsibility and accountability. But also, please, tell us what we can do better! We're listening and we care.
So, no, frankly I don't feel like I owe my employer a single fucking thing beyond showing up, doing my work, and leaving. I certainly don't owe the top-level leadership team the truth when they aren't honest with me.
But I want to make it clear, too, that I'm not lying on these surveys. But, they're not getting a full accountability from me, from my perspective, either. And even if I wanted to give that, it'd be pretty hard when the questions are worded in such specific, guided ways and there's very little space for providing direct feedback.
And, if you decide to just always say things are going well, then that's what management will see, and the status quo will remain. At least until a project goes poorly--delivered late and a buggy mess. Then, if I were a high-level manager, I would look at the surveys and see that the team was happy and believed everything was perfectly okay right up until failure, and I would judge the team as incompetent, because a competent team would see failure approaching long before it happens. I'm not saying I would fire anyone, but clearly a discussion needs to be had with the team manager, and probably the whole team, about reporting problems early.
Of course, if a company wants people to report problems early, then they need a culture that responds well to early warning signs, rather than the shoot-the-messenger culture that is all too common. I do sympathize with your frustration for fucked up company cultures.
If you left comments, it was generally possible to figure out who said what based on idioms etc. but they were kept separate from the scores anyway.
I thought it was a good system but I'm pretty sure it was gone by the time I left in 2023. If nothing else, I don't think a system based on that kind of radical candor can survive the first or second round of layoffs at any company.
Peer reviews are what allowed me to break out of imposter syndrome. Realizing that people valued my knowledge, contributions, and demeanor while still acknowledging areas in which to grow was instrumental in me breaking out and realizing I was bringing value
Is it wrong to use tools for doing your job? Metrics can be a part of knowing what your reports are up to and how effective they're being.
I feel that there should be an alignment on what the expectations are and how people are graded and these tools should be applied before the evaluation and information should be provided to employess on how they are doing on a regular basis.
I would say that if a manager sucks, it might not be the employees total fault, because they haven’t clearly delineated expectations to the employees.
To just apply analysis retrospectively makes no sense and it should be applied regularly, so that people know where they are and can improve.
I’ve definitely worked at organizations that are totally unorganized and it’s totally unclear what the objectives are and they will just call you up and give you different objectives every day and then the performance review addresses totally different objectives from what we’ve been actually doing the entire period.
Metrics are like supporting arguments for a whatever narrative a manager is telling. I've used employee metrics to help support the case for promotion or supporting my case to HR for why they should be fired (I've never fired someone because of metrics). It reinforces observation. The time metrics get toxic is when a manager starts telling ICs their performance is their metrics. A whole host of bad things happen then.
And if you're telling me bad managers will suddenly become good managers if you take away their employee metrics, you've got a surprise coming.
Sometimes the content is decent. But this post, and this line, hits me as very tone deaf. It’s like no deeper reflection occurred.
If you're not going to to use metrics (agree that we are very limited by what can be measured), and not supposed use peer reviews (agree that they can be rife with bias), the only way to reasonably expect the median manager to know the ins and outs of everyone they manage is to have a small ratio of managers to team members. But that means more layers, and people hate that too!
Also let us not forget that the alternative presented ("It's the job of a manager to know what their reports are up to, and whether they're doing a good job of it, and are generally effective.") boils down to "does your manager think you're good" which is it's own giant can of worms.
I have bad news. Unfortunately if your manager does not think you're good, literally nothing else you're going to do will matter, no matter what metrics say in either direction. If your manager does not think you're good, you should leave immediately unless you have some trump card in the form of a higher-up manager who does think you're good. It's the only exception (and barely an exception at that).
So, short of that universal caveat, what system is better? I've said this and I'll say it again: EMs should have unilateral power over their reports performance designations. They already basically do, and the delta wherein they don't is by far abused for evil more than it is for good. So just close the gap.
You fire the bad managers.
Well, the next question would be how do you find out if the managers are bad? One has to talk to peers, subordinates and superiors and do anonymous feedback, in addition to random checks. All that has to be done by the upper management. If the upper management is not doing it it can only mean either of these 2 things: 1)They are not interested 2) They are too incompetent to do it.
But the article claims you can't trust peer reviews, and that managers should just "know" what their reports (in this case line managers) are up to / how good they are...
If you ran a company that you founded how would you judge a manager? You don't just sit on your ass and hope that someone will tell you about the new manager that was hired. You actively seek information, you grill people, you hold the them high standard of integrity.
Also worth repeating: If the upper management is not doing it it can only mean either of these 2 things: 1)They are not interested 2) They are too incompetent to do it.
I will be happy to sit in an office with my VP and HR and explain to them that we have to let them go due to not performing up to $COMPANY standards, but we wish them well and here is 2 months salary and a copy of your NDA and non-compete; can I have your badge please?