[HN Gopher] A change of heart regarding employee metrics
___________________________________________________________________
A change of heart regarding employee metrics
Author : zdw
Score : 521 points
Date : 2024-11-04 05:06 UTC (17 hours ago)
(HTM) web link (rachelbythebay.com)
(TXT) w3m dump (rachelbythebay.com)
| peterldowns wrote:
| I stopped working on a tool in this space (https://dev.log.xyz)
| for a variety of reasons, but the idea that you could really only
| sell it to incompetent teams who wouldn't be able to benefit from
| it is one of them. I agree that management cannot and should not
| be replaced by software, and good management is fundamentally a
| human-to-human interaction. That said, I'd use devlog myself in
| the future -- sometimes information gathering takes a lot of time
| that I'd rather spend on actually talking to people rather than
| clicking through a million github tabs.
| ethbr1 wrote:
| >> _[Why not build programmer performance measurement tooling?]
| It 's the job of a manager to know what their reports are up to,
| and whether they're doing a good job of it, and are generally
| effective. If they can't do that, then they themselves are
| ineffective, and that is the sort of thing that is the
| responsibility of THEIR manager, and so on up the line._
|
| Agreed wholeheartedly, but for slightly different reasons. To
| wit, laziness and Goodhart's law. [0]
|
| In the absence of infinite time, automation will excuse a lack of
| manager curiosity, as other competing tasks absorb the freed
| time.
|
| Consequently, most managers with automated dashboards showing
| performance metrics won't use those dashboards... plus all the
| person-to-person work they were previously doing. They'll only
| use those dashboards.
|
| Which then slowly but inexorably turns your employees into
| dashboard-optimization drones via operant conditioning.
|
| Helping a colleague doesn't show up on the dashboards? Fuck that.
| Digging into what looks like a security vulnerability isn't on
| the sprint board? Fuck that.
|
| Which is incredibly corrosive to quality, creative system design.
|
| And then, because this is the work reality you've created, the
| creative folks you really want working there bail for greener
| pastures, and you're left with bottom of the barrel talent and
| retention problems.
|
| [0] https://en.m.wikipedia.org/wiki/Goodhart's_law
| bigiain wrote:
| > Helping a colleague doesn't show up on the dashboards? Fuck
| that. Digging into what looks like a security vulnerability
| isn't on the sprint board? Fuck that.
|
| Managers who are the sort of people who don't value helping
| your colleagues or being curious/concerned enough about
| potential security problems, are most likely the sort of people
| who won't pick up on any of that being a valuable use of your
| time during one on ones or in standups either.
|
| I think fundamentally you agree 100% with Rachel, shit managers
| are shit and nobody owes them tooling to make their job of
| being a shit manager easier.
|
| If you want all the employee loyalty and long tenure
| institutional knowledge of a micro managed call centre, sure -
| implement checkin and LOC dashboards, or Jira ticket "velocity"
| charts. Watch all your talented people leave and don';t be
| surprised when everybody is only there because they're
| desperate or comfortable. Your entire dev team will eventually
| be only working-visa-prisoners, talentless-seatwarmers, or
| people who've dialled the give-a-shit down so low it doesn't
| bother them just picking up their pay checks.
| chipdart wrote:
| > Managers who are the sort of people who don't value helping
| your colleagues or being curious/concerned enough about
| potential security problems, are most likely the sort of
| people who won't pick up on any of that being a valuable use
| of your time during one on ones or in standups either.
|
| This is not a "sort of people" problem. This is a metrics
| problem.
|
| It's not only developers who are evaluated by using useless
| metrics that don't track the value you add to an
| organization. Low-level managers are too.
|
| Low-level managers need to evaluate the people assigned to
| them, they need to evaluate them objectively, and they need
| to give an unbiased and objectively verifiable score. This
| means something they can measure, such as metrics or
| verifiable goals.
|
| If low-level managers cannot do this, they will need to
| answer why they gave X and Y this score whereas poor little Z
| who outworked them both was scored lower. Not being able to
| objectively justify a score is a problem that no manager
| wants to have, as this is a major liability.
|
| Hence the bullshit metrics and absurd goals. They need
| something on paper to back up their decisions. A manager
| might be fully aware that you unblocked half your team
| members throughout the year with critical help, and that you
| are the go-to guy to solve critical issues. But if your team
| members close twice the tickets you did, they will have
| trouble justifying you are contributing as much as them.
| gradstudent wrote:
| > 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.
| Arainach wrote:
| Unfortunately, a lot of things boil down to metrics, even
| at companies with great engineering cultures.
|
| If you have four L4 engineers on the team, all of whom
| are performing at the level described in the career
| profile as L5, but only budget to promote two of them,
| how do you pick which two? What if they have different
| managers, all of whom sincerely believe their report is
| the one delivering essential value?
|
| If you have an organization with forced bucketing where
| X% of your team need to be given a subpar rating, how do
| you decide which one? If you don't have an obvious low
| performer you'd better have metrics.
|
| This system is soul crushing but it exists all over the
| industry.
| alextingle wrote:
| > If you have an organization with forced bucketing where
| X% of your team need to be given a subpar rating, how do
| you decide which one?
|
| Easy. You quit, and find a better job.
|
| That practice is so toxic that it's sufficient to condemn
| the organisation as unworthy of any buy-in whatsoever.
| Just leave.
| jart wrote:
| Nah you make sure X% of your team is staffed with losers.
| It's a nutty system I know. But I'd imagine that's how
| things worked at companies that have stack ratings.
| Managers probably traded low performers like baseball
| cards.
| ethbr1 wrote:
| In defense of stack ranking, it does solve a very common
| problem -- managers who never fire people who deserve to
| be let go.
|
| This ultimately rots an organization from the inside, as
| it leads to attrition of higher performers because
| they're forced to work with useless people.
|
| You see this a lot in companies that rarely fire people,
| because managers optimize for accumulating direct report
| count (whether or not those direct reports are doing
| valuable work).
| convolvatron wrote:
| companies need to do much better about letting managers
| go. I get it, they are hard to find. and those that
| actually have any engineering management skill at all are
| even harder to find. and every time you hire a new one
| you're taking a risk that they'll be a absolutely
| terrible manager. a terrible manager can cause a huge
| swath of destruction.
|
| but the answer can't be an army of useless middle
| managers diluting the impact of the people who actually
| do want to help the company and providing cover for
| people like them that are just phoning it it.
| ethbr1 wrote:
| Absolutely. I'd like to see companies get more serious
| about driving manager requirement from span of control.
|
| As well as regularly rotating managers, like the military
| does (e.g. 3 year reassignment).
| marcosdumay wrote:
| > This ultimately rots an organization from the inside
|
| Hum... So instead you decide to immediately rot the
| organization from the inside.
|
| I can see how it avoids that one problem. The important
| problem is the waiting, right?
| gradstudent wrote:
| > how do you pick which two?
|
| You (=hypothetical manager, please excuse second-person
| tense) use your managerial skills to make a decision,
| which considers metrics and other contributing factors.
| Then you write a justification which you defend, to
| higher ups and to those who weren't promoted. Because
| that's your job.
| eesmith wrote:
| Yes, the Nuremberg defense - "I was just following
| orders" - is one approach.
|
| It's a lot easier than applying back pressure, fighting
| for your reports, or quitting in solidarity.
|
| "Sorry, Hugo and Maryna, you two only got the Fields
| medal while Anton and Alain got a Nobel Prize, so we'll
| have to let you go for your under-performance."
| Arainach wrote:
| Here's how this works in practice:
|
| * Corporate says "here are the buckets. They should match
| at the VP level since that's a large pile of people"
|
| * VPs tell their Directors to match these buckets, who
| recurse further
|
| * L1/2 Manager Alice says "my team is too small, this
| isn't how statistics work, I want an exception"
| * Problem #1: the teams with actual low performers will
| often make similar claims
|
| * If the claim actually gets escalated all the way to the
| VP, the VP says "tough, fit the buckets".
|
| * Alice is now a troublemaker in VP/Director's eyes
|
| * If Alice and everyone who feels the same way quits in
| protest, nothing changes except that the org is full of
| yes men, none of whom are even trying to push for changes
| in the system any more.
| eesmith wrote:
| So it's better that Alice stays because ... why?
| Arainach wrote:
| Because Alice is a good manager who cares about their
| reports and is otherwise supporting them, advocating for
| them, pushing for changes to team culture, etc.?
|
| The fact that they can't control this one thing does not
| mean that they should just abandon the whole company. If
| Alice finds a company where they can get similar
| compensation for similar workload without the forced
| bucketing, perhaps that's a good idea for their mental
| health, but Alice leaving is a large negative for the
| team.
| eesmith wrote:
| I wrote 'applying back pressure, fighting for your
| reports, or quitting in solidarity'. Alice leaving was
| the third of these.
|
| 'advocating for them' and 'pushing for changes' are parts
| of the first two.
|
| When back pressure and fighting for your reports does not
| work, what do you do then?
|
| As you wrote it, Alice leaving is a large negative for
| the company to, making it full of yes men, unable to
| change away from a collision course.
| marcosdumay wrote:
| Nah, it's better on the long term if she goes work
| somewhere better.
|
| But changing jobs doesn't happen immediately, and
| "somewhere better" may be very hard to find.
| jjav wrote:
| > Then you write a justification which you defend, to
| higher ups and to those who weren't promoted.
|
| What happens next is this manager gets a low performance
| rating themselves, for making decisions not backed by
| metrics. So next year they conform.
| ryandrake wrote:
| This "don't make a decision unless it is 100% derived
| from metrics" mentality I just don't get. A robot could
| do that. Why is your company out there trying to
| hire/promote smart managers with good judgment if they
| don't let those managers apply their brains and judgment?
| "If employee's measured results > threshold, then reward
| employee" can be done by a computer. No need for a human
| manager.
| marcosdumay wrote:
| People create process because of the principal agent
| problem.
|
| The upper managers do that because they think the lower
| ones are lying or incompetent. A traceable process
| doesn't lie.
|
| And yeah, it's stupid, and it makes the problem worse.
| It's the reason nonetheless.
| kaashif wrote:
| > If you have an organization with forced bucketing where
| X% of your team need to be given a subpar rating, how do
| you decide which one? If you don't have an obvious low
| performer you'd better have metrics.
|
| This is a case where you're forced to rate people who are
| up to par as subpar - the rating system is simply
| bullshit. You should be allowed to rate people according
| to their actual performance.
|
| Metrics don't solve the underlying problem which is that
| the rating system sucks. Having a random number generator
| called "metrics" to "make decisions" isn't good either.
| BeFlatXIII wrote:
| Dice.
| red_admiral wrote:
| > If you have an organization with forced bucketing where
| X% of your team need to be given a subpar rating, how do
| you decide which one?
|
| I think it's Joel Spolsky who has a tale of a manager
| asking him to do that for his team when everyone had gone
| all in with overtime to get something shipped on time. To
| their great credit, the author refused, and the manager
| saw sense.
| Yizahi wrote:
| Pfff, what kind of problem question is that. Manager
| promotes the ones who go with him for a smoke or do some
| other regular informal activity together, obviously. :)
| csa wrote:
| > If you have an organization with forced bucketing where
| X% of your team need to be given a subpar rating, how do
| you decide which one? If you don't have an obvious low
| performer you'd better have metrics.
|
| If you're a manager in this type of system, your job is
| to reach out _constantly_ and find folks who are low
| performers and get them into your department. They will
| fill the bottom of your team rating chart. At that point,
| they can be managed out (ideally in a humane way) or just
| held onto to fill that cellar dweller role while not
| slowing others down (some people are ok with this as long
| as they get paid).
|
| I would never choose to work in an environment like that,
| but some people find themselves there without better
| options (e.g., being location-bound due to family, etc.).
| throwaway2037 wrote:
| Wow, I never saw this type of advice before, but I like
| it. In short: If you are required to do stack ranking,
| where at least one person must get a shitty score/grade,
| then recruit someone internally who is below average and
| will take the hit. Brutal, but practical.
| ryandrake wrote:
| Or externally! I posted an idea here a while ago, where I
| thought I'd start a staffing company called "Scapegoat
| Consultants" and we would offer your team a "low
| performer" that you could hire and then fire after a
| year, to protect the rest of your team from stack-
| ranking. Our consultant will join your team and do as
| little as you want, or even nothing at all! We'd
| guarantee that they will at least not actively make your
| code base worse, but that's it. After a year of this, you
| can easily make the case that our recruit was a low-
| performer and manage them out. Don't worry, he won't mind
| --his job was to be the low performer, and we'll hire him
| out to the next BigTech company who struggles with stack
| ranking.
|
| It used to be tongue in cheek, but maybe the industry
| actually needs something like this.
| Calamitous wrote:
| Cynical, but probably the most humane take I've seen here
| so far.
| marcosdumay wrote:
| That's the standard strategy to survive stack ranking.
|
| Have you heard any story by someone that was hired into
| some megacorp just to be sent into a PIP or fired by low
| performance before they had any chance to even do
| anything? Stack ranking is the most common reason those
| happen.
| bolasanibk wrote:
| "Hire to fire". Not a new idea. I have been hearing it
| for at least 5 years now.
| passwordoops wrote:
| >the situation you describe is a classic sign of a shit
| manager
|
| Well then it means the vast, vast, _vast_ majority of
| companies with a coherent corporate structure are shit.
| Welcome to reality
| red_admiral wrote:
| I've had experience with internal "support" that marks
| tickets as closed without actually fixing the problem.
| Sometimes the reason for closing suggests they haven't
| even read the email that opened the ticket.
|
| Think something like "Tool $X is missing on machine $Y.
| Please can you install it, according to $POLICY it is
| meant to be on all prod machines." Then the ticket gets
| closed with "The policy is correct. $X must be on all
| prod machines, we cannot change this." Without installing
| the tool.
|
| Then when the annual anonymous "rate your satisfaction
| with these services" survey came round, they wondered why
| the ratings were so bad - I made sure in the open text
| feedback not to go after the poor employee but to raise
| concerns about the performance of the team manager. I
| won't take credit for it, but I'm told things at $COMPANY
| have got better since.
| dogleash wrote:
| > a shit manager
|
| This isn't about a singular individual, it's about a
| group of professionals. You have to deploy systems
| thinking. If you give a cohort a tool that allows and
| incentives them to do worse at their job, the average
| person in that group will perform worse.
|
| I like my boss; I have also built a skillset and
| frugalness where I don't worry about working for someone
| I don't respect ever again. _But I still care about what
| 's going on at large and trends._ I don't want downward
| pressure on the average. Not only will that slowly seep
| into effecting me, I also care about the lives of the
| people at points in their career where they don't have
| employment opportunities that allow them to avoid bad
| management.
| chipdart wrote:
| > The metrics make reporting to higher ups easier, no
| doubt.
|
| It's not about being "easy". It's about being objective,
| verifiable, and demonstratably unbiased. It's about
| justifying how you rank the performance in a way that's
| impossible to refute.
|
| > But the situation you describe is a classic sign of a
| shit manager:
|
| It's not, and frankly this "shit manager" accusation is
| an infantile remark that screams a failure to understand
| what it means to perform well.
| BlueTemplar wrote:
| It becomes an interesting contradiction : there's no such
| thing as a good unbiased and objective metric on this.
|
| So good managers (that do their job properly) are bad
| managers (that get fired for it).
|
| And bad managers are good managers...
| pxc wrote:
| Recent-ishly on HN: https://yosefk.com/blog/advantages-
| of-incompetent-management...
| Brian_K_White wrote:
| A manager can absolutely describe any value as simply as
| you just did.
| jimberlage wrote:
| One thing that is always on the table - if you see a person
| picking up valuable work and they don't have a ticket for
| it - you as a manager can create that ticket.
|
| Now you may need to coach the person on how to do that
| themselves (can we make the ticket making process more
| lightweight? Can we make a heuristic like just put story
| points for the time you've already spent on it plus a
| buffer for after-the-fact work?)
|
| But managers who really want documentation and truly think
| people are doing underappreciated work can always make it
| themselves.
| Simon_ORourke wrote:
| > Managers who are the sort of people who don't value helping
| your colleagues
|
| Helping, yes certainly one of the core requirements being a
| manager is unblocking direct reports from whatever they're
| doing.
|
| But it has limits, because you as a manager have finite time.
| I've got seven direct reports, three are relatively new hires
| and so consume most of my "help". Of the remainder another
| three are great senior devs who can be trusted with getting
| the broad brush strokes of a problem and going off
| independently to delve in.
|
| One however, a struggling senior dev with junior dev
| capabilities, and having major childcare issues at home is
| totally floundering, pulling sick days and basically failing.
| As a manager I basically don't have capacity to commit the
| amount of time required to pull them out of it, and I'm
| trying to move them off the team.
| alextingle wrote:
| Have you talked to your "failing" team member about this?
| Have you worked together to try and identify a path towards
| improvement? Off the top of my head, perhaps they would
| benefit from more WFH time? Or perhaps a period of part-
| time work? Perhaps their duties could be shifted around so
| that they can contribute in a different way for a while?
| Could they take over some of your mentoring duties?
|
| I mean, this is the bread and butter of your job as a
| manager, right? Getting the best out of your people?
| cutemonster wrote:
| > Could they take over some of your mentoring duties?
|
| They wrote that the person has _junior_ skills.
|
| > so that they can contribute in a different way for a
| while?
|
| Seems to me that this is what they're doing already:
|
| >> I'm trying to move them off the team.
|
| (To another team where the person fits better,
| presumably.)
| Brian_K_White wrote:
| I don't read it so charitably. They only see a problem
| they want to go away. How do I know what they see?
| Because that is what they said.
| bryanrasmussen wrote:
| whatever else, that major childcare issues comment right
| there should tell anyone "don't work at that company,
| because hey your child gets cancer they don't care and will
| try to figure out a way to fire you. Probably by saying you
| have 'junior dev capabilities'"
| lazide wrote:
| That's nice and all, but what else do you expect to
| actually happen?
| bryanrasmussen wrote:
| if someone is underperforming due to those kinds of
| problems then to say they have junior dev abilities seems
| somewhat insulting, which is especially contemptible
| because it is wrong to insult someone that is going
| through an especially difficult time, especially as the
| person doing the insulting might not be able to handle
| the situation any better themselves.
|
| So first off I expect not to insult people in that case.
|
| Then I might expect something like "unfortunately due to
| the extreme medical situation the family finds themselves
| in I do not feel this person can fulfill their duties at
| the company any longer, and will need to be let,
| following company policy / legal requirements in our area
| that means the following rights pertain ...."
|
| that is to say instead of moving them out by saying they
| have junior dev capabilities and are just failing, acting
| honorably in the firing process and taking whatever hit
| the company is supposed to take.
|
| In other words I expect the company to pursue its
| benefit, but honorably and not as a scumbag. Your "what
| else do you expect to actually happen" suggests that you
| think it is likely the company will be a scumbag, your
| "that's nice and all" seems to imply that you think being
| a scumbag is not just likely but somehow also correct.
|
| on edit: referring to the legal rights and
| responsibilities of company may also in some cases be
| that the employee has rights to paid leave and similar
| things. So it does not necessarily mean that someone will
| be fired, depending on where this situation is taking
| place.
| dasil003 wrote:
| This is why if you're telling someone something they
| don't want to hear it's best to only give one reason.
|
| Senior dev overleveled and performing at junior level is
| one thing. Personal issues impacting performance is
| another. They have totally different solutions and just
| mentioning them together sounds like the manager has an
| axe to grind.
| bryanrasmussen wrote:
| it may be true that these have different causes in a
| particular situation, but given the variability and
| length of employment in most companies and projects for
| everyone involved (managers and programmers) I would
| think it more likely that a manager wouldn't actually
| have enough data to reliably separate the two conditions
| when dealing with it.
| ethbr1 wrote:
| Something similar came up in another HN comment thread I
| was in a few months ago -- someone hired at senior level,
| but ended up only having junior level skills.
|
| The root issue, imho, is there's no accepted corporate
| method of demoting an employee (in the US).
|
| Which is unfortunate, because it would benefit both the
| company (who retains someone with training and
| familiarity) and the employee (who isn't fired).
|
| "Lower expectations for lower money" shouldn't be
| verboten, but it is.
| vdvsvwvwvwvwv wrote:
| You can give your team members more responsibility. Tech
| leads, buddies, owners of initiatibmves etc. are things.
| The juniors shouldn't be sucking too much at just your
| teet.
| doodaddy wrote:
| Based on what you've said, are you confident that you're
| delegating enough? I mean, you kind of answered your own
| questions - you've got three seniors. Are they really
| senior or senior-in-title? If really senior then they
| should be helping take on some of the junior mentoring.
|
| Be wary of the hero, "only I can do it", mentality as a
| manager. It only leads to burnout.
| senkora wrote:
| Not to be antagonistic, but just as a practical matter to
| consider: if your account username is your real name then I
| would be careful talking about your direct reports like
| this. People who you work with might see it.
| agentultra wrote:
| > people who've dialled the give-a-shit down so low
|
| In the age of stock buy-backs, cyclical lay-offs, and record-
| high executive compensation I sympathize with these folks. It
| might even be morally correct thing to do.
| Jcampuzano2 wrote:
| As someone who's company has gone through the constant
| cycle of layoffs including one that happened just a few
| weeks ago, I'm at this point now and I have no qualms of
| all the other people who are also here at this moment.
|
| I get exactly what is asked of me to do and nothing more,
| no longer respond to things outside of work hours and
| collect my paychecks. I still enjoy learning new tech and
| whatever the next thing is, but my interest in applying
| myself to my day job is at an all time low.
|
| Oh forgot to mention our execs bonuses and stock went up
| despite everyone hating it here now.
| alsetmusic wrote:
| > I still enjoy learning new tech and whatever the next
| thing is, but my interest in applying myself to my day
| job is at an all time low.
|
| I'd say you're relatively lucky. I found it soul-crushing
| when my work changed from something in which I took pride
| to something where I just wanted to coast and no longer
| cared. Management sucked and I was depressed at my lot in
| life. I didn't have much energy to look for and apply to
| other positions.
|
| Layoffs came twice and getting let go was the biggest
| favor they could have done for me.
|
| My next (current) job is rewarding, and I'm again having
| fun learning new things in my downtime instead of vegging
| out on streaming content after work.
| gtirloni wrote:
| I don't. All you mentioned have zero impact on my daily
| work. I could as well say that in the age of Tiktokers
| earning millions, why should I care about my work?
|
| I care about my work because it's my work and I don't want
| to just collect paychecks. If you're not happy and can
| leave, just leave. Go do something productive with your
| life that makes you proud of. Life is too short to play by
| others' rules.
| Jcampuzano2 wrote:
| Its a hard pill to swallow but I just want to point out
| that if you look around you at most jobs, including
| highly paid tech jobs - most people do not care about the
| job itself apart from the fact that it compensates them
| well - whether that be with salary or with time/benefits.
|
| And not everyone simply has the choice to just find
| another job when they are unhappy. I know you caveated
| that with the "if you can" but I'd say the vast majority
| of people can't.
|
| That and the fact that most peoples work is not actually
| theirs as you say. Everything you do is part of the
| company, and managers/execs take credit for the work all
| the time at many companies.
| enraged_camel wrote:
| >> All you mentioned have zero impact on my daily work.
|
| Are you sure? My GF's company went through two rounds of
| layoffs this year and she now has such a heavy workload
| that she works most evenings and some weekends as well,
| and her stress level has gone through the roof.
| effingwewt wrote:
| This is happening to me in the trades.
|
| Im in maintenance as an industrial electrician.
|
| New plants came to town paying current market rate and
| snagged most of the top talent.
|
| Then the company started quiet-firing to avoid layoffs.
| It killed all motivation.
|
| Then they froze hiring as we kept losing people. We are
| now short on HVAC, mechanics, and electricians.
|
| Lucky me I'm the only guy who can do all three so im
| running ragged all day.
|
| We have response times we have to meet but our vehicle
| (an electric GEM) had the charger die, it's only $2k but
| they won't let me order it so we all walk everywhere.
| Huge plant I easily bust 30k+ steps and 20+ stories
| climbed via stairs.
|
| We then had a mechanic and an electrician take paternity
| leave so we are even more shorthanded. Still wont let us
| hire.
|
| We lost the maintenance manager and cant get another one
| for what we pay and the condition the business is in now.
|
| I love my job andy co-workers but I'm sending out resumes
| and interviewing because I can't take all the extra
| workload with no extra pay while our administration keeps
| getting more money and bonuses.
|
| How do companies keep making the same mistakes over and
| over expecting different results? They don't, they know
| what's going on and are getting theirs before the bottom
| falls out.
| ninininino wrote:
| If your company:
|
| * needs HVAC, mechanics, and electricians to function and
| deliver revenue
|
| * your company cannot afford to hire new people, only
| maintain their current payroll, or are unwilling to raise
| wages to be able to hire more (not enough talent)
|
| * you are able to do all three, but are being asked to do
| more than want or are able to do
|
| then there's a simple outcome that to me it seems like
| you're missing.
|
| you can just say "I can't", or "no, I'm going home at 6"
| or "cool, that's a great plan but I only have time to do
| the first half of the tasks you just described today",
| and most importantly - your company simply won't be able
| to afford to do anything about it.
|
| What are they gonna do? Fire you and be even more fucked?
| Seems like if you set firmer boundaries on how much you
| can work, their best decision is going to just be
| accepting it. Because their only alternative is to even
| stupider which would be to fire you and have no work get
| done at all.
| effingwewt wrote:
| Not really. I just came off night shift and was thrown
| right back on it. We work 12 hour shifts, they alternate
| between forced overtime and disallowed overtime at their
| whims.
|
| When I brought up I have yet to get my float (4x10s
| considered the 'easy' shift) I was told there was nothing
| they could do. All I could think was well how will you
| handle it when I leave?
|
| Management really is that dense.
|
| They care not one whit about objections nor people
| leaving.
|
| Imho it's merely a matter of time but the younger guys
| all hold out hope. I've none left.
| nothercastle wrote:
| Many Manufacturing managers hate people and just treat
| them as an expense to be exploited.
| tivert wrote:
| > All I could think was well how will you handle it when
| I leave?
|
| You mentioned upthread:
|
| > New plants came to town paying current market rate and
| snagged most of the top talent.
|
| You should totally get a job at one of those plants and
| let them hang.
| ethbr1 wrote:
| Given how common this is with layoffs, it feels like
| backpressure is needed.
|
| Specifically: task shedding when they exceed available
| hours
|
| If you're the last one keeping the lights on for a 4
| person team, it seems reasonable to let some lower
| priority things go undone and communicate to your boss
| that "You don't have time for that."
|
| Trying to ratrace to keep up with an unreasonable amount
| of work is just rewarding a company for overworking you,
| by avoiding sending it the hard signal of "too much
| work."
| agentultra wrote:
| Fulfilling your obligations under the terms of your
| employment contract doesn't mean you don't care about
| your work and aren't acting professionally.
|
| For a lot of people work isn't a passion project, it's
| literally the only way to have a roof over your head and
| food on your table. If you happen to enjoy it that's a
| bonus and not a requirement.
| nuancebydefault wrote:
| I can't imagine doing a job without having some passion
| around it. If that were true, i would be ticking of
| checkboxes in the form of executed jira tickets purely
| created by others, or fulfilling requirements set by
| others. I'm sure it would wear me out.
|
| > If you happen to enjoy it that's a bonus and not a
| requirement.
|
| I know a few people for who this used to be true. One of
| them got laid off and went back studying, the other
| changed jobs but is still ill half of the days.
|
| My point being, passionless job is not a sustainable
| thing.
| yfw wrote:
| Then you lack imagination and empathy for those with less
| opportunity
| agentultra wrote:
| I think it depends on the kind of person you are. I've
| met some pretty reliable folks for whom their day job was
| just a job and it didn't matter if they were being paid
| to program web applications for processing tax returns or
| batch processing reports. They were much more passionate
| about collecting accordions or attending their kids'
| hockey games.
|
| They did not give one f for, "the company," but they were
| steady and reliable co-workers.
|
| I've also worked with passionate "try hards," that will
| get upset if they're not using the latest-and-greatest
| languages and tools. They'd throw tantrums over
| architectural decisions. And if they didn't settle down
| they'd move on to the next job in a year. Hope they found
| what they were looking for.
| gtirloni wrote:
| In a single comment you mixed:
|
| * Professional reliability
|
| * People who don't care about what type of job they do
|
| * Hobbies
|
| * Parenting
|
| * People who don't care about the company, but cared
| about their job
|
| * Tryhards
|
| * People chasing the latest fad
|
| * People that have opinions about software architecture
|
| * Job hoppers
|
| My initial comment was about people caring about THEIR
| work, not the company or anything else. It was about
| people not doing something they dreaded for >8h straight
| and thinking that's what life has for them.
| gtirloni wrote:
| Please re-read the comment I was replying to and see if
| it was about "fulfilling your obligations under the terms
| of your employment contract".
|
| I think you're hijacking this thread to make your point
| regardless if its related or not to it.
| haswell wrote:
| Even if my employer doesn't deserve my dedication, it's the
| end-user impact and personal cost of not giving a shit that
| concerns me.
|
| People building software are often in a position to
| directly impact significant numbers of people: not giving a
| shit leads to severe software vulnerabilities, data leaks
| leading to identity theft, compromised systems, etc. Real
| disruption to the lives of normal people.
|
| And actively not giving a shit gradually changes the person
| doing so. I've seen this mindset become corrosive and has
| changed people who I previously respected in ways that I
| really don't think could be beneficial or "good" regardless
| of what the company does or does not deserve.
|
| Not giving a shit is why our industry is increasingly under
| scrutiny by regulators - for good reason.
|
| I question a moral calculus that only accounts for the
| problematic business practices of an employer while
| ignoring the many potential downstream impacts that are
| unrelated to those practices.
|
| There's a needle to thread in terms of how one handles
| their emotional state while working and finding a healthy
| balance between doing good work and not dedicating one's
| life to their employer (which I'm not advocating btw). But
| I'm increasingly skeptical of the idgaf mindset and
| frustrated by people who don't take seriously the
| privileged position they're in and the world changing
| impact of the work they do.
|
| The only truly moral option in many cases may be to quit
| (if the alternative is not giving a shit). But people
| want/need that paycheck.
| zrail wrote:
| > people want that paycheck
|
| In most cases people _need_ that paycheck. You can talk
| about morality all you want if you have the privilege to
| not need a paycheck, but you can't know everything about
| everyone's lives. You mostly only ever know about the
| choice someone else makes. You hardly ever know what
| options they had to choose from or the tradeoffs they
| need to think about.
| haswell wrote:
| That's completely fair, and I slightly edited my comment
| to include the word need, because I strongly believe what
| I said applies to both dynamics.
| walls wrote:
| > not giving a shit leads to severe software
| vulnerabilities, data leaks leading to identity theft,
| compromised systems, etc. Real disruption to the lives of
| normal people.
|
| None of this affects me. The only way to make an employee
| care about this kind of thing is to pay them, and treat
| them, well enough to care.
|
| You also need enough free time to care, which isn't
| nearly as common now that every team at every company is
| running on a skeleton crew.
| haswell wrote:
| > _None of this affects me_
|
| Frankly, that's a huge problem.
|
| > _The only way to make an employee care about this kind
| of thing is to pay them, and treat them, well enough to
| care._
|
| The workforce is absolutely full of people who value
| their work and its impact on other people above all else
| regardless of how poorly they're paid or treated. This is
| not an endorsement or acceptance of the status quo, but a
| recognition of the importance of one's actions.
|
| If you're a teacher, bus driver, emergency responder,
| nurse, transit operator, power/gas workers etc. you're
| most likely not getting paid much or nearly enough, but
| would never dream of bringing this "idgaf, pay me"
| attitude to work.
|
| I suspect it's because software is so abstract and the
| people building it are so far removed from its impact,
| but our industry seems uniquely disconnected, complacent,
| and entitled when discussing the impact of an
| individual's actions.
| walls wrote:
| > The workforce is absolutely full of people who value
| their work and its impact on other people above all else
| regardless of how poorly they're paid or treated.
|
| They're called juniors, and haven't yet been broken by
| the system.
|
| > If you're a teacher, bus driver, emergency responder,
| nurse, transit operator, power/gas workers etc. you're
| most likely not getting paid much or nearly enough, but
| would never dream of bringing this "idgaf, pay me"
| attitude to work.
|
| Have you seen the state of these professions? That's the
| prevailing attitude at the moment, and the reasons are
| obvious.
| haswell wrote:
| > _They 're called juniors_
|
| I'm 20 years into this, not a junior. And the people I'm
| talking about certainly aren't juniors.
|
| I'm not questioning the existence of people who stop
| caring. I'm saying that this is a choice, and one that
| many people can't bring themselves to make.
|
| > _That 's the prevailing attitude at the moment_
|
| Attitudes and actions are two different things. If people
| in many of those professions were acting like many do in
| the tech world, people die as a result.
|
| I'd be careful not to project your own view of this
| matter on the broader workforce.
| rightbyte wrote:
| > And actively not giving a shit gradually changes the
| person doing so. I've seen this mindset become corrosive
| and has changed people who I previously respected in ways
| that I really don't think could be beneficial or "good"
| regardless of what the company does or does not deserve.
|
| Ye turning into a cynic is not nice. You can rationalize
| all you want but the corp is eating your soul, more or
| less.
|
| A problem I observed is when cynics from bad places move
| to hardly OK places, and overestimate the amount of
| badness. People that think the corporation is rotten
| seems easier to make do rotten things, while others that
| "don't get it" might protest.
| idunnoman1222 wrote:
| The subset of software that I can't opt out of is small.
|
| Not that the regulators are competent... but for opt in
| software it's user beware
| alistairSH wrote:
| _not giving a shit leads to severe software
| vulnerabilities, data leaks leading to identity theft,
| compromised systems, etc. Real disruption to the lives of
| normal people._
|
| Meh, I'd question how much that is actually true.
| Generally, when people talk about "not giving a shit",
| it's not literally about half-assing everything. Instead,
| it's about only doing what you have capacity to do while
| balancing work with the rest of life....
|
| Boss give's you 60 hours worth of info-sec tasks to
| complete this week.
|
| You have a social engagement Friday night through Sunday
| (siblings wedding, and you put it on the on-call calendar
| months ago).
|
| You remind boss "I can do 2/3 of that list, the rest
| needs to go to someone else, because 5pm Friday, I'm
| offline for the weekend".
|
| You do the 40 hours worth of stuff, do it properly, and
| go to the wedding.
|
| If your boss drops the ball, that's his problem. You did
| everything properly. Working through your sibling's
| wedding only justified your boss's under-resourcing of
| work.
| tivert wrote:
| > In the age of stock buy-backs, cyclical lay-offs, and
| record-high executive compensation I sympathize with these
| folks. It might even be morally correct thing to do.
|
| Under capitalist and corporate morals, it's a sin for a
| worker to fail to give the best part of his efforts to the
| shareholders.
| astrange wrote:
| Stock buybacks are good if you're paid in employer stock
| like tech companies are.
|
| Aside from that, they're value neutral to the company.
| They're not spending money, any more than you buying stocks
| is.
| ricardobeat wrote:
| That money could be spent on R&D, other investments or
| better compensating underpaid people who made that profit
| possible in the first place. Framing it as "no money
| spent" is disingenuous.
|
| At a previous job we got lower bonuses than the year
| before, after a successful product launch, while the
| company spent something like $8B in buybacks - and no,
| common stock didn't rise in value to any meaningful
| degree.
| nisegami wrote:
| >Managers who are the sort of people who don't value helping
| your colleagues or being curious/concerned enough about
| potential security problems, are most likely the sort of
| people who won't pick up on any of that being a valuable use
| of your time during one on ones or in standups either.
|
| I think in a lot of cases these managers do value those
| things, but the fundamental issue is that those things aren't
| reflected on the dashboard.
| FireBeyond wrote:
| 100%.
|
| At my last org, my eng team (I'm a PM) had no manager for a
| while, during which leadership instituted metrics that
| tracked "Planned Points versus Planned Points achieved". My
| team also handled support escalations and defects. That work
| is ... unplanned. That was not tracked in their system.
|
| I had to go in and advocate for them... "You have work that
| they are being _required_ to do that not only doesn 't show
| up on metrics that you are using to evaluate developer
| productivity, but in fact, you're actually dinging them by
| flagging that 'planned versus completed points' as
| unacceptably low. How do you think morale is going?"
|
| They would do things like "The team planned 30 points to be
| completed in this sprint. They only completed 10 points, 33%,
| and we expect 90%. Oh? What's that, they actually also
| completed 25 points in unplanned work due to Sev-0 and -1
| bugs and defects? That doesn't count."
| yesiamyourdad wrote:
| Yet the author wrote tools to do that. Part of what I thought
| from looking at these dashboards is that the author by their
| own admission[1] arbitrarily doubly prioritized customer
| communications over internal discussion and gave credit for
| doing things in the ticketing system when presumably none of
| the actual work takes place in the ticketing system.
|
| I know those events were over a decade ago and I appreciate
| the author's willingness to reexamine their beliefs, but
| that's what's meant by second-order thinking. What I got from
| reading a few of their writings is that this is a person I
| probably would avoid interacting with.
|
| [1] https://rachelbythebay.com/w/2011/11/16/onfire/
| seb1204 wrote:
| I would argue that a managers time will be filled no matter
| what she does. So she could prioritise knowing what her peers
| do, and acquire the basic knowledge to understand tech maybe?
| And then fill up the rest of the calendar.
|
| So I'm saying it is up to the manager to either suck upwards or
| support peers.
| seb1204 wrote:
| Stupid question but when digging into a potential security
| vulnerability, should that not be a ticket already that can get
| tracked?
| p1esk wrote:
| Of course. Same as helping a colleague (unless it's a few
| minute task). Whenever there's something that I can spend my
| time on, it's going to be converted into a ticket.
| jachee wrote:
| How do you prevent that from recursing infinitely?
| happymellon wrote:
| If you are measuring tickets, then you can't.
|
| Your job is to create tickets to close them. If you
| generate productivity along side that, then thats a
| bonus.
| djtango wrote:
| Because we're humans, not robots and a human manager with
| human managees should be capable of working within a
| process without abusing the most obvious of edge cases.
|
| When building software you have to be precise to the nth
| degree but with human processes you can afford some
| degree of ambiguity and judgment...
| exe34 wrote:
| you create tickets for helping colleagues? I would
| understand "add this feature for me", but do you also have
| a ticket to "take x through this unfamiliar neighborhood of
| the codebase"?
| ryandrake wrote:
| I've seen tech companies that strongly encouraged that:
| Open a "task" or "process" ticket describing what you're
| doing, then do it, then close the ticket. Not all tickets
| are bugs and features. During review time, if you
| expended effort not described in a ticket, it's as if you
| never did it. When in doubt, open a ticket.
| exe34 wrote:
| that makes sense. I hate Jira enough though I don't
| really like cluttering it.
| madeofpalk wrote:
| Why?
|
| "Tickets" are a means to an end, but not the end itself. If
| it helps you, create a ticket. Otherwise don't.
| 8n4vidtmkvmk wrote:
| If there's no ticket, how will anyone know you did anything
| at all? How will submit your code change without a ticket #
| to satisfy the validator?
| macNchz wrote:
| I read this something like:
|
| I'm working on a feature, I notice something curious in some
| adjacent code that could maaaybe let someone bypass the
| UserAuthorizationAdapter with a carefully crafted request,
| but I'm not familiar enough with that code to say for sure.
|
| It'll take me at least half an hour to figure out whether
| it's a complete misunderstanding on my part (I'm pretty sure
| it is...but it might not be...) or a real issue worth raising
| as a security ticket. Even just pinging someone about it will
| break my flow. It seems, however, that 100% of the decision
| making about whether I have a job next quarter and how big of
| a raise I might get is made based on three metrics on a
| productivity dashboard my boss is obsessed with. Should I
| take the time to learn more about the
| UserAuthorizationAdapter, or just assume it's fine, finish my
| feature and move on to the next?
| 8n4vidtmkvmk wrote:
| That hits too close to home. Except for us it's all about
| OKRs. You get one or two tasks for the quarter, and
| anything that isn't working towards that be damned. Which
| basically translates to launch your [AI] feature and fix
| nothing.
| ethbr1 wrote:
| Actual example from my experience:
|
| Trying to figure out the correct AD groups/permissions I
| needed to use an internal web app to schedule patching for
| some servers I managed.
|
| After stepping through the app's js, I realized they were
| doing user group retrieval and validaton client-side (!!).
|
| Wrote a quick POC that patched their check and gave me
| admin permissions, then sent it and a description over to a
| friend on the internal app security team.
|
| Not my job, but apparently the service account backing that
| app had permissions to reschedule patches on _any_ internal
| server. (including f.ex. domain controllers)
|
| So probably something that it was worth having someone
| spend a couple hours figuring out and reporting, despite it
| not showing up in my OKRs.
| beAbU wrote:
| Based on my experience automated reporting dashboards start to
| cause damage where they are allowed to become visible by
| higher-ups in the org. A dashboard is immensely powerful for
| the immediate manager to know how their team is doing, identify
| problems and work with the members to resolve those problems.
| As with many things, the numbers on a dashboard must be read
| with context and the closer you are to that team, the better.
|
| The moment the dashboard is accessed by higher ups, several
| things happen: The devs become scrutinized by higher-ups that
| do not have all the context to make sense of the numbers, the
| manager is rendered ineffective because the knowledge and power
| they had while reporting to their superiors is taken away, and
| upper management will inevitably start caring about the numbers
| on the dashboard, and nothing else.
|
| There is a level of "managing upwards" that lazy direct
| managers struggle with, and they just pass on the reporting
| numbers as-is without really caring what this might result in.
| regularfry wrote:
| Yep. It's for exactly this reason that I've told potential
| vendors in the past that _not_ exposing, and preferably not
| gathering, individual contributor metrics was a hard
| requirement. I 'd rather have individual team leads or scrum
| masters have to gather their own stats than have people with
| disproportionate organisational leverage exposed to
| information they don't know they aren't qualified to
| interpret.
| touristtam wrote:
| It's about safe space. We're not just cogs in the machine. We
| exists as humans with our own sets of fluctuating of
| emotional and psychological states. Break that at your own
| peril.
| ethbr1 wrote:
| Excellent insight!
|
| Metrics are useful, but only with context. Any metrics
| reported at skip level by definition lack context: there's no
| ground-level engagement or time to dig into details. Ergo,
| the reported numbers are understood as the _only_ numbers.
|
| With the exact solution you offered! Use them, but only at
| the level in which additional context is available, then
| report up new numbers that allow for enriching / adjusting
| the base numbers.
| mirekrusin wrote:
| There is an interesting parallel with overfitting [0] which may
| mean solutions can also resemble each other.
|
| [0] https://news.ycombinator.com/item?id=41684082 (Too much
| efficiency makes everything worse (2022))
| DrBazza wrote:
| The most interesting thing during COVID was seeing the switch
| from in-office to remote, followed by a round of redundancies,
| and the redundancies were fascinating. It was full of people
| that when in-office seemed gave the impression of hard-working,
| largely by a combination of 'face time', and just talking to
| other employees, and not necessarily about work.
|
| >> [Why not build programmer performance measurement tooling?]
|
| I'm pretty sure there wasn't any employee monitoring software
| other than completion of Jira tickets within individual teams.
|
| The whole sneaky monitoring/measurement software is totally
| counter-productive, and counter-intuitive. If I'm in an office,
| no one is going to care if I read the docs or an ebook,
| possibly on my tablet, but if I'm remote and not jiggling my
| mouse every few seconds I'm slacking off.
| ryandrake wrote:
| > It was full of people that when in-office seemed gave the
| impression of hard-working, largely by a combination of 'face
| time', and just talking to other employees, and not
| necessarily about work.
|
| Hahah, we all know these people! They walk around the office,
| sometimes carrying a clipboard or stack of paper, initiating
| business-y conversations, always making sure they look very
| serious and busy, deliberately walking past the boss's office
| frequently so he can see them visibly DoingSeriousBusiness.
| When promotion time comes around, these social butterflies
| are always at the top of the list, because naive managers see
| them buzzing around everywhere, and they at least think they
| know that these guys are constantly doing work.
|
| These people were panicking during COVID and WFH. Their
| entire self-promotion vector disappeared overnight.
|
| Now that most companies have returned to in-person work,
| these hall-walkers are back and once again getting promoted
| based entirely on their presence and visibility.
| mihaaly wrote:
| I work now for a long history smaller organization that
| formalized management and organization in the past 4-5 or so
| years. I joined midway of this - looking my way out now - and
| the focus on unconnected details only was odd right from the
| beginning. I attributed this to me being new and can't see the
| whole picture, digged into discovering my immediate vicinity.
| But after a year seeing we are still being obsessed only about
| those plenty of items that fit into a sprint multiple times
| remained sick to me. I discovered several embarrasing mistake
| in design of approaches, interaction or implementation that
| made me scared: how this went through at all, and how it
| remained there for so many years? Is this used at all
| actually?! People should desert us not paying for such nonsense
| (shit, actually). Reported these mistakes in our issue tracking
| system and those fit into less than half of a sprint landed
| back on me sooner or later, almost all. Not those first being
| very serious, but those fit into the schedule (but mixed in
| seriousity at least, those being serious first). My takeaways:
|
| - Seriousness and functionality is not the primary concern,
| company management is!
|
| - Others (about 2 dozens of engineers) did not take the effort
| to report. I am not brighter than them, I was novice in that
| environment and codebase and the actual technology, also what I
| was reporting stands out on usage level only, no tecnological
| knowledge necessary.
|
| - Apparently problems are positioned proactively on blind spot
| to remain unrecognised. There must be a serious level of
| ignorance involved.
|
| The company lived through decades of difficulties, never had
| investors but built and run by the increasing number of
| enthusiastic loyal people. The company organization was non-
| existing compared to today's norms meeting contemptuous looks
| from today'n collaborative organizational ninjas. I am sure
| several of the problems stems in the casual running of the
| organization, but the reorganization is not helping but making
| things worse, preserving, leaving in. The reorganization made
| the company look much shinier though. It looks much improved.
|
| As I later learned the reorganization was needed for selling
| the company. The founders pushing retirement age and want to
| cash out. Even my employement was part of that show, fitting
| into making the company look similar to trendy ones clueless
| investors can find appealing based on the facade. We are agile
| in all sense, we are technologically advanced (AI feature is
| pushed in for the sake of it), our recruited HR professional is
| like all other, we are uniquely successful like all others, we
| are team, we care of employees a lot, we have workplace well-
| being taken the most seriously (just like everything else in
| HR), we are family in matching uniforms smiling happily into
| the camera in a team building excercise, and above all we have
| top notch marketing with thick flow of photographically
| illustrated success stories and dynamism.
|
| And practically our backlog does not contain serious bugs.
|
| For the matter of how users stay with us my running theory is
| that there is no better choice than this. Others are similar
| (also the lock-in effect to something they learned and invested
| in is there). I see complaints, I see angry complaints now
| despite me being disconnected from the client facing report
| system, I see their efforts for trying to make it work, finding
| workarounds of workarounds only reporting when the combination
| of workarounds collapse. They try to use it, they need
| something like this. I feel their efforts, this is what I am
| doing in increasing level with Windows, and the various
| software tools I use. Those look similar on the surface,
| increasingly so and it deteriorates as we speak.
| InfamousRece wrote:
| I used to work for a company that started using Gitprime to
| measure developer productivity. Gitprime would show a nice
| dashboard with stack ranked employees based on their git
| commits. Besides the obvious effect that it had on cooperation
| (you don't want to help another developer lest they go before
| you in the stack rank) it had also funny effect on the code we
| wrote. For example, replacing old code with new code was
| penalized as "code churn", so we had to write something like
| if (false) { // old code } // new code
|
| In Golang projects we avoided pushing the vendors directory in
| one commit. Instead we had to strategically commit it piece by
| piece to satisfy "frequent small commits" metric that
| apparently is a signature of good developers.
| jacobyoder wrote:
| I worked in a place where... regardless of what I did in
| branches, someone else would merge it and their name would be
| the only thing that showed up in the git metrics, because we
| only looked at the final 'main' branch. I'd looked at the
| 'develop' - where feature branches were merged before master
| - and I think I had something like 75%+ of the commits (over
| a 14 month period). But to look at the daily dashboard, I was
| doing nothing, and someone who was barely in weekly meetings
| for more than 15 minutes was doing 95% of the work.
|
| I didn't particularly care, until people started looking at
| 'dashboard metrics' to see 'who's doing what'. I wasn't
| initially _wanting_ visual credit, but when my contributions
| were effectively erased to the casual viewer, it pissed me
| off...
| raxxorraxor wrote:
| > the creative folks you really want working there bail for
| greener pastures
|
| This is the main reason. Either pay 100k with boni and I work
| as a code monkey for some years. But even then I will bail
| after some time. A strategy that cannot be viable for any
| company, even those that just need a quick software solution to
| a problem. The knowledge management with changing employees
| only makes it even more expensive.
|
| If you want to burn money to see the commit log glow, please do
| so. I am unlikely to take any ownership of the code produced,
| but probably will come up with a commit here and there.
|
| Not every form of coding requires creativity, there is also a
| lot of mundane logic that just needs to be given form. But even
| those developers should not be subjected to such metrics or
| anyone really.
|
| What we created in other industries like logistics and call
| centers amounts to slavery aside from the fact that the
| employees decided to work there at some point. Something that
| also can be disputed how voluntary that decision was. Managers
| with such strategies are a liability for any company.
| steveBK123 wrote:
| Employee level metrics are a fast slipper slope to encouraging
| all the wrong behaviors. Most of what you actually want out of
| a good developer is not captured in metrics easily, but lots of
| superfluous stuff is.
|
| I recall one of my worst managers was a guy who would nitpick
| the "how" of every action (email/slack to users, internal
| runback documentation, etc), but rarely if ever call anyone out
| for inaction. He was also pretty indifferent to the what
| (actual functionality delivered to users).
|
| This created a tremendous bias to inaction in the team, and
| everyone developed slopey shoulders.. He eventually got fired
| but not before a lot of turmoil and turnover.
|
| As soon as you start rewarding devs based on story points,
| ticket counts, response times, ticket closure rates you get all
| sorts of bad behavior. You'd be better served based on
| quarterly changes in user satisfaction metrics as thats
| literally all that matters - the end product.
| jatins wrote:
| > "Peer reviews actually improve things" is about the biggest
| crock of shit that people in tech still believe in.
|
| God that hits home
| 000ooo000 wrote:
| Does the author mean peer review in the performance review
| context? Or code review?
| rustypotato wrote:
| Performance review, as per the linked post of theirs:
| http://rachelbythebay.com/w/2021/02/19/perf/
| 000ooo000 wrote:
| Thank you
| johnnyanmac wrote:
| Ahh that makes a lot more sense. Peer review was probably
| some of the best thing's I'd do at workplaces. Helping to
| point out thorns in my eyes and vice versa. There could be
| a bit too many LGTM comments, but I always welcomed having
| a second set of eyes.
|
| It can also help me scope commits. I definitely had a habit
| early on to bundle maybe 4-5 commits worth of code into one
| review; I figured it would waste their time a lot less.
| Fortunately I was taught early how that was a bad practice
| for multiple reasons.
| zooweemama wrote:
| I took it to mean in the performance review context.
| swampdonkey64 wrote:
| I learned years ago to either give constructive mutually agreed
| upon ahead of time peer reviews or not give any. I always run
| this type of stuff by the recipient to make sure that it isn't
| a surprise. Not too long ago I had one cartoonishly insecure
| coworker recruit another colleague to their cause of poo-pooing
| me. The latter wrote something like "they care more about doing
| things right than delivering quickly" because I surfaced too
| many obvious architectural issues in my PR comments (actual
| ones where they departed from our mutually agreed spec, not
| trite OO pedant nonsense). Thankfully my manager told me of it
| and dismissed it in much the same manner I did but I didn't
| feel great about being thrust back to junior high school social
| behavior.
| baq wrote:
| There's being polite and then there's this. You're throwing
| the baby with the bathwater. Don't do this. Claim this as an
| achievement and proof of your integrity instead.
| throwaway313373 wrote:
| > "they care more about doing things right than delivering
| quickly"
|
| Is it actually supposed to be a negative review...
| scott_w wrote:
| > Thankfully my manager told me of it and dismissed it in
| much the same manner I did but I didn't feel great about
| being thrust back to junior high school social behavior.
|
| I had an interesting interaction years ago where an engineer
| in my team shared his fear that a negative peer review would
| shape his performance review. I made a similar point to him:
| as the manager, I read all feedback but it's _my judgement_
| as the manager that determines the review.
|
| If I'm just parroting the comments of others and treating the
| review as just taking the average then I'm no better than
| Metacritic!
| marcinzm wrote:
| In my experience it's not just the judgement of the manager
| but the judgement of their whole reporting chain. All of
| which can read the reviews and may be the ultimate decision
| makers on promotions/ratings.
| scott_w wrote:
| Yes, it does depend on the organisation. I do expect my
| manager to read and have input on my reports, as my
| team's outputs indirectly affect my manager's outputs.
|
| I question the value of this the higher up the chain it
| goes, as managers get more and more removed from the
| people doing the work. That said, it does happen and it's
| not always a good thing.
|
| In those situations, you can address the comments
| directly in the review, or summary, but you can't
| directly control what other people take out of the
| reviews.
| blitzar wrote:
| What you are experiencing, and what is being described is not
| peer review.
|
| The skill of giving feedback was lost a few days after the
| skill of recieving feedback was lost. Actual peer review no
| longer exists.
| comp_throw7 wrote:
| Argument from "fuck you, I got mine", basically. Notice that the
| article doesn't claim the tools don't "work", merely that if they
| work it's because some layer of management is incompetent (maybe
| sufficient, but not necessary), and if so the company deserves to
| fail (what?).
| necovek wrote:
| It's actually even stronger than that: in the very last
| paragraph, the concern is that you'll uncover slackers and make
| enemies.
|
| I really don't think you can measure output and understand
| value for anyone but the most junior of engineers who basically
| need to churn out code to be valuable in the short term (and
| that's for those who do not have a questioning mindset to
| understand why they need to build what they are asked to). 6
| months in and it becomes useless even for them as they acquire
| domain knowledge.
| KaiserPro wrote:
| I don't share that view.
|
| To me the article reads that simplistic metrics do no
| accurately assess performance of employees.
|
| Managers need to work out what their reports are working on,
| and base an opinion on performance using more than just "number
| of tasks closed" etc.
|
| by creating these simplistic metrics, it means that the
| management chain has a false sense of what make the company
| tick. That confidence is the rot, not the poor performers.
| Simply because they do not actually know who the poor
| performers are.
| Ozzie_osman wrote:
| I agree with the spirit that these metrics shouldn't be used to
| evaluate employees, but if we expect managers to know what's
| going on, they do need some signal. Metrics are one of those
| signals. It's the manager's responsibility to layer on other
| signals to form conclusions.
|
| In other words, just because the metrics themselves aren't
| sufficient, that doesn't mean we should take them away
| completely.
| riffraff wrote:
| Yeah, I feel the discussion around this is usually "random
| metrics can be gamed and may not reflect true value of a
| person's contributions". But neither does unmeasurable gut
| feeling!
|
| If you use done tickets or whatever metric to _determine_ value
| that's a bad idea.
|
| If you use it to ask questions or confirm impressions it can be
| useful.
| exitb wrote:
| I think the argument is that if a manager is so far removed
| from the work being done, that they don't even know who's doing
| what, than they're a figurehead anyway.
| tjoff wrote:
| They need some signal, and metrics are not one of those
| signals.
|
| The metrics tell you one thing, but how to interpret it
| requires you to know what people are actually doing. And if you
| do know that then you don't need the metrics.
|
| Add to that, I don't think I know anyone that could be trusted
| to not misinterpret the metrics. It is a great way to reinforce
| what you believe, you can take your gut feeling and finding a
| way to see it in the data. But that isn't helpful either.
| rtpg wrote:
| I think the idea is that if a manager is just like... in the
| meetings with team members or also just ambiently participating
| in the work then they'll know what is happening.
|
| I don't need a metrics dashboard to know what's going on with
| my spouse. Feels pretty normal for a manager to have a decent
| idea of what's going on with their reports.
| crazygringo wrote:
| > _I don 't need a metrics dashboard to know what's going on
| with my spouse._
|
| You'd be surprised.
|
| It's extremely common for both spouses to think they're doing
| 75% of the housework. Resulting in a lot of resentment.
|
| Then after couples' therapy they agree to actually make a
| list. And the truth is revealed, and you can actually figure
| out how to make it balanced.
|
| It's extremely in common in therapy for both partners to
| insist they know what's going on with their spouse, when the
| reality is they don't at all, and therapy is about _actually_
| seeing the other person 's POV. And believe it or not,
| metrics can help with that -- particularly around time spent
| and money spent on things that are obligations vs.
| recreation.
|
| And it's not so different with managers. I've had managers
| who just simply disliked one report and didn't think they
| worked hard enough, and just liked another report and always
| assumed they could trust their output. With no correlation to
| the employees' actual performance. Metrics help correct our
| blind spots.
| donatj wrote:
| In the late aughts, I became lead developer of a team that had
| never done any sort of version control. Just nightly backups of a
| shared SMB server.
|
| I wanted to get everyone using git, but getting people to
| actually bother committing their work was like pulling teeth.
|
| I built a "git leaderboard" showing how many commits each
| developer had made that week. It didn't really help and it sure
| didn't make them resent me any less.
| gardenhedge wrote:
| Some things need management to run and say "do this, or else".
| If you don't have that weight behind your words good luck
| getting any big changes done.
| donatj wrote:
| I was ill suited to be manager in hindsight. I am a good
| developer, I am not great with people. I wanted it because it
| seemed like the next logical step in career progression but I
| was not good at managing people.
|
| I am very glad I left. I have spoken on here before about how
| it gave me stress induced health issues.
| gardenhedge wrote:
| Were you a lead or a manager?
|
| Did you take a salary cut?
| donatj wrote:
| Both? I was in charge of our codebase as well as managing
| our developers.
|
| Is that not how it always is? Everywhere I have worked
| "Lead Developer" has been a management position, such
| that your team reports to you.
|
| No, it was actually a pretty significant pay increase. I
| went from a very small company to a larger one.
| eesmith wrote:
| About the same time, I looked to see if there was any research
| on the effectiveness of a version control system like git vs.
| other methods of versioning (like VMS-style numbered versions,
| or backup/snapshotted file systems with a temporal browser).
|
| I found nothing.
|
| FWIW, "git leaderboard" is trivially gamed. Not only with
| pointless auto-commits, but some people commit every few lines
| while others commit only when things are in a good shape. What
| you ended up doing was introducing the same sort of resentment
| as factory workers under Taylorism and observations from the
| time-and-motion man.
|
| Had our schools taught more about the history of labor rights
| and struggles, and perhaps less of the success of industrial
| oligarchs, then perhaps you would have been more likely to
| expect that resentment and not tried it in the first place.
| donatj wrote:
| > trivially gamed
|
| Eh, there were no rewards, so no real incentive to win. The
| idea was just more to get the act of committing their code
| into their minds. Like "oh hey, everyone can see I'm at zero,
| maybe I should commit my work".
|
| This was something I tried after months of poking people to
| commit their work.
|
| I'd put together a whole training on what git is and why we
| should be using it. It came up every weekly meeting. I was
| grasping at straws.
| eesmith wrote:
| Then no real inventive to lose, so no real incentive to
| switch, so no real incentive to care about a scoreboard,
| while making those who might test the waters subject to
| possible public ridicule.
|
| What do you think the advantage is to 1) using a version
| control system, and 2) using git, in the aughts?
|
| Version control systems have been around since at least the
| 1970s (dating from SCCS), so 30 years before your
| experience. My group was using RCS in 1993. Which means the
| people you were trying to convince almost certainly know
| about the concept and possibility before you tried to
| persuade them.
|
| Frequent backups of a shared file system is a form of
| versioning. VMS-file filenames.txt;001 is a form of
| versioning. Moving projects into new directories is a form
| of versioning. None of them require any special training to
| get started, and the latter two let you use any normal
| tools to view and compare different versions of the file.
|
| Some places had conventions about who was allowed to modify
| a file, while the git model is that anyone can modify
| anything.
|
| Which means there are clear negatives to switching to git,
| especially for an organization which has been using another
| means of versioning.
|
| What did you do to minimize those negatives? What did you
| do to provide transition system so some people could use
| the old system and others the new? Why start with git, and
| not something like RCS/CVS which was structurally more
| aligned with the centralized model they were used to?
| devoutsalsa wrote:
| One could make the argument that if you need to measure what your
| employees are doing, your business processes suck or you have the
| wrong employees. I feel like in a functional business, people
| will know who is and isn't getting stuff of value done.
| onion2k wrote:
| _It 's the job of a manager to know what their reports are up to,
| and whether they're doing a good job of it, and are generally
| effective._
|
| That's true, but it's not what employee metrics tools tell you.
| If you're using metrics tools to measure productivity then you're
| not really being a good manager. Metrics tell you are the
| quantitative details (eg a count of how much output there is),
| but as a manager what you actually care about in your day to day
| work is the qualitative details (eg how good the output is), how
| happy the team is, where the conflict is, etc. Metrics won't tell
| you that.
|
| But...
|
| Being a manager is about more than just getting people to do
| their job well. You also need to plan things, you need to know
| what's changing over time, you need to test whether your
| processes are working. I use metrics to measure the aggregate
| impact of _my_ influence on managing my teams, not that of any IC
| on any of my teams. Employee metrics are useful for a big picture
| view.
| bigiain wrote:
| > Employee metrics are useful for a big picture view.
|
| Which "employee metrics" do you find useful for that?
|
| Because in my experience, it's pretty much guaranteed to be
| someone who isn't anywhere near leading on the type of metrics
| these discussions are talking about - that's making the biggest
| impact and amplifies _team_ productivity. Those people don't
| close a dozen Jira tickets before lunch, they are the people
| who spend two weeks actually finding and fixing the root cause
| of that one annoying ticket that 15 other people have closed
| only to find the problem re occurs. They aren't top of the
| leaderboard in git commits, because they actually read the RFCs
| or dependancy source code while working. They sure as hell
| don't always write the most LOC in a week - I want the "minus
| 2000 lines of code" guy, not the one who's best at gaming
| whatever metrics you use.
|
| https://www.folklore.org/Negative_2000_Lines_Of_Code.html
| onion2k wrote:
| I don't even look at the metrics for ICs. If a team has an
| underperformer I expect the lead to be handling that, with my
| support if necessary.
|
| The metrics I find useful are things like trends before and
| after a change. For example, if lots of PRs are taking a long
| time to get through review because the descriptions don't get
| filled in well, I want to look at the time code spends in
| review before and after updating the PR template. Or before
| that, I want to see which teams have code in review for less
| time so I can look at their PR process and suggest changes to
| slower teams that the faster teams have already implemented.
| If a team is doing the same stuff as other teams but their
| typical PR size is much bigger I want to know if they have
| fewer stories that they should be breaking down further. And
| so on.
|
| None of this is data I don't have a gut feel for, but having
| real numbers is useful for making a case for change. People
| don't always believe instinct. It's harder to argue with a
| well-designed graph.
| ozim wrote:
| It is also super hard to look at trend of "gut feeling" or
| "instinct".
|
| Seems like lots of people discuss here false dichotomy and
| I really like onion2k explanation because it is much more
| nuanced and basically explains the same thing I was trying
| to convey in other thread on similar topic.
| welder wrote:
| How do you collect & display these metrics, manually,
| internal tools, or a product?
|
| I'm often asked to provide employee metrics but my product
| is just an automated time tracker for contractors & devs,
| who bill by time. I've avoided it being used as employee
| metrics, but we recently built a separate product for these
| trends and team insights that you're using.
|
| May I email you to the address listed in your HN profile?
| Just for an informal chat.
|
| You can reach me at alan@wakatime.com.
| onion2k wrote:
| I use Jellyfish. Happy to have a chat. Fire me an email.
| :)
| jachee wrote:
| I feel very seen.
|
| I'm at my happiest when being grease or glue; when I unstick
| the stuck, or stick the unstuck. I like to "walk the
| property". Find the bugs that are under rocks.
|
| I'm not at my best as a mere construction drone piling on
| work for work's sake. That's soul-killing, for my soul, at
| least.
| exe34 wrote:
| hello my fellow troubleshooter:-D
| ukoki wrote:
| > it's pretty much guaranteed to be someone who isn't
| anywhere near leading on the type of metrics these
| discussions are talking about - that's making the biggest
| impact and amplifies _team_ productivity
|
| It would be great if everyone on the team had different
| strengths that contributed to team productivity "A smashes
| out small features like nobody's business", "B is great at
| debugging", "C is great at planning and seeing through big
| long-term features", "D is great at helping teammates" etc.
|
| However in practice I find you have a minority of team
| members who can do _all_ of A, B, C, and D's tasks well, and
| a mediocre majority who deliver between 20% and -10% the
| productivity of the talented minority.
| khazhoux wrote:
| > They aren't top of the leaderboard in git commits, because
| they actually read the RFCs or dependancy source code while
| working. They sure as hell don't always write the most LOC in
| a week - I want the "minus 2000 lines of code" guy
|
| Yes, these engineers are invaluable. But the "minus 2000 LOC"
| engineer is rare.
|
| In my ~25 years of experience at several top companies, I've
| seen that --more often than not-- the most impactful coders
| _are_ writing the most LOC. And they 're not gaming it
| either. They are simply writing a ton of high-quality code:
| features, bug fixes, optimizations, cleanups, etc. Yes,
| occasionally there is a crazy heisenbug that takes 3 weeks
| for a one-line change, but that is rare.
|
| Note that I deliberately use the word "coder" (which I don't
| usually do) instead of the more generic "engineer." Because
| I'm not talking about those critical senior engineers whose
| job is mostly to prevent others from writing bad code.
| mikeshi42 wrote:
| Agreed. At the end of the day - the end user of the
| software probably wants something other than technical debt
| reduction, so it's not surprising impact and LOC can
| roughly be correlated.
|
| Taking the LOC metric too far, in either direction, is
| trying to read too much into a single metric.
| caskstrength wrote:
| > Being a manager is about more than just getting people to do
| their job well. You also need to plan things, you need to know
| what's changing over time, you need to test whether your
| processes are working. I use metrics to measure the aggregate
| impact of my influence on managing my teams, not that of any IC
| on any of my teams. Employee metrics are useful for a big
| picture view.
|
| The point of the article is exactly that such metrics don't
| give you any kind of a good signal _unless you are really into
| the fine details_. And if you _are_ , then you don't really
| need them in the first place.
|
| > quantitative details (eg a count of how much output there is)
|
| For example I recently spent a week producing several thousands
| of lines of tedious trivial code that parses some configuration
| out of JSON file in pure C. Then I spent a month writing less
| 1k lines of very dense low-level packet parsing code and the
| main loop also in C. So the metrics would show you the big
| picture of me slacking and my performance tanking which
| obviously wasn't the case. _You can 't substitute actually
| knowing and understanding of what your reports are doing with
| some tools providing you with trivia like number of commits,
| lines of code changed or tickets closed._
| blitzar wrote:
| Being a good manager is taking in all the metrics (+other
| information), assigning the appropriate weights to them and
| making informed determinations.
|
| If the worker changing your code style from snake case to camel
| case does 500 commits in a day they are not a 100x programmer
| vs the worker solving world peace who did 5 commits. If their
| commits drop to 1 a day then maybe reach out and see how things
| are going, solving world peace has a lot of dead ends and
| bottlenecks.
| ainiriand wrote:
| I like this new punk Rachel much more.
| alpb wrote:
| OK, I'll bite. I think if you're a technical team lead in a large
| organization, it is rather your job to point out what's working
| and what's not working from a technical perspective. If managers
| could figure this out, they most likely would not end up being
| people managers after all (insert if those kids could read
| meme.jpg). Sadly, nowadays even the most large tech companies
| have enough red tape and bullshit going on (OKRs, alignments,
| escalations, Q4 plannings, weekly 1:1s with all reports etc) to
| keep people managers full-time occupied. Most people managers
| nowadays neither have the chops to understand the work that's
| taking place on the ground, nor have the time to track it.
|
| So it falls on a tech lead to point out who are the sailors in
| the ship that are not rowing (or worse paddling backwards). I'm
| not saying "go build a git commit counter dashboard" but if
| you're working with dozens of people and it appears someone isn't
| delivering a lot of work lately, it helps you double check your
| assumption. (Again, not saying commits are a good metric.)
|
| This blog post is definitely relatable to most of us because we
| join teams that are somewhat dysfunctional, and if you have the
| influence capital and the chops to turn that team into a place
| where hiring is done properly, people have motivated and the
| right amount of work and the room to grow, I think you can turn
| the ship around. Or maybe I'm too naive and have a lot more to
| learn.
| bootloop wrote:
| That just means as a tech-lead you end up not only putting
| blame on the (broken) tech but also blame the people right with
| it?
|
| I don't think that is a smart thing to do within office
| politics.
|
| I do agree that you can elevate people with potential, to build
| something of value with them, but I would stay away of trying
| to get people fired or replaced.
| anonymoushn wrote:
| > If managers could figure this out, they most likely would not
| end up being people managers after all
|
| If ICs could figure out people management, they would have
| higher pay, less work, and the ability to blame their reports
| for all their problems.
| devjab wrote:
| If your job is not to manage people then their performance
| shouldn't really matter to you. If the company wants you to
| care about that they should give you actual management duties
| (and the pay which comes with it).
|
| It's obviously cheaper to have technical leads be a kind of
| pseudo managers where you get them to do most of the middle
| management, their own work and the reporting. This way you can
| save a lot of money by keeping the financial parts away from
| the technical leads, which also means you don't actually have
| to listen to what they say about performance. Because one of
| the major truths about management is that a mediocre performer
| is usually a good keep since they are cheap labour and less
| likely to leave. Sure you can do stuff like cutting the poorest
| 10% and I think this is popular in the US, but that usually
| doesn't invoke the best productivity because it hurts morale.
| This way you can also semi-easily replace your pseudo-middle
| managers because the hardest part of management isn't the day
| to day stuff, it's balancing the spreadsheets and making your
| own successes look good.
|
| From a top decision maker perspective the separation also makes
| sense in terms of not having too many responsibilities tied to
| a management area which is notoriously hard to get talent for.
| If your tech managers are too technical, or if your technical
| leads are too invested in management it's much more expensive
| when one of them leaves.
|
| The unfortunate side effect is that it often burns technical
| leads out. Makes them unhappy when they are passed over for
| promotions or don't feel they get credit for the work they do.
| There is no easy solution though because managers tend to
| change jobs much more often than most other "more expensive to
| replace" positions. I suspect a lot of technical leads might
| also find the corporate politicking between middle management
| and managers or managers very stressful.
| Jach wrote:
| I don't really disagree with anything here, except that I
| think "not my job, not my problem" is at best a sign of
| unhealthy dysfunction, and not something to aspire to. Well,
| for most people; probably certain annoying activist meddlers
| could settle down and focus more on their own areas. And I
| suppose it can be a rational self-protective mechanism when
| you're stuck in a really dysfunctional place, as doing too
| much "not in the exact letter of my job contract" types of
| work can quickly lead to burnout, but it'd still be better to
| look for something new... As the thread's current top comment
| mentions, when you disincentivize things like "Helping a
| colleague" or "Digging into what looks like a security
| vulnerability", that's just incredibly corrosive and makes
| dysfunction even worse. It doesn't matter whether you
| disincentive such things with bad management dashboards or
| with encouraging an attitude of "not my official job duties,
| don't care".
|
| It's not quite a matter of "professionalism", and I very much
| don't want programming to turn into something that requires a
| professional engineer stamp like other engineering
| disciplines, but professionalism might be the best proxy
| term. I want to work with people who do good work. Even
| excepting the cases where someone else's bad performance or
| work actually can directly impact me or the rest of the
| team's work or reputation, I'd rather work at a place that
| discourages bad performance. If management appears blind to a
| particular instance, it may well be worth saying something to
| try and correct it, even if performance of the system is
| ultimately their responsibility. Each place is different,
| maybe saying something will actually improve things, or maybe
| it just ends up being another one of the hundreds of cuts
| that eventually make you conclude the place sucks with
| management not interested in improving it or themselves, and
| you go elsewhere.
|
| There's a similar notion with introducing better technical
| practices like version control. Another comment mentioned
| struggling to get git adoption, but there are plenty of other
| stories of the opposite, where you do get a team to adopt
| something without the threat of management forcing it on
| everyone. Those experiences are great, I'm glad to have had
| several of them.
|
| For sure, if you're being asked to be "tech lead", you should
| at least be getting paid as much as any of the direct
| managers of the team. In the age of "parallel promotion
| tracks", there's enough truth to that convenient fiction that
| this shouldn't be too difficult to achieve. (There is the
| downside of dumb processes like having to perform "at level"
| for several months to prove you deserve a promotion. You're
| basically taking a pay cut for that time, so better argue for
| sufficient compensation increase/bonuses when that promo
| comes.. and justifiably ragequit if passed over.)
| devjab wrote:
| I think we mostly agree. I do think that this part:
|
| > is at best a sign of unhealthy dysfunction, and not
| something to aspire to.
|
| Should be disclaimed by saying that I'm Danish and we have
| a different view of workplace authority than people in the
| USA might.
| alpb wrote:
| I don't know if you've worked in a large corporate
| environment but usually your success depends on others. If
| you're a a tech lead, you rely on other individuals to
| deliver. If the whole project fails, nobody gets their
| promotions or bonuses anyway. So it's rather a collective
| effort to get the teams in a well executing state.
| raister wrote:
| "Tell me how you measure me, I will tell you how I behave." Eli
| Goldratt
|
| "When a measure becomes a target, it ceases to be a good
| measure." Goodhart's Law
| m463 wrote:
| "Eli, one unauthenticated metric is sent to
| https://metrics.corphq.yoyodyne.com/counterincrement in json
| format {"empid":"<employeeid>","workunit":"1"}, each time you
| complete a work unit."
| renewiltord wrote:
| You can't tie employee metrics to comp because of Goodhart's Law.
| But it can be useful to identify who's in trouble. Metrics exist
| as a technique of information compression that is valuable
| because as you go from the farmer inspecting a specific plant to
| an industrial farmer managing acres of plants you lose sight of
| the individual plants. That's not because you don't care about
| the plant. You do. You just also have to care about the other
| plants. But your scarce resource is attention and time.
|
| If you use the metrics to optimize your systems good for you. If
| you use it as a punitive/remunerative system, the org will
| optimize against your metrics.
| OccamsMirror wrote:
| I agree with this. If commits from a dev suddenly die off, it's
| worth investigating. But it's still not a metric worth
| dashboarding.
| PaulKeeble wrote:
| One project I was on someone added a tool and posted the results
| of the past week of number of lines of code added, my count was
| -5900 and I had been put at the bottom. This was a legacy
| project.
|
| Its pretty easy to explain why removing a bunch of complexity and
| replacing it with something smaller and meeting the customers
| requirements better is obviously the goal on any project.
| Everyone that added lines had made things more complex. Its
| obviously a useless measure for productivity or saying anything
| of note about the work at all other than the lines of code making
| up the project and how it is changing over time.
| ajuc wrote:
| Even if you insist on having these metrics and using them -
| it's another level of stupid to measure lines of code added
| instead of edit distance.
| r1chardnl wrote:
| "One of my most productive days was throwing away 1000 lines of
| code" -- Ken Thompson
| canucker2016 wrote:
| -2000 lines of code, Bill Atkinson, Apple Lisa Quickdraw
| developer
|
| https://www.folklore.org/Negative_2000_Lines_Of_Code.html
| m463 wrote:
| https://www.folklore.org/Negative_2000_Lines_Of_Code.html
| mirekrusin wrote:
| Removed LoC should count double.
|
| Edit:
|
| But then again, the point is not about individual examples
| really - the point is that whichever metric you choose, with
| time you'll see diminishing returns followed by negative ones.
|
| In case of doubling removals, you can easily game it by dumping
| json files for tests, then removing them ie. in favor of
| generator etc.
|
| What's interesting is universality of this phenomenon (strong
| goodhart's law?) - overfitting in llms, using metrics discussed
| here and why it makes sense to vote on opposite ruling party
| etc.
| maeln wrote:
| That is how you end up with a unreadable code where
| everything is a oneliner and there is no comment and no
| documentation :D
| mirekrusin wrote:
| Absolutely agree, added edit, should have posted long
| answer instead of update with clarification, my bad.
| nosianu wrote:
| Related, research: "Humans solve problems by adding complexity,
| even when it's against our best interests"
|
| Article:
| https://www.washingtonpost.com/business/2021/04/16/bias-prob...
|
| Study published in Nature: "Adding is favoured over subtracting
| in problem solving" --
| https://www.nature.com/articles/d41586-021-00592-0
|
| > A series of problem-solving experiments reveal that people
| are more likely to consider solutions that add features than
| solutions that remove them, even when removing features is more
| efficient.
|
| > ...the authors observe that people consistently consider
| changes that add components over those that subtract them" --
| be it bricks or regulations, so it works like this for real as
| well as for abstract things.
| vdvsvwvwvwvwv wrote:
| I reckon that depends.
|
| Coporate culture encourages adding. Half your job is
| justifying keeping your job. It takes a lot of swagger/social
| capital/clout to subtract and be loved for it. Or you need to
| work somewhere (a company or protected team) with a first
| principles thinking culture (and not a cargo cult one) which
| is very rare.
|
| In personal life I think people do often subtract. They give
| up X where X is harmful. They simplify. Not everyone but
| many. It feels like a natural part of life.
| nzach wrote:
| > even when removing features is more efficient
|
| Efficient in what sense ?
|
| > Our conclusion is that people systematically overlook
| subtraction; it's not that subtraction is always better
|
| My personal experience agrees with these findings, but I
| think they missed something more important. People try to
| change things because they want to see something new in the
| real world. But from ideas to real world impact there is
| always at least one level of 'approving' you will have to go
| through. And adding things will generally have less risk
| associated.
|
| Besides that, I think our education system doesn't train us
| to remove things. Everything we learn is incrementally built
| upon what was already there. So our default mode of thought
| is to add things.
|
| Now imagine we have 2 developers, one how always solves
| problems by adding something new and another one that always
| refactor things to keep things efficient.
|
| My guess is that by only adding things you will end up
| delivering more features with less bugs. Sure your code will
| be slower and at some point it will become impossibly complex
| to manage, but it takes quite a long to time to get to this
| point.
|
| After writing this message I've realized that 'making things
| easy to delete' is a pretty important feature.
| em-bee wrote:
| _People try to change things because they want to see
| something new in the real world_
|
| my personal feeling on this is rather, removing someone
| elses code is like dismissing their work. and generally i
| don't want to do that. if it is not clearly a bug, then i'd
| hesitate. someone wants this feature. taking it away would
| not be nice to them.
|
| it may be similar to the problem of design by committee.
| everyone wants to get their favorite features in, and we
| are more concerned about our relationship to our colleagues
| than the end result. here, we can solve this in a way to
| make everyone happy, but without stopping to ask if
| removing that mis-feature would actually make anyone
| unhappy.
|
| thinking further, i think this is also a problem with
| personal ownership of code or features instead of team
| ownership. this feature is owned by X, i can't remove it
| without his permission, or without a discussion in a
| meeting. leaving it in and working around it is the path of
| least resistance
| danaris wrote:
| Whether or not removing features might be "more efficient",
| in nearly all cases, if you remove a feature that's been part
| of a software package--whether external or internal--some
| nontrivial fraction of the people using it are going to be
| angry, because you just broke their workflow.
|
| The only way you can _possibly_ avoid this is if, in addition
| to removing that particular feature, you _add_ a feature that
| _does the same thing fully automatically_ , and does so
| correctly in every instance.
|
| (Even then, some people will complain about it, but at that
| point you just have to accept that as a cost of progress.)
| stavros wrote:
| That's not useless at all, the moment I saw -5900 I knew that
| was the most valuable contribution to the codebase.
| hinkley wrote:
| I gave myself carpal tunnel replacing over a hundred copies of
| the same five lines of code with an n2 complexity with a single
| implementation, so then I could fix the perf issue later. -500
| lines over a holiday week, which was nice, but not as nice as
| landing the changes to the shared function and making 2/3 of
| the app 10x faster with the test data, which was ultimately
| going to be a fraction of the real data.
|
| Don't large scale refactor in vim folks, especially if you
| haven't memorized all of the shortcuts (I hadn't discovered
| block indent until weeks later. Ouchie)
| shermantanktop wrote:
| Middle managers do not create value directly. They can only
| create the conditions for value creation by others. They can do
| so actively, by understanding their team and making changes, or
| defensively, by protecting their team from threats.
|
| If they are 100% busy with optics and reporting, the only thing
| they can possibly be doing is defensive work. At which point the
| game becomes clear - an organization so addicted to those
| approaches is actively suspicious of their own employees, trust
| has broken down, it's everyone for themselves.
| logicalxor wrote:
| >> So, my new position on that sort of thing is: fuck them. Don't
| help them. Don't write tools like that, don't run tests to see if
| your teammates will take care of basic "service hygiene" issues,
| and definitely don't say anything substantive in a performance
| review. None of it will "move the needle" in the way you think it
| will, and it will only make life worse for you overall. "Peer
| reviews actually improve things" is about the biggest crock of
| shit that people in tech still believe in.
|
| I know this is coming from a good place and good heart. However,
| even in 500 people organization this does not work. Peer reviews,
| championed by FAANGM and now adopted by everyone, are here to
| stay. If you don't do the work then someone else is ready to do
| that and take credit.
|
| Also, god forbid if you sit in Amazon style performance
| evaluation. Only way to survive is you know someone. I have seen
| too many things at these evaluations. One quarter someone is HV+
| or TT and in six months they are on PIP because manager changed
| their mind or Sr. Manager or Director asked them to.
|
| Pro tip: Don't work at shit orgs at Amazon (FinTech, Prime Video)
| and don't work for terrible employers. You won't believe how much
| fewer stuff we need to get by. I used to think one need 200k+ to
| survive in west coast VHCOL (Bay Area, Seattle). However, I am
| surprised how far even 60k gets you with a family of four and one
| of the spouse staying at home.
|
| Author is mostly right in spirit and I wholeheartedly agree. I
| just don't see a way for employees escaping peer review culture.
| OccamsMirror wrote:
| > However, I am surprised how far even 60k gets you with a
| family of four and one of the spouse staying at home.
|
| This has to be a joke, right? 60k income for a single income
| family of four? In the Bay Area or Seattle?
| makach wrote:
| Employee metrics is just a tool, as with any tool's metrics can
| be used for good or for purposely evil. So, it is how you use it
| to improve that matters- In a workplace everyone has a
| responsibility to support and make a good work environment and to
| ensure what you are doing is profitable, ethical, sensible.
| steventhedev wrote:
| There are a few exceptions to this, with varying degrees of
| justification:
|
| 1. An underperforming teammate when your personal rating is tied
| to team metrics. Which is a shit way to run a team.
|
| 2. You are a tech lead in a company where the career and level
| expectations are that you will assist in performance managing ICs
| on the team. Which is being a manager in all but name.
|
| 3. You truly care about the personal performance of these
| "slackers", which is a good sign that you want to be on the
| management track, but probably shouldn't be.
|
| 4. You have some strong external incentive like slackers directly
| impacting the values of your shares (and you own enough for it to
| make a difference)
|
| 5. You are a petty asshole.
|
| I will never cease to be amazed how many people will fall into
| number 5 - but will insist they are doing it for other reasons.
| stefan_ wrote:
| Whatever happened to
|
| 0. Working with incompetent people that can't deliver will make
| you miserable
|
| or the strongly correlated
|
| -1. If you are not learning, you are regressing
|
| Sorry, there are many many reasons to want to work with
| excellent, strong coworkers.
| qsort wrote:
| Or even just:
|
| 1/[?]2 + i/[?]2. We are all on the same boat and I have to
| pick up your slack if you don't work.
| YetAnotherNick wrote:
| While there are obvious flaws with metrics as Rachel mentioned,
| there are equally bad flaws with leaving things to manager.
| Lot/most of middle managers are dysfunctional and don't at all
| work or care to provide the best review possible from their side.
| Should the team suffer because of this?
|
| Aside, I think consistency is at least somewhat a good metric
| unless totally gamed. Not the number of PR merged or anything,
| but metric for coding activity time each day with a very low
| ceiling for completion, say 1 hours a day.
| ookblah wrote:
| I read her other post from 2004 and i can't help but think you're
| throwing the entire thing out, baby and the bathwater and all.
|
| I don't think you should make the metrics the end all be all
| (Goodhart's law), but that graph is certainly helpful if you can
| figure out who might be doing literally NOTHING for hours on end
| vs. someone who is productive at some level. All trying to
| "figure it out" at that point as a manager is just trying to cut
| through someone's bullshit when the data is right there.
|
| Maybe it's more like 90% of the cases those metrics shouldn't be
| used to measure anything, but they can certainly point out
| "smoke" where there might be someone struggling and then you can
| be an actual manager and figure it out case by case.
| Galaxeblaffer wrote:
| Yea because churning out or changing code is the only
| imaginable productive thing a software engineer can do ? what
| about planning, helping others out, researching all this stuff
| is super difficult to measure. It all depends on the work, the
| team and the size of the company i guess.
| physicsguy wrote:
| I totally agree with you, but there've been employees I've
| managed in the past who loved to go off and get distracted
| with anything they judged "useful", often at the expense of
| their actual work. That's something to be managed rather than
| measured by metrics.
| ookblah wrote:
| did i say that? that's why i said it's an indicator, one of
| many. if you are producing zero code vs your peers and your
| job is to program it doesn't mean you are unproductive, but
| at least someone can talk to you about it and clarify vs.
| just guessing with zero data.
| m463 wrote:
| This punishes the good people, putting them under scrutiny.
|
| Should these tools check up on management too? Maybe sneak in
| some false direct-report metrics to see if they notice?
|
| Make it game of thrones all the way down to game of peons. :)
| ookblah wrote:
| i don't understand how this is punishing the good people... i
| think everyone here has some ptsd with terrible managers or
| others micromanaging their work. data a good way to look back
| and ask the questions that might need to be asked, but to not
| use the data as the final criteria for anything (which is
| where i think most lazy managers end up).
|
| do companies plan their strategy with zero data? i find it
| hilarious we devs somehow think we are a special group that
| can't be measured at all, so just don't bother and let us be.
| at the same time we don't want managers up in our business
| all the time either. just because the measurement isn't
| perfect doesn't mean to not measure at all.
| m463 wrote:
| > i don't understand how this is punishing the good people
|
| This is putting the trustworthy people under personalized
| surveillance/scrutiny.
|
| I just don't think working with someone looking over your
| shoulder to be that healthy, and might be counter-
| productive (maybe literally).
| ookblah wrote:
| i mean i don't considere issues closed or tickets open to
| be "looking over my shoulder", but i guess we disagree
| there. these are some metrics that need to be looked at
| _at some point_ to determine some strategy about the
| future or reflect on the past.
|
| "trust" to me is knowing that everyone that has access to
| these metrics are making decisions in good faith. it's
| knowing that your boss isn't sitting there watching it
| every hour or using it as some simple metric to axe you.
| blame the people not the tools.
| renegade-otter wrote:
| The only metric that matters is - "is anything getting done". And
| this is why Scrum exists. Engineers hate scrum because it knocks
| us out of the zone in the morning, as it's yet another meeting to
| pop into.
|
| But Scrum is not there for us, it's for the managers to know
| "what up". It's the visibility overhead SPECIFICALLY for this. I
| don't know why we have to invent other things on top of it.
| qwer1234321 wrote:
| There was a time I was running a 10+ team and was executing
| scrum by the book, not really understanding much of it at
| start. Meetings felt weird and generally it was very intense
| time. But after some time a few things clicked in my head: I
| could plan with some certainty without bothering people, and
| execution was falling between min/max planned capacity,
| everyone was aware of pretty much everything, even in 'other
| places' where they were not actively contributing, everyone
| learned to estimate their work based on complexity. And above
| all, after leaving the place and working in a few different
| shops, when I look at the code quality produced in that place
| I'm still impressed (not brownnosing myself, really). We
| executed ~50 2-weekly sprints, I miss that time.
| valzam wrote:
| The irony of course being that the official scrum guide,
| however much weight you out on that, says that managers and PMs
| only attend standups if they actively contribute to the sprint.
| I have found daily standups that are mainly for the managers
| benefit incredibly annoying and unproductive. Maybe in teams
| with more junior people that don't speak up/actively reach out
| it makes sense but in my current team we talk all day on
| slack/meet. It makes much more sense to give the manager a
| weekly report on how the projects are progressing instead. This
| is much more outcome focused instead of trying to keep the
| manager abreast of every small step of solving a ticket.
| tpxl wrote:
| > it's for the managers to know "what up"
|
| If a manager wastes 30 minutes of their teams time every day
| because they can't figure out 'what up' from their task
| management software or quick 1-on-1 meetings, I can confidently
| assert they're a shit manager.
| bravetraveler wrote:
| Oh my, they did that kind of performance work at the cultiest of
| cults, Rackspace?
|
| Their temperature makes so much more sense now. I encountered
| that place, crash course in gaslighting. Thanks for probably
| getting me laid off
| talkingtab wrote:
| The power of language to lead us down stupid roads is amazing.
|
| "It's the job of a manager to know what their reports are up to
| ...".
|
| The conceptual framework that is required to read and write this
| sentence is slave labor. Not collaboration. Inherent in this
| sentence is the same lack of understanding of how people work
| that turned the US from being the world's biggest producer of
| cars to not. The Soviet Union crashed and burned because of this
| prisoner-guard model of interaction.
|
| Collaboration requires trust and common cause. Prisoner-guard
| embodies neither of these components.
|
| The need for collaboration is a function of complexity and
| uncertainty. Or upended, you can only "manage" people for tasks
| that are certain, known and simple. Which in turn means you can't
| adapt.
| IshKebab wrote:
| She put it a little strongly (it isn't the _only_ job of a
| manager) but I don 't think it implies everything you're
| saying.
|
| In a perfectly collaborative team (which can happen in small
| companies where the goal is very unambiguous), it's _still_ one
| of the jobs of a manager to know what everyone is doing. Not in
| an "I suspect you of slacking off" way, but an "I'm making
| sure we're all coordinated" way.
|
| Do you think a manager _shouldn 't_ be aware of what people are
| doing?
| __alexs wrote:
| Companies are information processing machines and managers
| are the data busses that the sub modules communicate through.
|
| Their job is to make sure that the right people know the
| right things at the right times. Their job isn't to just know
| what their team is doing, that's a valueless activity on its
| own.
|
| That is to say, managers need to know things about what's
| happening all over the place. Their own reports are probably
| the absolute easiest thing for them to monitor so this focus
| on it is kind of strange.
| talkingtab wrote:
| The best manager I ever had was someone I had no respect for
| at first. He was not a tech wizard and at times I suspected
| he was clueless. (He was not, just focused on _his_ role.
|
| He thought his job was to ensure that his reports knew what
| OTHER people in the group were doing. And that we, as a
| group, knew where we were going. The group was astonishingly
| successful, because WE got things done. Over a period of
| years.
|
| The silly company hired some very techy guy who decided to do
| a rewrite with plugins. Wowy Zowy Tech! Over two years that
| group became larger and larger and never, ever, ever shipped
| a product. Hmmmm. Then they went under.
|
| It is the WE that is important. This was not an attack on
| rbb, although I understand how it read like one, and I am
| sorry for that.
|
| It was however an attempt to point out that even if you drop
| the _only_ there is no WE in that concept of how people work.
| Certainly no one argues for a manager not to be aware, but
| the crucial element is for team members to be aware.
| ratorx wrote:
| > collaboration requires trust and common cause
|
| Much more fundamentally collaboration requires communication.
| In a hierarchy, a manager is a fan-in/out point. It is
| essential that a manager knows what their team members are
| doing to effectively perform their role.
|
| Trust and common cause are also essential for _effective_
| collaboration. However, I'd argue that regardless of whether
| these are present or not, the statement in question has to be
| true.
| satvikpendem wrote:
| > The power of language to lead us down stupid roads is
| amazing.
|
| You're taking one part of what the author said and
| extrapolating it many times further than its original meaning
| (comparing it to the Soviet Union, really?), ironic.
| mft_ wrote:
| I wonder whether successful Chinese car companies are currently
| thriving thanks to their implementation of a collaborative
| trust and common cause culture?
|
| Or maybe there's a little more to it...?
| pammf wrote:
| There's this theory that systems often thrive at the expense
| of its individual parts... I guess this is one of such
| examples.
| brodo wrote:
| I had managers in the past who did not know or care what I was
| doing. They got nothing done. They didn't know the product. I
| remember distinctly that one of my colleagues got mad because
| our manager proposed a feature that he had implemented a year
| before and was quite a lot of work. On the other hand, this was
| the coziest job I ever had. Most of us worked about 1-2 houres
| a day. For me that was fine, but others really struggled with
| it.
| talkingtab wrote:
| I did not mean this as a criticism of the author. I understand
| it reads that way, and apologize. It is an attempt to question
| the base assumptions inherent in the analysis. As I put in
| another comment, and as someone else stated, the job of a
| manager is:
|
| * ensure members of the group know what each other are doing. *
| ensure members of the team know where the team is going * act
| as direct report in another team that has another manager that
| does the same.
|
| Any non-trivial software project will require parallel
| development. The biggest risk to any non-trivial software
| project is that when the pieces from parallel development are
| put together, they will not fit or inter-operate. In my
| experience.
| alkonaut wrote:
| Wait so this person used to say people should be measured on
| output using tools, and people listened to them then? Why is
| anyone still listening?
| pixelfarmer wrote:
| Over the years I was wondering why management is often so bad to
| begin with. There are terms like "stupid" that are often used --
| I certainly did and still do -- but more often than not the
| people in question are not really stupid. What I came to realize
| seems obvious in hindsight: They lack the education to do their
| jobs right. Question really is, if there is any education that
| even builds the right foundations for that. If I look at
| something like [1] I get a chill down my spine, in return I
| managed to finish my buzzword bingo card (again).
|
| [1]: https://www.wgu.edu/online-business-degrees/management-
| leade...
| dakiol wrote:
| Worst manager I had was a software engineer with 8 years of
| experience as engineer and 2 years of experience as manager.
| Knew enough about software engineering and so he was involved
| in almost every technical decision. Knew little about
| management.
| muskmusk wrote:
| I an not sure these fairly one dimensional views are useful.
| Completely agree with the premises that it is the managers job to
| know what their people are doing. I have also worked at companies
| where the managers weren't doing their job. I can also completely
| see how an overfocus on metrics kills an otherwise good company.
|
| I don't agree with the conclusion though: metrics are bad.
|
| In software, in theory, you don't need metrics. You just write
| good code that does what it needs to do. Add tests to prove it,
| you are good. In reality though everyone agrees that metrics are
| a good thing to have. Why do we need them? Complexity and
| sometimes we just make mistakes. We could write software that is
| very close to bug free, but then we move at aerospace speed. Not
| always optimal.
|
| Software metrics come with all the pitfalls of management metrics
| like over focus on metrics and not seeing the forest for the
| trees. Yet we still find the metrics useful.
|
| Managers face many of the same problems, so they ask for metrics.
| I don't think that is bad. Being bad at using metrics is bad.
| ozim wrote:
| Blog post is about someone approaching author on "individual
| employee productivity tooling".
|
| So it is not "all metrics are bad", it is "individual employee
| productivity tracking is bad".
|
| On team level and across teams having trends and looking at
| trends before and after some change is helpful and can be done
| only when you have metrics of course.
| swiftcoder wrote:
| > "Peer reviews actually improve things" is about the biggest
| crock of shit that people in tech still believe in.
|
| Hey, it's finally catching on! I stopped writing substantive peer
| reviews years ago, after I realised folks (including management)
| were mostly using them to snipe peers for things like caring
| about infrastructure/security, or just because they were
| foreigners/women/etc.
| kreyenborgi wrote:
| Also, those tools don't show everything. Someone here told/linked
| to a story about this guy who had like 0/100 on their automated
| performance scores, because he was sitting down with juniors and
| asking relevant questions to get them on the right track and
| generally keeping the ship together. People do a lot of work that
| isn't legible to automated tools, but which good leaders can and
| should recognize.
| sevg wrote:
| HN death hug in effect.
|
| https://archive.is/pYG8C
| physicsguy wrote:
| The main issue with code metrics is that they're easy to game,
| and they're not necessarily an indicator of anything.
|
| In my day job I just made a big change across many microservices
| updating a core dependency library, so last week it looks like
| I've done about 50x more work than I have any other week, but
| that's because I scripted the update, it's not a reflection of
| the actual work I did at all.
| d--b wrote:
| > I know that if you go back far enough in these posts of mine,
| you will find some real crap in there. Sometimes that's because I
| had a position on something that turned out to not be very
| useful, or in some cases, actively harmful. This sucks, but
| that's life: you encounter new information and you are given the
| opportunity to change your mind, and then sometimes you actually
| do exactly that.
|
| followed by
|
| > So, my new position on that sort of thing is: fuck them
|
| I always found rachel's articles (is she called rachel? Idk) way
| too opinionated. It doesn't get better with experience
| apparently.
|
| I mean, don't "fuck them"... Maybe, just maybe, there's some tool
| out there in the blue void of ideas, that could potentially help
| managers UNDERSTAND what's going on.
|
| I, for instance. As an individual contributor, I will accept
| everything that is thrown at me. Yet, there are specific tasks I
| totally suck at, and I will slack a lot to avoid doing them. I
| don't like going to my manager and tell them: "I actually suck at
| this, and if you give this task that sounds relatively easy to
| anyone else, I will slack the shit past the deadline for sure."
| So if there was a may that my manager could learn this by
| himself. That would certainly help everyone on the team.
|
| I am not very proud of that particular aspect of my psychology,
| but you know, that's the way it is. I'm highly capable in other
| aspects, so I don't think my employment is questionable in any
| way. There is just this specific psychological thing that maybe a
| tool could help fixing.
| KaiserPro wrote:
| I like that Rachel has clearly expressed opinions.
|
| What I love is that Rachel is aware of them, revisits, and
| explains why a new opinion has been formed.
|
| being able to say "I was wrong, because" followed by "here is
| my new opinion based on what I have learnt" is much more
| valuable than opinion disguised as fact.
|
| Knowing _why_ an opinion has changes is often very valuable.
|
| > Maybe, just maybe, there's some tool out there in the blue
| void of ideas, that could potentially help managers UNDERSTAND
| what's going on.
|
| Maybe, but what the article points out is that slapping a
| metric on something and saying "this is performance" leaves you
| with a massive quantisation error. If you have a simplistic
| metric, then people will optimise for it, often simplistically.
|
| The other thing the article points out is that "peer feedback"
| is often not a useful way to help people. If you were to put
| your point about those specific tasks in your own feedback, or
| someone wrote it about you, it would form an indelible mark on
| your record. Because it'll probably be the only tangible and
| _actionable_ bit of information, you manager will overindex on
| that.
| dambi0 wrote:
| I agree. It is always commendable to face the realisation
| that our previously held actions or opinions are limited.
| Even more so to do so publicly with the hope the experience
| can help someone else.
|
| On the other hand, we are told that these previous actions
| were actively harmful. Perhaps given this some degree of
| apology to those that might have been impacted would be in
| order.
|
| The final sentence of the article is quite illuminating. I
| wonder whether that would have changed were the metrics
| useful in identifying relative work performance.
|
| It's a courageous and commendable article either way.
| welder wrote:
| > Once again, if management is too stupid to notice what's going
| on, they deserve every single thing that will happen when it
| finally "hits the fan". Make them do their own damn jobs. You
| have enough stuff to do as it is.
|
| Management isn't stupid, it's just a symptom of large companies.
|
| - Yes, peer reviews don't work.
|
| - Yes, peer reviews push the manager's job onto ICs.
|
| - No, it's not the manager's fault. Take that manager and put
| them in a small company and they'll know their team without peer
| reviews.
| twelve40 wrote:
| A bunch of very different things conflated from perf reviews to
| tools for counting commits (i guess?).
|
| Tools: sure, some metrics are either misleading or gameable to
| the point of being useless. But you'd imagine some tools might be
| actually useful for a manager? Then the perf reviews. Obviously
| everyone hates them. I hate them. But how do you keep large orgs
| of thousands of people with varying motives, moods and ability
| from descending into chaos?
|
| Managers don't spike on technical problems of unpredictable depth
| and don't do code reviews. (I've seen wishful thinking that they
| did, but in practice, they don't). How can they tell if someone
| is genuinely stuck on a harder-than-expected problem or is simply
| full of shit? Verbally ask around for opinions from ICs closer to
| the subject matter? But that's the same or worse as an informal
| 360, or a perf review.
|
| fwiw i'm currently and thankfully not a manager but i kinda see
| why they do what they do.
| InsideOutSanta wrote:
| She links to an earlier article, where she determined that some
| people were "slackers" based on ticket metrics, and then blamed
| these "slackers" for making people who work incessantly burn out:
| "Stuff like this is why the people who really cared later burned
| out."
|
| Assuming the data is correct, the much more likely explanation is
| that working non-stop for your whole shift is not sustainable
| over the long term, and _that_ is what makes you burn out.
|
| But the data probably isn't correct. In German, they say "wer
| misst, misst Mist." I've seen this often enough.
|
| I worked at a major financial supplier whose CEO was super into
| metrics, and fired hundreds of the "worst performers" every year
| based on his spreadsheet. Like clockwork, every year, I saw the
| most valuable people in every team get fired, because those were
| people who had a deep knowledge of the system, and were often
| diverted from doing "visible" work by helping less knowledgeable
| people. They were the ones who trained new hires, who you went to
| when you couldn't figure out how to debug your problem, who wrote
| the architecture documentation so people knew how things worked,
| and so on.
|
| Guess what, none of this stuff showed up in any spreadsheets.
|
| It didn't help that they usually also had worked at the company
| for longer, and had higher salaries, so firing them "saved" the
| company more money.
|
| Unsurprisingly, the software product they sell is an absolute
| mess.
| lmeyerov wrote:
| I agree with the manager-knows mentality for people management
| evaluations of productivity focused on bonuses & firing... they
| should know! ...
|
| ... but disagree from the high-performing engineering org notion
| of individual & team productivity. It's hard to improve technical
| processes when you can't see them. Is some person a 10X'er
| because they write shit code that other people have to refactor &
| fix, rely on other people to take their code to production, and
| don't do their share of code reviews? Is the team slowing down
| because PRs and deploys are slow, testing is manual, and everyone
| is used to it? Are calendars too packed or fragmented? Etc.
|
| Any individual item can seem ok, but a lot easier when you can
| see the issues, reflect as a team, & see how chiseling away
| works/doesn't.
| srvaroa wrote:
| I worked on an internal platform for a large engineering org and
| was responsible for choosing what features we put in.
|
| We had the technical means to track everything from commits to
| reviews, jiras, deploys, etc. Some of our most celebrated and
| impactful features were reporting on Accelerate metrics and
| related. E.g. deploy frequency, size of changes, duration of
| stages in the dev cycle and such.
|
| I set a very inflexible red line: we don't expose data more
| granular than at team level. Ever. No excuse.
|
| Quite a few line managers would come to me asking for "personal
| metrics", and even engineers in the team were super interested in
| building that ("with all this data we could...").
|
| My argument was that these metrics are toxic and invite misuse. A
| second factor was that this misuse would generate mistrust from
| engs against the platform and damage adoption.
|
| Instrumenting an organization thought of as a system is fine. You
| want to see where are bottlenecks, you want to have measurable
| targets for how technical work is done and how it correlates to
| business goals/KPIs.
|
| You want to offer teams metrics of their delivery my process so
| they can take the info and implement improvements whenever they
| see fit, and have a data driven conversation with the business
| (e.g. about the right setting for the carefulness knob)
|
| But teams are the minimum unit of ownership, we stop the
| instrumentation there. Sure, a team's performance ultimately
| links to individuals, but that is the manager's job to figure
| out.
|
| Interestingly:
|
| * only line managers asked for this info, nobody in a
| director/vp/cxo role * the most annoyed by me saying no were
| engineers in the team who wanted to do these features
| regularfry wrote:
| Yes, this is the way. It's better never to gather the
| information at the individual level.
| throwaway2037 wrote:
| This is a great comment. My thought, after reading it: _Why_ do
| line managers want this info? Do you think they have someone in
| mind for promotion, and they are looking for metrics of
| accomplishment?
|
| And, cynically, I would say that senior managers don't care...
| because to them, most hands-on engineers/devs are fungible.
| What is your view about why the upper levels never ask for it?
| madrox wrote:
| As a former line manager, there have been two cases when I
| use metrics: I'm promoting someone, and I like having numbers
| that back up how good they are, or I'm firing someone, and I
| like having numbers that back up how bad they are.
|
| I generally agree with OP, but there are times where as a
| manager you know exactly what is going on with your team, but
| numbers are still helpful.
| marcinzm wrote:
| My cynical view is that's it's to find scapegoats especially
| in companies that have a lot of politics or a lot of PIPs.
|
| You generally scapegoat one level down and then let that
| level push it further down if it can.
|
| So the Directors need team level metrics to find which
| managers reporting to them to scapegoat and have data to
| "prove" it.
|
| Then the Managers need individual level metrics to find which
| engineers to scapegoat and have data to "prove" it.
| hinkley wrote:
| Yo dawg, I heard you like throwing people under buses. So I
| put a bus under yo' bus so you can scapegoat people while
| you scapegoate people.
| srvaroa wrote:
| > Why do line managers want this info? Do you think they have
| someone in mind for promotion, and they are looking for
| metrics of accomplishment?
|
| Nah, you don't need to assume malice :)
|
| Most times it was managers with good intentions, not
| realizing that those metrics were either pointless (e.g. how
| much code / commits does $person do), or toxic, in the sense
| that it leads the team to game metrics, that it prevents the
| manager to actually understand _why_ the values are what they
| are, that it opens the risk to link them to promotions and
| perf reviews etc.
|
| Explaining them all this was generally enough!
|
| > And, cynically, I would say that senior managers don't
| care... because to them, most hands-on engineers/devs are
| fungible. What is your view about why the upper levels never
| ask for it?
|
| Actually that wasn't the case. AFAIK (I left at some point,
| but kept a bit in touch with former colleagues) upper
| management started using some of those metrics to set
| organizational objectives.
|
| Again, same argument. You don't need to assume malice.
| Management has a legit interest in engineering productivity.
| What happens most of the time is that they don't know how to
| measure it in an effective way, or how to use it to drive
| organizational change. Providing guidance is part of your job
| as a Platform eng.
| ebiester wrote:
| So, it's a bit more than that. Let's say I've identified
| someone that I can't figure out what they're doing. They're
| just going slower than I expect given what I understand of
| the work. (I was a professional programmer for over 15 years
| before management, so this is based on the expectations of a
| former practitioner.)
|
| Now, why is that? The first possibility is that they ran into
| a string of tickets that were just harder than we expected at
| the outset, and it's a statistical anomaly. A second
| possibility is that this person takes the hardest of the
| tickets, and anyone would struggle. A third possibility is
| they are taking tickets past their capabilities as a
| developer and aren't getting the help they need. In this
| scenario, they're a capable performer, but are need help to
| get to the next level. Maybe they're junior, or they're a new
| employee. If they keep taking these tickets, they will grow
| and their performance will jump. In these cases, you just
| keep monitoring.
|
| In the middle case, they may have transitioned to a team or
| project that is a bad fit, and would thrive on another team
| or an adjustment to what they're asked to work on. They may
| be a front end specialist that was expected to pick up back
| end tickets and struggled from the start. Or, they may be in
| a temporary dip due to personal circumstances.
|
| Then, you have the negative cases. Their work ethic might be
| insufficient. They may just not be good at their job and may
| not ever be able to match the performance at the pay grade
| and seniority they were hired. Or, you may have a good
| bullshitter on your team and your numbers tell a different
| story.
|
| The numbers will tell you if this is a temporary dip. The
| numbers will tell you if their current output is in line with
| the rest of the team. From there, the hard work starts.
|
| If you don't have those numbers, it starts looking like a lot
| of status updates and micromanagement.
| ebiester wrote:
| Note: remember I am condensing the real work into a few
| paragraphs. Of course I know it's much more nuanced than I
| am making it here. This is a surface level treatment.
|
| Also note: Most managers end up doing a lot of part time
| jobs, of which performance management is a relatively small
| part. If my primary job was performance and task
| management, that would be a very bad use of resources for
| the company.
| nemo44x wrote:
| Agreed. And "personal metrics" can also end up having a lot of
| consequences that were not planned for. Incentives are tricky
| that way. There's always a long tail of things that need to get
| done on occasion that doesn't show up in these types of metrics
| and it becomes difficult to find takers when everyone is
| optimizing themselves around the core metrics as bonuses,
| promotions, and even keeping your job in today's climate could
| be determined by those. It also makes allocating load to play
| to contributors strengths (which is often what they enjoy most)
| far more difficult.
| srvaroa wrote:
| Yep, this is an important point.
|
| We wanted the metrics to create the right set of incentives
| to make people improve the right parts of the system.
|
| For example, we did present deploy frequency prominently.
| This gets people to see it, managers to want their team to be
| in the upper percentiles, etc. which drives a set of
| practises that, in general, and backed by research, are
| beneficial.
|
| One of my favourite features was putting two graphs together:
| size of PRs vs. time to review. Time to review went up more
| or less linearly to size of PRs, but past a certain threshold
| (different per team!) time to review dropped sharply with
| larger size of PRs. This made for a good conversation to
| topic with teams that sets the right incentives for smaller
| PRs, iterative development, etc. (and it happens to correlate
| with deploy frequency).
| hinkley wrote:
| Might also suggest a size limit for PRs. Theres always that
| Golden Child who gets away with things because they are
| prolific. But they tend to screw up architecture because
| they make too-big moves that discourage feedback and
| negotiation.
| hinkley wrote:
| I've helped build out or steer these sorts of systems a number
| of times and usually management behaves themselves during the
| adoption and honeymoon phases but then erode the trust later on
| by trying to use the system to determine PIP or promotion.
|
| Devs who have seen this behavior before tend to push back hard
| on adoption, and then invest the absolute minimum effort in
| using these tools. The tools tend to be built wrong often
| enough to encourage that slide into toxicity. There's an amount
| of using a tool where it improves your work experience, and
| then an additional amount that improves the team experience,
| and then beyond that it's doing your manager's job for them and
| self-reporting/narcing.
|
| I'm trying to build a tool at the moment that has had three
| focuses due to different sources of inspiration. First it was
| going to be Trac (a project management tool and wiki that is so
| simple it shouldn't work, but somehow does) with bits of
| Jenkins. Bamboo has thousands of features and integrations
| where it should have hundreds. All those integrations make
| reproducing a failed build locally difficult or impossible. The
| bones of a build process should be in the build scripts and
| dependencies, so you can run them locally. The build tool
| should schedule builds, report status changes, collect some
| release notes data, and track trends with grafana charts and
| that's about it. I also want something running in each dev's
| machine to boost system performance and do some of the teamcity
| features for trunk based dev like push-on-green-build. I just
| miss how distilled Trac was, but it had some problems with
| plugins and git support.
|
| That sat on the Some Day Shelf behind two other projects until
| I read Cal Newport's Deep Work, and then Slow Productivity.
| Then it became more user oriented. Atlassian has about three
| per-user dashboards that I'm responsible for juggling all day,
| and that is tragicomically stupid. I'm terrible with this sort
| of juggling but have coworkers who don't check the PR list ever
| - you have to pester them to look at PRs, week in and week out.
| If I'm doing deep work I don't want preemptions except in
| specific circumstances (like I broke trunk). But when I come up
| for air I need a cheap gestalt of what I've missed and what
| people are expecting from me. Show me all the PRs, and my red
| builds and open tasks in a single view. Allow some low priority
| alerts through. And that can be facilitated by building a
| pomodoro straight into the dashboard and information hiding
| during deep focus moments.
|
| I have some family that was recently diagnosed as
| neurodivergent, and the thing about YouTube is that your
| suggested videos get influenced by what other people in the
| house are watching (particularly if you're not logged in on a
| device). ND people of all types have a lot of coping mechanisms
| to function within other people's expectations (eg work and
| responsibilities) and to mask. They get both barrels when it
| comes to being judged poorly by toxic management tools because
| their variability is so high. Best performer one day, second
| worst the next. And this is nowhere more true than with ADHD.
| And the worst of it is that almost nobody will go harder and
| farther than an ADHD person during a crisis. They can
| hyperfocus during rare moments but most reliably due to an
| emergency (self created, like a paper due tomorrow, or
| externally driven, like servers on fire). They also innovate by
| drawing connections nobody else sees between different
| disciplines.
|
| But they're the first on the block when toxic metrics kick in.
| And the productivity tools they objectively need more than
| anyone else on the team seals their fates, and thus they either
| don't use them or use their own, which are similarly poorly
| integrated, which leads to more plate spinning which they are
| terrible at.
|
| So what finally got me ass-in-chair in front of a keyboard was
| realizing that if this is two tools instead of one, you can
| keep some of the productivity data _on the employee's machine_
| where it can help them with time management and self-
| improvement but not self-incrimination. Then you can cherry
| pick and clean up the narrative of your day or week before you
| self report. Have private tasks on your machine that may look
| embarrassing to others (like remember to drink fluids, eat
| lunch, call the dentist, tasks you're skunkworking).
| konschubert wrote:
| It is a natural desire for upper management to want to know if
| the people in the company are working hard and effectively.
|
| But that is the job of middle management to know. And if upper
| management cannot trust middle management to give them honest and
| good feedback on this, then they have the option to hire and
| manage better middle management.
|
| > Why? It's surprisingly simple. It's the job of a manager to
| know what their reports are up to, and whether they're doing a
| good job of it, and are generally effective. If they can't do
| that, then they themselves are ineffective, and _that_ is the
| sort of thing that is the responsibility of THEIR manager, and so
| on up the line.
| a_c wrote:
| This post is absurd.
|
| Just because people starting measure the wrong stuff, number of
| PRs, number of lines of code, check in counts, etc, doesn't
| automatically conclude that the act of measuring is superfluous.
|
| If the act of measuring is the responsibility of someone higher
| up, who is even higher? Is it manager all the way up? Do we, for
| instance, conclude that the CEO is ultimately responsible, and
| every not CEO relinquish the responsibility of knowing any
| measurement of performance?
|
| Aren't we all CEO of our own life?
| hcfman wrote:
| Are there any tools to measure the performance of managers?
| zem wrote:
| there's a scene from the tv show "suits" that has always stuck
| with me:
|
| the show is set in a law firm, and in this particular episode
| they needed to lay off some of their associates. a young, newly-
| promoted lawyer was tasked with drawing up a list of the
| associates and marking the ones who she felt should get the axe,
| based on their performance. so she comes up with some metrics,
| goes through the associates' work, and ranks them based on the
| resultant numbers, saying that the bottom few could be let go.
|
| there is one employee, brian, who ends up near the bottom of the
| list. a more senior person takes her aside and asks why she
| recommended brian be laid off, so she brings out the metrics and
| rankings and points to him near the bottom. the senior person
| asks "okay, so who are the top associates in your list? can you
| point them out on the seating chart?". turns out, the top five
| associates were all brian's neighbours, and the reason was that
| he was really good at helping people when they were stuck with
| something. but of course that affected his own individual
| contributor numbers, and there were no metrics for "helped
| someone else out but didn't get credit for it".
| Shatnerz wrote:
| I wouldn't be surprised if that was directly adapted from the
| anecdotes of Harry Nyquist at Bell Labs [1].
|
| """ After crunching a lot of data, they found that the only
| thing the productive employees had in common (other than having
| made it through the Bell Labs hiring process) was that "Workers
| with the most patents often shared lunch or breakfast with a
| Bell Labs electrical engineer named Harry Nyquist. It wasn't
| the case that Nyquist gave them specific ideas. Rather, as one
| scientist recalled, 'he drew people out, got them thinking'"
| (p. 135). """
|
| 1. https://en.wikipedia.org/wiki/Harry_Nyquist
| ryukoposting wrote:
| The cynic in me expects someone to read this and come to the
| conclusion that what they really need is _more data_ to
| improve their review process. Clearly we need to know who 's
| eating lunch together!
| blitzar wrote:
| The cynic in me expects poor performers / low contributers
| who read this come to the conclusion that they are the
| Harry Nyquist of their organisation.
| blub wrote:
| This by the way is an excellent argument against home office
| for professions where innovation plays an important role.
|
| I don't think we'll ever see a Wikipedia quote saying "the
| only thing productive employees had in common is that they
| were hanging out in a Microsuck Teams chat room".
| vdvsvwvwvwvwv wrote:
| Not entirely convinced. The tradeoff is in-office you need
| to sit next to someone. Remote you can talk to anyone in
| the world. But it is the role of good WFH culture to avoid
| siloing of people.
| lazide wrote:
| Except you don't _actually_ talk (as in have a real
| conversation) with anyone on Teams.
| danaris wrote:
| Maybe _you_ don 't.
|
| I've never had any trouble having real conversations on
| online platforms, whether for work or otherwise.
| lazide wrote:
| Research shows, that is about as accurate as saying a
| Twinkie is real food.
|
| Not _completely_ wrong, but...
| danaris wrote:
| [Citation needed]?
|
| I've not heard of any research that shows that it's
| _impossible_ to have meaningful conversations on these
| platforms.
|
| And please note the distinction between "it is impossible
| to have such conversations" and "some people (especially
| less tech-savvy people) have a harder time having such
| conversations" on these platforms.
|
| Teams/Slack/Discord/etc is just another communication
| medium. Once our society has, collectively, had more of a
| chance to get used to them, and once we're no longer
| dealing with an entire generation who were bad managers
| before the personal computer even _existed_ (
| </hyperbole>), I wager you'll see a lot less complaining
| about the medium itself.
| jsight wrote:
| TBH, I've been on teams where the chat was a constant
| stream of activity. It works really well and involves a
| lot of people that might not be involved in decisions
| otherwise.
|
| I've also seen the room be quiet way too much on some
| teams. This is always bad, but hard to fix.
| starkparker wrote:
| The worst is when the team chat rooms are quiet because
| each member is in several private rooms or group-chat
| conversations doing the actual work in there.
|
| Regardless of the reasoning, it's toxic to WFH/remote
| work, even in the short-term. And it's outright sabotage
| in the long run when it's time for someone who wasn't
| invited to the "correct" chats to onboard a new hire who
| ends up needing some context that exists only in someone
| else's private chat.
| vdvsvwvwvwvwv wrote:
| I try to move into team chats. If I have a private chat
| that ends up with useful info I will dump it on
| Confluence. Keep things searchable!
| Yizahi wrote:
| In my very limited experience this happens when managers
| (above team leads) insist on being present in chat rooms.
| No offense to any manager in this topic, I know that you
| mean no harm in 99.9% of cases and that you do want to
| make things better, but honestly your presence creates a
| chiller effect. Jokes are no go, because who knows, maybe
| this one will be interpreted badly. Local questions are
| no go, because you can't ask them during work time (he's
| slacking!), you can't ask anything which can even
| remotely be treated as improper. Can't show that you lack
| knowledge in things which should be obvious, can't banter
| about colleagues or about work in non-positive way. And
| the list goes on. We have a chat with 100 people which
| started as a meme and joke one, a lot of people were
| posting funny stuff there. Now the last meme picture
| posted there in mid october, and the second to last was
| in august. And the only people posting there at all, even
| sirius stuff, are the 3-4 teamleads very close to the
| management. Same shit in the chat of immigrants, we have
| a quite a few semi-permanent relocants on the projects,
| but manager is not one of them and is still present in
| that chat room. No one posts there, everyone talks either
| behind the scenes (because there are a lot of questions
| for people in new country) or in the independent big
| chats outside of the company.
|
| And again, it's not like our managers are bad, quite the
| contrary, they are very good professionally and
| personally. And we don't have layoffs. But people still
| won't talk in the presence of even mid level management,
| it's an instinct of sorts I guess :) .
|
| PS: this is only about informal optional chats. All work
| chats are never hidden or avoided. We divide them by
| program, Slack for work and Telegram for fluff.
| AgentOrange1234 wrote:
| Fair enough.
|
| As one potential mitigation, I've consistently had deep
| mentorship conversations over the phone. For me, I think
| voice-only is actually much better than in person.
| throwaway2037 wrote:
| > For me, I think voice-only is actually much better than
| in person.
|
| This is interesting. Can you explain why? To be clear: I
| don't doubt you, but I have never seen a comment so
| specific about this matter. I would like to learn more.
| For one, I assume you said "voice-only" _specifically_ to
| exclude video calls, which are a special kind of hell,
| when compared to in-person discussions. (Staring at
| yourself and only seeing the other person 's head always
| struck me as a bit weird / artificial / Uncanny Valley-
| ish.)
| regularfry wrote:
| Not necessarily. There's no clear indication that you need
| full time (or even an amount of time measured in "X days
| per month") to get these benefits.
| Yizahi wrote:
| Did you or anyone else has actually observe any such
| processes? I mean employees A and B meeting at any place
| which is not a workplace or any of them (because meeting at
| workplace means one of the pair has come specifically to
| another, and that is mostly equivalent to calling that
| person by phone, on full remote) and there spontaneously
| talked about work topics generating previously unheard idea
| useful for the company?
|
| If the and answer is yes, then what was the rate of such
| encounters per number of employees?
|
| And finally - honestly answer yourself - does this
| minuscule probability worth the ~30 full awake days in
| every years of life, of every employee? (2 hours commute
| per 250 days in a year, then divide by 16 awake hours per
| day) For me the answer is obvious - it is not even remotely
| equal in value to such a gigantic time waste. If that super
| brainstorming even real at all. Personally I've never
| observed this.
| thyrsus wrote:
| Anecdata: I work from home and spend about a quarter of my
| time helping colleagues.
| sevensor wrote:
| I think you're wrong, but in an important way that deserves
| discussion, so please enjoy an upvote. First of all,
| innovation and productivity are not necessarily connected,
| and in many cases innovation is not at all what management
| wants or the business needs. (Using Jira is a sure sign
| that management does not want innovation, yet we see it in
| widespread practice.) Second, the quality of the colleagues
| males a huge difference. Not every workplace is golden age
| Bell Labs. Most people don't have a Nyquist down the hall.
| I used to sit shoulder to shoulder with a guy who had
| YouTube videos on his second monitor all day long, to help
| him focus. Evidently it worked for him, he was a very solid
| contributor, but neither my productivity nor my ability to
| innovate were helped. (Like Jira, the open plan office is a
| sure sign that management values observable units of effort
| over either productivity or innovation.)
| shadowtree wrote:
| Counterpoint: comp.os.minix
|
| There are famous groups/chats that allowed the creation of
| stupendously important software.
| hinkley wrote:
| I have been accused by a number of people who like me of
| "asking good questions" and of asking difficult questions by
| people who don't.
|
| I sucked at school until someone opened up the idea for me
| around third grade that how the curriculum is taught is just
| the teacher's opinion, not a law, or a religion. If you can
| reframe the material in a way that makes sense to you then do
| so. I ended up spot-tutoring a bunch of people over the years
| because I would hear them complain about how the material
| made no sense and I would swoop in and say, "yeah how they
| teach this is bullshit, have you tried thinking about it this
| way?" Which validates their frustration and then gives them a
| life raft.
|
| That kind of reframing to keep up can become reframing to get
| ahead. I went from Problem Student to grade school
| "valedictorian", to polymath. Years ago we were all fixated
| on the trap of Expert Beginner and I would half-joke that I
| was instead an Expert Journeyman - able to quickly get to
| adequate instead of mediocre in a new discipline. And these
| days I think that may be what "polymath" is most of the time.
| Just knowing what the next question is to ask to keep going.
| The big breakthroughs come from people who become experts in
| most fields, but these same sorts of people also get pretty
| good at music or painting or writing as a hobby. As good or
| better than mediocre professionals.
|
| The first time this happened to me in a professional setting,
| a coworker was stuck on a SQL problem and insisted I pair
| with them to help debug it. I told her I've never touched
| SQL, just worked on some bespoke data processing. She didn't
| care. Come here anyway. And I'll be damned if I didn't help
| her find her problem by just asking her what this part does
| and that part does. Why does this work that way? And I
| started writing SQL a couple weeks later, substantially off
| of just that interaction, bolstered by what first generation
| search engines could scrape together.
|
| And the thing is when everyone asks you questions and you
| don't break their trust, you quickly learn where all the
| bodies are buried in the project/org. Which is a valuable
| asset for someone wishing to become a lead or staff engineer.
| I became lead by popular vote most times, rather than an
| actual game plan to get promoted. I just did what thought
| needed to get done and was within my abilities, which looks a
| lot like leadership, especially if management doesn't have
| that quality. Port in a storm, that's me.
|
| But I've never ever completed the most stories or features.
| I've occasionally fixed the most bugs, the most performance
| issues, or workflow problems. Is calculated I saved forty man
| hours a week for the team on code-build-test-push ergonomics
| and my shitheel boss was still made about my productivity
| those two quarters. I could not show up to work and still be
| contributing 8 hours a day, dummy.
| throwaway2037 wrote:
| I have posted a few times here about this issue. Honestly, you
| need to protect yourself first. If your line manager is
| anything less than amazing and very involved, then helping your
| teammates "too much" is an easy way to miss promotions and pay
| rises due to lower year-end ratings.
| CSMastermind wrote:
| As someone who has both built and used different off the shelf
| tracking tools I've always found that they were terrible for
| evaluating individuals but great for evaluating teams (and by
| proxy the manager).
| rrrrrrrrrrrryan wrote:
| > there were no metrics for "helped someone else out but didn't
| get credit for it"
|
| Employees should be evaluated, by their peers, their managers,
| and their subordinates. Wherever possible, the evaluations
| should be qualitative rather than quantitative.
|
| Trying to automate performance evaluations and boil your
| employees' contributions down to numbers in a report is both
| idiotic and inhuman.
|
| Everyone knows the terrible team members, and everyone knows
| the outstanding team members. If you need information to inform
| layoffs, promotions, or raises, the best way to get the
| information is to just ask.
| the_gipsy wrote:
| If you're at the point that you _need_ 360 reviews (mind you that
| many companies do them but don 't _need_ them), because you don
| 't trust middle management to not play politics for themselves,
| then your company culture is already rotten and will not get
| fixed by doing 360 reviews.
| axegon_ wrote:
| I have a bunch of thoughts on those in general. I agree, a good
| manager should know who is doing what and if not, why. It could
| be laziness, it could be that the rest of the team is completely
| insufferable and they are only doing the bare minimum until they
| find a better job(I've been guilty of that one) or 20 other
| factors, who knows.
|
| But all the associated tooling that has been created over the
| years for figuring out who is doing what are insanely counter-
| productive. Assume you work in a large corporation and you are
| tasked with "implement and deploy X". Fine. But in order to
| deploy it, you need to rope in a dev ops, sec ops, 3 other people
| to sign it off and 10 other tickets being tossed around between a
| dozen people which are nearly impossible to track. All while your
| manager is sitting there, looking at this one ticket assigned to
| you and be like "tf?"
|
| So no only do you have to effectively manage a process involving
| 10 people but you also need to find a way to show that you are in
| fact trying your best to make progress. Keep in mind that
| everyone else working on your problem are also involved in 4
| other things in each given time.
|
| For a manager to be able to work through that, they must be ready
| to put the needs and comfort of the people they manage before
| their own and be ready to make some internal enemies in the
| process. So far I've had two such manager in my whole life and it
| was a genuine pleasure to work with both of them - everyone was
| doing the absolute best they could 100% of the time. In both
| instances, we had 0 tools to monitor who is doing what - the only
| tool we used was gitlab with merge requests, even if the company
| enforced Jira. What the managers did was manage Jira on their own
| completely and not bother developers at all with it. As a tech
| lead, I did not even know where to access Jira. And when we got
| asked how come we get everything done a month and a half before
| anyone else, the simple answer was "f-bureaucracy". Even when it
| came to dev ops and stuff, we had become friends with some of
| them and had an internal rule: "Before sending an email, send me
| a message in the chat so I know what's needed and I can prepare
| myself, send us an email and send me the ticket id you get. We
| love working with you cause you come with clear instructions and
| no bs". This is an exact quote from a devops in Ukraine who had
| around 150 words in his English vocabulary. And whether it was a
| kubernetes cluster, network configuration, upgrades, downgrades,
| backups or anything else, the most we've ever had to wait was
| less than an hour. You don't need Jira to know when someone is
| slacking, whether you are a manager or someone else - you can't
| hide that and we've had such people on those teams, it's up to
| the manager to address those.
|
| This is of course large corporations. In smaller ones, it's less
| straightforward and even more in the hands of the managers. The
| first question you need to answer is whether those companies
| aspire to be large corporations while having 50 employees(in
| total, I don't mean in the tech departments). If that is the
| case, then it's the same as what I described above and if you
| pull she short straw(the way I did at my old job), end up with an
| absolutely insufferable, egocentric team and a manager who's
| policy was "don't start conflicts, no matter what, sweep any
| confrontation under the rug as fast as possible".
|
| The second type is the Jira(and jira-like) obsessed managers in
| small companies where acting as a developer, dev ops, infosec,
| network admin and hardware admin are the same thing for everyone
| involved. This is fine to my mind, but we get back to "implement
| and deploy X". Do you want me to log every action I do, while
| doing a ton of R&D, setting up a redis cluster, kafka and 3 other
| things or should I focus on getting it done asap because those
| things are mutually exclusive.
|
| And the last type, which appears to be my current job - "0
| nonsense", "nothing will ever be perfect", "we know we are fixing
| our car while driving it" are all 100% acknowledged by everyone,
| management included. A small board with what is needed, "whenever
| you have time, figure it out". It may sound bad, but it works
| astonishingly well.
| koliber wrote:
| Normally Rachel writes well and I am a big fan. In this article,
| I have a hard time understanding what she is trying to say.
|
| I agree with the general sentiment that metrics are not a
| panacea. Managers need to put in work to do their job, instead of
| leaning blindly on tools like metrics. IC's need to do their work
| instead of expecting managers to prop them up.
|
| I'm guessing that this is what the article is trying to convey.
| What I read though is a complete 180 flip into "no tools are
| helpful", and "don' help anyone" territory. I don't agree with
| that.
| devjab wrote:
| I didn't read it as "don't help anyone", I read it as "don't
| help managers". As someone who's worked both sides I agree, not
| least because I very efficiency tool I've ever been exposed to
| was bullshit. To me most of these things, including peer
| reviews and retrospectives and whatever else the pseudo jobbers
| and consultants have peddled for two decades now don't work.
| Then again most organisations could probably get by with half
| their current middle management staff if we removed all these
| metrics and audits and actually let them manage. We won't do
| that of course.
|
| Somewhat hilariously I was a manager during Covid, and as such
| I saw the metrics which showed that every worker group in the
| city I was working for was happier and more productive. Except
| for middle managers and the various positions they are in
| meetings all day. Interestingly productivity was way up despite
| people spending significantly less time at their computers.
| mikeshi42 wrote:
| > Somewhat hilariously I was a manager during Covid, and as
| such I saw the metrics which showed that every worker group
| in the city I was working for was happier and more
| productive.
|
| I'm curious how productivity was measured for that. I assume
| happiness was self-assessed, but I'm also surprised that'd be
| up given how much of a rollercoaster a time that was just in
| general.
| BlueTemplar wrote:
| I guess it ought also be pointed out that these days *a lot*
| of jobs in general are harmful because increasing economic
| growth, accelerating in the process the destruction of the
| biosphere and depletion of natural resources (both of which
| became a concern half a century ago at least).
|
| Yet of course it's extremely hard to make people understand
| that, when these are things that they, their families, and
| even their communities or their polities have been doing for
| generations, and are directly relevant to their short term
| livelihood (which they see as medium or even long-term
| livelihood, as "short term" here means decades).
| koliber wrote:
| > "don't help managers"
|
| Managers are people too, despite of what Dilbert will have
| you believe. They need help, support, and tools.
|
| It's true that many tools and frameworks are sold as magic
| pills that solve all the problems. Metrics are one of those
| tools that are often misrepresented. I think that many of the
| tools are helpful, if used skillfully.
|
| You can't manage what you can't see. You see your team
| through your direct interactions with them. You see what they
| do through the artifacts that they produce. You learn about
| them from others - hear-say, praise, complaints, and gossip.
| You also get another perspective through various metrics. You
| need to combine multiple ways of seeing a team to have a
| more-complete picture. Take any of them away, and you're a
| little more blind.
|
| I remember when I first transitioned into the manager role.
| There was so much that I needed to learn. Some of the tools
| gave me insight into what is happening on the team that I
| really don't get to observe directly. However, none of the
| tools did my job for me. I learned by reading, using new
| tools, and experimenting. Over time I honed my ability to be
| able to understand what my team is doing well, and where it
| needs help. If someone took away ALL the metrics-based tools,
| I would have fewer ways of evaluating my team.
|
| Managers need as much help as anyone else to do their job.
| This also involved introducing new tools, and teaching
| managers how to use them. In a large part, that is their
| manager's job. Sometimes they call me to help.
| canterburry wrote:
| Engineering manager here...
|
| I understand the sentiment around that managers should do a
| better job and many metrics based tools miss out on people
| performing necessary tasks that won't show up in the metrics. The
| people I have managed who fit those criteria were very obvious
| and it was known their code delivery was suffering because they
| were helping others. The good players always stood out.
|
| The areas where I had wished we had comprehensive people metrics
| were frequently for remote employees on drastically different
| time zones where daily regular interaction was difficult or where
| there was some clear under-performance but the WHY was unclear.
|
| It can be very tricky being a manager and to getting to the
| bottom of WHY someone isn't performing. Should a PIP be
| necessary, it's very important to identify specific behaviors
| that need improvement.
|
| During 1:1s, under-performing employees will provide the most
| vague explanations, copious excuses, blame other factors. Even
| when I've cross checked with their peers, no one wanted to really
| give any clear answers as to why something was late, had abnormal
| amount of issues, or development was standing still altogether.
| People were clearly avoiding the questions.
|
| Everyone here seems to assume direct reports are always honest,
| open and transparent. They are not, and especially when things
| are not going well.
|
| Manager need a way to verify what they are hearing. Do the
| metrics support the claims, or is someone who's slacking just
| BSing you. It's not where you get your primary information on
| performance, it's what you use to verify your own suspicions or
| find supporting evidence.
|
| For example, an employee who has a history of not testing their
| code and has in their development plan to improve on that. During
| 1:1s, the question comes up and invariably, every time I've been
| positively assured they are making great progress and everything
| is being tested.
|
| I now have 3 options: 1. perform my own review of their code to
| verify their claim 2. get a high level metric that testing has
| improved 3. trust what they are saying, move on and throw the
| dice that everything will be fine
|
| Option 1 is obviously the best but very micro-managerial and will
| clearly demonstrate I don't trust their word, further
| demotivating the individual
|
| Option 2 would be a good place to start unless employee gives me
| further reason to go with option 1
|
| Option 3 is what shitty managers do
| darylteo wrote:
| In this model of "managers know what their reports are doing" how
| does one gain insight into overall engineering health from a high
| enough level (say, engineering manager / CTO)
|
| How does a engineering manager know what their managers are up to
| in order to get an understanding of what their manager's team
| members are up to? Even worse if you have a large enough
| organisation where you may have managers managing leads who
| manage teams?
| tpxl wrote:
| Mayhaps the CTO would deign to do their work and ask their
| direct reports about the status, then compile a report with the
| desired information? The direct reports would obviously ask
| their reports, and so forth, until you get to the lowest rung
| on the ladder.
| ChrisMarshallNY wrote:
| My GH activity graph[0] is pretty full, but some of the days with
| the _least_ checkins are ones where I did the most work.
|
| I had a day like that, a couple of days ago. I spent a
| significant portion of the day, building experimental approaches
| to handling an issue, but reverted, at the end (the experiment
| did not yield the results I wanted). That is fairly common.
|
| Also, a big part of my reflective refactoring, is reducing
| codebase size, like factoring out common functionality into
| protocol defaults, and/or base classes. That can take quite a bit
| of time.
|
| So LoC/Time is pretty much a worthless metric.
|
| And if you cloc my codebases, the comments/code ratio is usually
| about 50%. Documenting my code[1] can take a lot of time, as
| well, and is actually a fairly important part of refactoring, as
| I often find issues, when I have to explain what's going on.
|
| [0] https://github.com/ChrisMarshallNY#github-stuff
|
| [1] https://littlegreenviper.com/miscellany/leaving-a-legacy/
| BlueTemplar wrote:
| And that's not even starting with the questionable morality of
| using GitHub in the first place (~ after Microsoft bought
| them)... (especially for non-US developers)
| ChrisMarshallNY wrote:
| Eh, I don't lose any sleep over it. There's bigger fish to
| fry.
| BlueTemplar wrote:
| Yeah, leaving aside other concerns about platforms,
| Microsoft, and the USA, I too want to stress how GitHub is
| problematic in GP's <<some metrics are bad>> sense : the
| social networking aspect, stars, number of projects, and,
| as you say, number of contributions and number of lines of
| code.
| ChrisMarshallNY wrote:
| Yeah, that stuff is pretty ridiculous, but I think a lot
| of it predates Microsoft.
|
| There's a big school of thought, that "gamifying" things,
| brings "engagement" (the holy grail of SV).
|
| I'm old and cynical. It doesn't really do much for me,
| but it is a well-integrated hosted solution, and that's
| what I get from it.
| juped wrote:
| well, yeah, they are themselves goodharting the metrics
| that vcs use. it's fake metrics all the way down
| jackhiggs wrote:
| I'm an Engineering Manager for a large company and have been for
| a number of years. For our large team we will rank the team based
| on perception of managers. After that we will then manually
| collate coding stats from all repos we work on. Unfortunately for
| the consensus view here and in the article, you get a 100% hit
| rate on who you think poor performers are and the lowest coding
| contributors.
|
| For top performers it's more nuanced. In general they will be top
| of the contribution stats but sometimes if they're doing R&D or
| hard work then the stats are not very meaningful. But that's why
| we don't rely on them.
|
| So metrics have their place to inform and color existing
| perception. But they will rarely change perception completely.
| aswerty wrote:
| Qualitative and quantitative approaches together inform us
| best. Probably not the most eye opening of statements.
|
| But I think as you indicate, qualitative generally paints the
| picture, and quantitative validates it.
| LaGrange wrote:
| > Unfortunately for the consensus view here and in the article,
| you get a 100% hit rate on who you think poor performers are
| and the lowest coding contributors.
|
| This is circular logic. If you measure that "coding
| contribution" nonsense, people's "performance" will be
| perceived based on that, _especially_ by their direct managers.
| AgentOrange1234 wrote:
| I've seen cases where folks completely checked out and were
| contributing nearly nothing, making no commits, writing no
| code, and faking it at standups. Simple metrics can help
| surface cases like this.
|
| I agree that it's something a manager could over-index on.
| I'm not sure how to avoid that beyond adopting a mindset of
| "this is noisy data that sometimes gives you important
| insights."
| JohnMakin wrote:
| > I've seen cases where folks completely checked out and
| were contributing nearly nothing, making no commits,
| writing no code, and faking it at standups. Simple metrics
| can help surface cases like this.
|
| Of course we've all seen varying degrees of this - but
| these kind of people can only exist because of terrible
| management. Throwing metrics at the problem just introduces
| a more insidious version of this individual, one that knows
| how to game whatever metrics are used (managers especially
| will do this). I've been on teams where such an individual
| could thrive for years, even with promotions, and on teams
| where such an individual would be outed within a week.
| mrguyorama wrote:
| If you need metrics to see an employee isn't doing what you
| assigned to them, what are you even being paid to do?
| lowbloodsugar wrote:
| Amazing. You just proved her point with data and then drew the
| exact opposite conclusion.
| cromulent wrote:
| Software engineers are constantly investing their expertise into
| the product.
|
| Measurement (if any) should be on the realised gains in the short
| and long term, not the visible investment. LOC, tickets closed,
| hours spent etc can all have negative payoffs.
|
| Unfortunately that is hard to measure, as Rachel points out.
| t-writescode wrote:
| This misses "negating realized losses", which I believe is a
| very important area for engineers to perform in.
|
| Perhaps I am wrong.
| cromulent wrote:
| I guess my point was that the value of a days work is
| realised later, over months or years, rather than on the day.
|
| So indeed, corrective and maintenance work have payoffs.
|
| This would also be true of managers - their work should pay
| off over time, so measuring it in "meetings attended" is not
| a good metric.
| stingerpk wrote:
| I respect the intent behind the article, which as I understand is
| that managers should work closely with their teams and know first
| hand how they are adding value, instead of depending on a chart
| to know that.
|
| However, there are a few problems here:
|
| - There are more manager positions than there are qualified
| managers. So you will always have people who are simply bad
| managers. This is generally more true in larger companies where
| productivity of an individual team is easy to ignore.
|
| - Even good managers are humans and are subject to emotions and
| biases that they don't even realise they carry around. The only
| things which bring objectivity is data and good processes.
|
| - Hybrid or remote work is a larger trend that began much before
| covid, and while back to office mandates might make it seem that
| the trend is loosing steam, it is not. There will be more remote
| work in coming years, and that makes understanding your peers'
| work even more difficult.
|
| So what is the solution? I believe that:
|
| - You should measure events, but you should have the intent that
| you want to "understand" what is going on, instead of policing
| people. Data can reveal a lot, like conflicting work patterns,
| burn-out indicators, problems in communications etc. Not all
| metrics are bad.
|
| - You should combine objective data with subjective feedback, as
| well as more context such as life events (marriage, becoming a
| parent etc) to understand how people work.
|
| - Processes should enhance focus on outcomes, rather than
| activity. Frameworks such as OKRs are hard to implement
| correctly, but they do let you focus on business outcomes. The
| problem with knowledge work is that you cannot measure it with
| activities alone. Trying to bridge OKRs with activity metrics as
| well as subjective feedback can be helpful.
|
| For disclosure, I am founder of a platform called Crewnetics, and
| we are building tools for measuring performance of knowledge
| workers.
| from-nibly wrote:
| > There are more manager positions than there are qualified
| managers.
|
| So? Let companies fail, let the world rot. If people want to
| live indoors they need to learn how to be good at something.
|
| > Even good managers are humans and are subject to emotions and
| biases that they don't even realise they carry around.
|
| Data doesn't solve this it codifies it. Tracking commits is
| PERMANENTLY codifying a commit frequency bias to work
| performance.
|
| > There will be more remote work in coming years, and that
| makes understanding your peers' work even more difficult.
|
| How? Did managers only understand what was going on by looking
| over peoples shoulders? What data did they get by people
| sitting near them? Looking busy and getting stuff done are two
| things that look the same from the outside.
| rco8786 wrote:
| > It's the job of a manager to know what their reports are up to,
| and whether they're doing a good job of it, and are generally
| effective.
|
| I don't think this is mutually exclusive with building tools that
| gives a bird's eye view of what various employees are doing. In
| fact, that sounds like a helpful tool. The ONLY tool? No, of
| course not. And a healthy dose of interpretation is required - in
| the same way that an engineer must look at a datadog dashboard
| and apply the necessary context to interpret anything useful from
| it. Some level of human interaction and empathy is required to be
| a manager. But if I can "know what my reports are up to" at a
| glance rather than interrupting them to ask...seems like a win
| win.
| brainzap wrote:
| It hurts me that my coworkers literally do nothing. Managers need
| a metric, which one, its a secret ;-)
| kasey_junk wrote:
| This is such an on point post.
|
| But I'd add one thing. Peer review is extremely valuable if you
| use it as a tool for career improvement and not as a tool for
| performance review.
|
| To do that though you need 2 things, trust between the peers and
| for it to have no way to impact career progression from the
| companies perspective.
|
| So when I was a manager I'd have a rule that at 4 times a year my
| reports would need to do 2 peer reviews with peers of their
| choice. Preferably over lunch the company paid for. The only
| thing I wanted to know is if it happened or not.
|
| I got mixed feedback on the method from my reports. I think the
| ones who saw it as an opportunity to get real unadulterated
| feedback loved the process, while the rest just got lunch. Which
| is fine.
| blitzar wrote:
| extremely valuable if you use it as a tool for self improvement
| dudeinjapan wrote:
| Can anyone steelman the case for employee metrics and if so what
| are the best ones?
| rgbrgb wrote:
| idk if this is steel, but I think the basic counterpoint is
| that humans are biased. No matter what, you are going to be
| compared against your co-workers sometimes (think layoffs or
| raises). Say your manager has 10% of budget to allocate to
| raises. How do they allocate? What is fair? OP seems to
| advocate for the manager to just know who is high impact and be
| fair. But even if the manager is good and their team is happy
| and productive, there's probably not consensus on what this
| should look like. So it's attractive to codify this process and
| try to remove human bias.
| Buttons840 wrote:
| Companies love to collect their data, and they love their AIs to
| analyze that data. But they ignore the easiest to collect data
| and the strongest AIs available; these AIs are so good you could
| just call them Is.
|
| I've always wanted to see regular anonymous mass surveys of
| employees, about things like project progress and completion
| dates.
|
| Do you want to know when a feature will be finished? You can
| analyze story points and build a fancy burn down chart, or you
| can just ask the people working on the feature. Allow the entire
| team to anonymously predict when the feature will be finished and
| I'll bet you get a better answer.
|
| Anonymity is important because people are easily pressured into
| changing their answers. We've all been asked "how long do you
| think this will take?". "Two months" you answer. Then managers
| pressure you into changing your answer, but usually, no matter
| what you're forced into saying, you still think it will take two
| months.
|
| Why did they ask if they didn't want my answer? Therein lies the
| truth. Companies don't want accurate answers and data, they want
| to see and hear what makes them happy right now.
|
| I don't think most companies would have the courage to regularly
| gather data with anonymous surveys.
|
| But maybe, if one clear-headed and high-level executive wanted to
| force it on the company, they could. They could mandate the use
| of a software tool to do anonymous surveys, and no matter how
| much lower-level managers complained, the team could still
| anonymously say when they actually believe the project will be
| finished. Etc.
| junaru wrote:
| > 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.
| Buttons840 wrote:
| The survey I'm imagining is just "rate the progress of
| project X from 1 to 10 (1 being just started, 10 being
| complete)"[0], and also "rate your happiness from 1 to 10",
| and "rate the quality of the work done from 1 to 10".
|
| This would be anonymous, the only thing that wouldn't be
| anonymous is whether or not an employee has updated their
| survey within the last 2 weeks.
|
| I would absolutely throw that hypothetical lower-tier manager
| you mentioned under the bus. The surveys could have a "rate
| your manager 1 to 10" question too.
|
| I think it would be valuable insight to all levels of
| management. If the team is being death marched, happiness and
| quality surveys would drop. Or, if you see a team deliver a
| buggy project, but quality surveys were high all throughout
| development, then you could tell that the team was
| incompetent and hire/fire/train accordingly.
|
| [0]: Don't ask people to guess completion dates, have them
| guess percent completed and then calculate completion dates
| in the software.
| scruple wrote:
| We get supposed "anonymous" surveys where I work and I see the
| hash at the end of the URL, and we've confirmed amongst a few
| of us that they're unique, and so the assumption goes that it's
| actually not anonymous at all. I don't think I would ever trust
| an "anonymous survey" from an employer to actually be
| anonymous. Maybe if it was hand written.
| Buttons840 wrote:
| If the URLs had all been the same, then would you trust that
| it was anonymous?
|
| Employees could lie about their own happiness, and
| satisfaction with their manager, to their own detriment.
| Employees could also lie about project progress and quality,
| also to their own detriment, because it looks bad if a team
| says "everything is on track, quality is great", and then the
| project runs long and is a buggy mess.
|
| I just think a lot of what a manger does is give progress
| reports, and it's easy for one person to lie about progress
| reports, and then when it becomes clear that the progress
| reports were wrong all along, the manager somehow shifts
| blame to the workers. These surveys would give everyone a say
| in the progress reports.
| scruple wrote:
| I don't see how any deeply honest, earnest feedback can
| come from me when I am told "this is anonymous" and there's
| a 99.999999% chance that it isn't. If it came from a
| position of mutual respect then maybe I'd reciprocate, but
| it doesn't.
|
| It's hard for me to take any of this seriously. Industry-
| wide we're told layoffs have to happen and these same
| corporations go on to post record numbers, far exceeding
| internal and external expectations. Executives are lavished
| with bonuses while many of my colleagues are getting < 2%
| CoL adjustments while taking on more and more
| responsibility _and_ accountability. But also, please, tell
| us what we can do better! We 're _listening_ and we _care_.
|
| So, no, frankly I don't feel like I owe my employer a
| single fucking thing beyond showing up, doing my work, and
| leaving. I certainly don't owe the top-level leadership
| team the truth when they aren't honest with me.
|
| But I want to make it clear, too, that I'm not _lying_ on
| these surveys. But, they 're not getting a full
| accountability from me, from my perspective, either. And
| even if I wanted to give that, it'd be pretty hard when the
| questions are worded in such specific, guided ways and
| there's very little space for providing direct feedback.
| Buttons840 wrote:
| I'm not saying these are the only questions that should
| be asked, or that this should be the only way of getting
| feedback. I suggested questions for a 30-second weekly
| survey. I think longer surveys with more detailed
| feedback should be done periodically as well.
|
| And, if you decide to just always say things are going
| well, then that's what management will see, and the
| status quo will remain. At least until a project goes
| poorly--delivered late and a buggy mess. Then, if I were
| a high-level manager, I would look at the surveys and see
| that the team was happy and believed everything was
| perfectly okay right up until failure, and I would judge
| the team as incompetent, because a competent team would
| see failure approaching long before it happens. I'm not
| saying I would fire anyone, but clearly a discussion
| needs to be had with the team manager, and probably the
| whole team, about reporting problems early.
|
| Of course, if a company wants people to report problems
| early, then they need a culture that responds well to
| early warning signs, rather than the shoot-the-messenger
| culture that is all too common. I do sympathize with your
| frustration for fucked up company cultures.
| nemo44x wrote:
| I would never treat them as anonymous. Expect that even if
| told they are that at some point someone could access your
| answers, for whatever reason they may have. I don't think you
| need to lie on them but I'd probably hold personal criticisms
| back and use a gentle touch. In essence, be positive and
| likeable.
| scruple wrote:
| Yes, I don't outright lie or try to sabotage, or otherwise
| do anything anti-social like that, but I approach it from
| the position that I am in fact standing in a room with an
| executive being asked these questions and if I were in that
| position how would I answer?
| nemo44x wrote:
| The main thing is to be sure to do them and not ignore
| them. They're "engagement surveys" and the first metric
| to determine engagement is if the employee engaged with
| the survey in the first place.
| insom wrote:
| Shopify had this between ~2017 and ~2020 -- every project was
| expected to complete a "health check" every two weeks where
| anonymous participants gave a 1-3 score on various metrics
| including velocity, quality, making good decisions quickly etc.
| You couldn't see the scores until everyone had answered and
| there was cultural pressure towards honesty. All that was
| stored was the average score and optional comments.
|
| If you left comments, it was generally possible to figure out
| who said what based on idioms etc. but they were kept separate
| from the scores anyway.
|
| I thought it was a good system but I'm pretty sure it was gone
| by the time I left in 2023. If nothing else, I don't think a
| system based on that kind of radical candor can survive the
| first or second round of layoffs at any company.
| mdgrech23 wrote:
| This is exactly why deadlines in tech are such bullshit. It's
| my personal experience that more times than not I'm told the
| deadline as opposed to us reaching some kind of agreement. It's
| reasons like that that I have hard time taking it seriously
| when I'm told we're late. It's more like you're "estimate" was
| wrong or you demanded completion date was too aggressive.
| sethammons wrote:
| > "Peer reviews actually improve things" is about the biggest
| crock of shit that people in tech still believe in
|
| Peer reviews are what allowed me to break out of imposter
| syndrome. Realizing that people valued my knowledge,
| contributions, and demeanor while still acknowledging areas in
| which to grow was instrumental in me breaking out and realizing I
| was bringing value
| BobbyTables2 wrote:
| The best managers never speak or think about KPIs.
| perryizgr8 wrote:
| > It's the job of a manager to know what their reports are up to,
| and whether they're doing a good job of it, and are generally
| effective.
|
| Is it wrong to use tools for doing your job? Metrics can be a
| part of knowing what your reports are up to and how effective
| they're being.
| daft_pink wrote:
| I think the issue is that while it's true that the manager shoud
| know if they are generally effective or not, employees should
| also have a decent understanding of what the goals and objectives
| are of the organization.
|
| I feel that there should be an alignment on what the expectations
| are and how people are graded and these tools should be applied
| before the evaluation and information should be provided to
| employess on how they are doing on a regular basis.
|
| I would say that if a manager sucks, it might not be the
| employees total fault, because they haven't clearly delineated
| expectations to the employees.
|
| To just apply analysis retrospectively makes no sense and it
| should be applied regularly, so that people know where they are
| and can improve.
|
| I've definitely worked at organizations that are totally
| unorganized and it's totally unclear what the objectives are and
| they will just call you up and give you different objectives
| every day and then the performance review addresses totally
| different objectives from what we've been actually doing the
| entire period.
| luckydata wrote:
| I read the article and frankly I'm not sure what she means by it.
| madrox wrote:
| I agree with the premise that numbers aren't a replacement for
| actually knowing what's going on, I think there's a false
| equivalency the author has that if you're a manager wanting
| metrics on your people that it's because you don't know what's
| happening.
|
| Metrics are like supporting arguments for a whatever narrative a
| manager is telling. I've used employee metrics to help support
| the case for promotion or supporting my case to HR for why they
| should be fired (I've never fired someone _because_ of metrics).
| It reinforces observation. The time metrics get toxic is when a
| manager starts telling ICs their performance _is_ their metrics.
| A whole host of bad things happen then.
|
| And if you're telling me bad managers will suddenly become good
| managers if you take away their employee metrics, you've got a
| surprise coming.
| datavirtue wrote:
| Collary, only lazy and ineffective managers need employee
| productivity metrics. A good manager wouldn't even trust those
| metrics.
| lowbloodsugar wrote:
| Hope you are doing ok, Rachel. I know you've been doing this a
| while, and likely don't need my advice, but if any of what you're
| writing is about current personal experience then maybe it's time
| to GTFO. The mistake I've repeatedly made is not getting the fuck
| out at the first sign of this kind of trouble.
| stonethrowaway wrote:
| > I know that if you go back far enough in these posts of mine,
| you will find some real crap in there. Sometimes that's because I
| had a position on something that turned out to not be very
| useful, or in some cases, actively harmful. This sucks, but
| that's life: you encounter new information and you are given the
| opportunity to change your mind, and then sometimes you actually
| do exactly that.
|
| Sometimes the content is decent. But this post, and this line,
| hits me as very tone deaf. It's like no deeper reflection
| occurred.
| tqi wrote:
| I certainly sympathize with the underlying sentiment, but this
| post seems to boil down to "managers should be better!" which...
| yes, definitely. But how?
|
| If you're not going to to use metrics (agree that we are very
| limited by what can be measured), and not supposed use peer
| reviews (agree that they can be rife with bias), the only way to
| reasonably expect the median manager to know the ins and outs of
| everyone they manage is to have a small ratio of managers to team
| members. But that means more layers, and people hate that too!
|
| Also let us not forget that the alternative presented ("It's the
| job of a manager to know what their reports are up to, and
| whether they're doing a good job of it, and are generally
| effective.") boils down to "does your manager think you're good"
| which is it's own giant can of worms.
| atomicnumber3 wrote:
| "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.
| dennis_jeeves2 wrote:
| >"managers should be better!" which... yes, definitely. But
| how?
|
| You fire the bad managers.
|
| Well, the next question would be how do you find out if the
| managers are bad? One has to talk to peers, subordinates and
| superiors and do anonymous feedback, in addition to random
| checks. All that has to be done by the upper management. If the
| upper management is not doing it it can only mean either of
| these 2 things: 1)They are not interested 2) They are too
| incompetent to do it.
___________________________________________________________________
(page generated 2024-11-04 23:00 UTC)