16 ms·

A change of heart regarding employee metrics

• peterldowns 2y ago
  I stopped working on a tool in this space (https://dev.log.xyz 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.
• deleted 2y ago
  [deleted]
• ethbr1 2y ago
  >> [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 https://en.m.wikipedia.org/wiki/Goodhart's_law
  • bigiain 2y ago
    > 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 2y ago
      > 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.
• jatins 2y ago
  > "Peer reviews actually improve things" is about the biggest crock of shit that people in tech still believe in. God that hits home
  • 000ooo000 2y ago
    Does the author mean peer review in the performance review context? Or code review?
    • rustypotato 2y ago
      Performance review, as per the linked post of theirs: http://rachelbythebay.com/w/2021/02/19/perf/ http://rachelbythebay.com/w/2021/02/19/perf/
      • 000ooo000 2y ago
        Thank you
      • johnnyanmac 2y ago
        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 2y ago
      I took it to mean in the performance review context.
  • swampdonkey64 2y ago
    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.
• comp_throw7 2y ago
  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 2y ago
    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 2y ago
    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 2y ago
  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 2y ago
    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 2y ago
    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 2y ago
    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 2y ago
    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.
• donatj 2y ago
  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 2y ago
    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 2y ago
      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 2y ago
        Were you a lead or a manager? Did you take a salary cut?
        • donatj 2y ago
          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 2y ago
    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.
• devoutsalsa 2y ago
  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.
  • deleted 2y ago
    [deleted]
• onion2k 2y ago
  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 2y ago
    > 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 https://www.folklore.org/Negative_2000_Lines_Of_Code.html
    • onion2k 2y ago
      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.
• ainiriand 2y ago
  I like this new punk Rachel much more.
• deleted 2y ago
  [deleted]
• alpb 2y ago
  OK, I'll bite. I think if you're a technical team lead in a large organization, it is rather your job to point out what's working and what's not working from a technical perspective. If managers could figure this out, they most likely would not end up being people managers after all (insert if those kids could read meme.jpg). Sadly, nowadays even the most large tech companies have enough red tape and bullshit going on (OKRs, alignments, escalations, Q4 plannings, weekly 1:1s with all reports etc) to keep people managers full-time occupied. Most people managers nowadays neither have the chops to understand the work that's taking place on the ground, nor have the time to track it. So it falls on a tech lead to point out who are the sailors in the ship that are not rowing (or worse paddling backwards). I'm not saying "go build a git commit counter dashboard" but if you're working with dozens of people and it appears someone isn't delivering a lot of work lately, it helps you double check your assumption. (Again, not saying commits are a good metric.) This blog post is definitely relatable to most of us because we join teams that are somewhat dysfunctional, and if you have the influence capital and the chops to turn that team into a place where hiring is done properly, people have motivated and the right amount of work and the room to grow, I think you can turn the ship around. Or maybe I'm too naïve and have a lot more to learn.
  • bootloop 2y ago
    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 2y ago
    > 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 2y ago
    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.
• raister 2y ago
  "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 2y ago
    "Eli, one unauthenticated metric is sent to https://metrics.corphq.yoyodyne.com/counterincrement https://metrics.corphq.yoyodyne.com/counterincrement in json format {"empid":"<employeeid>","workunit":"1"}, each time you complete a work unit."
• renewiltord 2y ago
  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 2y ago
    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 2y ago
  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.
  • stavros 2y ago
    That's not useless at all, the moment I saw -5900 I knew that was the most valuable contribution to the codebase.
  • ajuc 2y ago
    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 2y ago
    “One of my most productive days was throwing away 1000 lines of code” ― Ken Thompson
    • canucker2016 2y ago
      -2000 lines of code, Bill Atkinson, Apple Lisa Quickdraw developer https://www.folklore.org/Negative_2000_Lines_Of_Code.html https://www.folklore.org/Negative_2000_Lines_Of_Code.html
  • m463 2y ago
    https://www.folklore.org/Negative_2000_Lines_Of_Code.html https://www.folklore.org/Negative_2000_Lines_Of_Code.html
  • mirekrusin 2y ago
    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.
• deleted 2y ago
  [deleted]
• shermantanktop 2y ago
  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 2y ago
  >> 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 2y ago
    > 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?
    • logicalxor 2y ago
      I am not joking. I don't know why do you say that. Granted, not everyone is equipped to pull it off but trust me $60-$80k are good if you manage your expenses well. Here is the breaddown: Rent: $2400 (East South of Seattle, quiet and safe area 3B2Ba SFH) Groceries: $800 per month Kids school: $200 per month (public school) Kids activities: $200 (for 4-6 months). We play at home. Electricity, Gas, Sewer - $400 per month Gas: $100 per month (I mostly do WFH) Emergency: $300 per month Fun: $100 month Healthcare: $1200 per month (through marketplace) Childcare: None since one of the spouse stays at home. We could lower it if we moved to an apartment but we love the place. We live happily and I get to see kids everyday rather than leaving them with strangers with cookie cutter upbringing. You can't outsourced parenting when you decide to have kids. But, most people never grow up. They want to party every weekend. They can't keep up with jonasses. We are different. This is how my family built the wealth. I will follow their teachings and path and will build my own destiny. It is manageable with $60k to $80k. Granted, we are not contributing to retirement but this won't be forever situation. Somehow, people have build expectation that you need $150k - $200k to live descently. It is utmost corporate and media brainwashing one could imagine.
• makach 2y ago
  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 2y ago
  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_ 2y ago
    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 2y ago
      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 2y ago
  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 2y ago
  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 2y ago
    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 2y ago
      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 2y ago
      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 2y ago
    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. :)
• renegade-otter 2y ago
  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 2y ago
    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 2y ago
    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 2y ago
    > 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 2y ago
  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 2y ago
  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 2y ago
    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 2y ago
      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 2y ago
      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.
• alkonaut 2y ago
  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 2y ago
  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-leadership-masters-program.html https://www.wgu.edu/online-business-degrees/management-leade...
  • dakiol 2y ago
    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 2y ago
  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 2y ago
    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 2y ago
  > "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 2y ago
  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 2y ago
  HN death hug in effect. https://archive.is/pYG8C https://archive.is/pYG8C
• physicsguy 2y ago
  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 2y ago
  > 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 2y ago
    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.
• welder 2y ago
  > 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 2y ago
  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.
• throw989843 2y ago
  [flagged]
• InsideOutSanta 2y ago
  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 2y ago
  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 2y ago
  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 2y ago
    Yes, this is the way. It's better never to gather the information at the individual level.
  • throwaway2037 2y ago
    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?
    • 2y ago
• konschubert 2y ago
  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 2y ago
  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 2y ago
  Are there any tools to measure the performance of managers?
• zem 2y ago
  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 2y ago
    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 https://en.wikipedia.org/wiki/Harry_Nyquist
    • ryukoposting 2y ago
      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 2y ago
• the_gipsy 2y ago
  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_ 2y ago
  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 2y ago
  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 2y ago
    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 2y ago
      > 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 2y ago
      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).
• canterburry 2y ago
  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 2y ago
  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 2y ago
    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 2y ago
  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 https://github.com/ChrisMarshallNY#github-stuff [1] https://littlegreenviper.com/miscellany/leaving-a-legacy/ https://littlegreenviper.com/miscellany/leaving-a-legacy/
  • BlueTemplar 2y ago
    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 2y ago
      Eh, I don’t lose any sleep over it. There’s bigger fish to fry.
      • BlueTemplar 2y ago
        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 2y ago
• jackhiggs 2y ago
  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 2y ago
    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 2y ago
    > 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 2y ago
      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 2y ago
        > 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.
• cromulent 2y ago
  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 2y ago
    This misses "negating realized losses", which I believe is a very important area for engineers to perform in. Perhaps I am wrong.
    • cromulent 2y ago
      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 2y ago
  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 2y ago
    > 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 2y ago
  > 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 2y ago
  It hurts me that my coworkers literally do nothing. Managers need a metric, which one, its a secret ;-)
• kasey_junk 2y ago
  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 2y ago
    extremely valuable if you use it as a tool for self improvement
• dudeinjapan 2y ago
  Can anyone steelman the case for employee metrics and if so what are the best ones?
  • rgbrgb 2y ago
    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.
  • jlund-molfese 2y ago
    The straw man is usually that employee metrics should be used as the primary factor in performance reviews. Well, I guess it's hard to call it a straw man because some companies, allegedly, really do operate like that. The steel man argument would be that employee metrics can provide a couple data points that a manager doesn't take action on by themselves, but can help a manager know where to look. Metrics can flag unusual situations. Sometimes there's a great explanation behind employee X making 80% fewer commits than the average employee. Like less rework, making more impactful changes, or simply bundling more changes together. Other times, it can be a sign that someone is having trouble onboarding or simply not performing at the necessary level. When you see that a metric is different than what you expect, it's your responsibility as a manager to figure out why.
• deleted 2y ago
  [deleted]
• Archana345 2y ago
  [flagged]
• Buttons840 2y ago
  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 2y ago
    > 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 2y ago
      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.
• sethammons 2y ago
  > "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 2y ago
  The best managers never speak or think about KPIs.
• perryizgr8 2y ago
  > 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 2y ago
  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 2y ago
  I read the article and frankly I'm not sure what she means by it.
• deleted 2y ago
  [deleted]
• madrox 2y ago
  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 2y ago
  Collary, only lazy and ineffective managers need employee productivity metrics. A good manager wouldn't even trust those metrics.
• lowbloodsugar 2y ago
  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 2y ago
  > 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 2y ago
  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 2y ago
    "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 2y ago
    >"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.
    • tqi 2y ago
• efitz 2y ago
  I will stop complaining about executives measuring my performance with objectives and metrics they define, if I can define my own metrics and objectives for them and measure executive performance, complete with PIPs, layoffs and forced attrition for the lowest 10% of performers. What’s good for the goose is good for the gander. I will be happy to sit in an office with my VP and HR and explain to them that we have to let them go due to not performing up to $COMPANY standards, but we wish them well and here is 2 months salary and a copy of your NDA and non-compete; can I have your badge please?
• giantg2 2y ago
  I have no faith in managers to try to understand or correctly apply any metric. I collected metrics this year that showed I did a lot for the team/company. I still got a shit review because my TL gave me bad feedback. I asked why the feedback was taking precedent over the data. They said that just how it works. The company previously agreed to extra coaching as an ADA accommodation and failed to provide that for 4-5 months out of the year. They refuse to listen to reason, so maybe it's lawyer time.
• jfil 2y ago
  Rhis hits a spot for me that I call "millionaire problems": The owners of the company are millionaires. They're just as smart as the workers, and vastly more well-resourced. You, as an employee, shouldn't cry for their challenges or break your back helping take on their burdens. Their job is "managing", their job is dealing with unions, fundraising, assessing productivity etc. - so step aside and let them do their job. You focus on doing yours.
• akomtu 2y ago
  Corporations are meant to be well oiled machines that extract money from the sands of humanity. The harkonnen's harvester from Dune would be a good analogy. This machine is meant to be soulless, blindly doing the will of its owner. Today, corporations have to be made of employees, who have their own will, and their will is often not aligned with the will of the owner. It's as if the harkonnens would have to hire freemen to do work that would harm their own people. From the owner's perspective, those employees are defective mechanisms that must be fixed, and the owner creates a control framework that fixes them. That's what metrics do: they reduce employees to small parts of the machine, with well defined functions, inputs, outputs and measurable qualities. This is what makes modern corporations smell so off. One day in their careers, managers realise that they have to make a choice: side with the employees or fuse themselves with the machine.