6 ms·

Another article missing the more fundamental point: You can't measure any productivity that has any cognitive component. Devs think it's ok when sales product

• mandelbrotwurst 3y ago
  > You can't measure any productivity that has any cognitive component. Are you able to elaborate on why this is true please?
  • bane 3y ago
    How many units of thinking did you perform today? How do you charge or how are you payed per thinking unit?
    • RandomLensman 3y ago
      How much profit did that thinking create at the end of the year (or whatever the horizon is)?
      • Scarblac 3y ago
        I never understood how I'm supposed to know that. The company as a whole makes a profit, how do you know what it would have been if feature X wasn't implemented? And ten people had a role in deciding to implement it, four in implementing it. How can I possibly put a number on my contribution?
        • RandomLensman 3y ago
          You can at least start from the top: the overall thing you are working on, how much did that make? Are features you worked on a contributing reasons for a sale/how much extra did they bring? Are you directly linked to some sales because you provided something specific? If you are doing internal software, could be cost reductions associated with that or also additional business. Your number won't be exact, but it doesn't have to be and double counting among the other people isn't always bad.
          • Scarblac 3y ago
            I make frontends for our products (that we sell to governments), but they're not what drives sales. Customers by our product got features of the backend, they assume there is some frontend. If I do good work users are happy, but they don't make the buying decisions either. That I work on the front ends was only partly my choice, we all move around depending on where we need people at that time, and other people decide what needs to be implemented. If we were to fire all developers, we would probably lose hardly any sales the first year. But over time, licenses would go down more and more. So part of this year's profit is due to the work of people who left us years ago. I don't see any point in claiming some specific part of our profit. People would laugh at me, probably.
            • RandomLensman 3y ago
              You don't need claim, but you can at least associate with it. Even tracking happy users is a measure of sorts. It isn't an exact science and it doesn't need to be. And, yes, that isn't always fair to those gone from the company.
        • bane 3y ago
          Yup, it's a more or less worthless conversation, but one that many knowledge workers end up in. I remember once being a similar conversation regarding a training program I was working on, and the customer was trying to assess the value of the training not on the improved performance of the employees, but on some measurable "knowledge unit" that had been transferred to the student (regardless of their ability to retain it). It was beyond frustrating.
          • RandomLensman 3y ago
            If you think your contributions to the economics of a business are impossible to understand, then you are in a dangerous position (your admittedly bad experience notwithstanding).
            • bane 3y ago
              What I'm saying is that measuring output for knowledge workers in terms of some kind of unit other than business impact is not a great idea.
      • esafak 3y ago
        What if, as is usually the case, it created nothing until a whole team built the rest of the product that fits with my piece? What is the value provided by the front-end of a web app separately from the back-end?
        • RandomLensman 3y ago
          You can double count to some extend/doesn't have to exactly proportion but you worked on something that in the end had an economic impact.
    • staunton 3y ago
      That's not a good answer. We're not talking about thinking, we're talking about things with a cognitive component. Writing software has such a component and it's possible to tell if any software has been written (it's even sometimes possible to tell if it works or not).
      • bane 3y ago
        > You can't measure any productivity that has any cognitive component.
        • staunton 3y ago
          I'm not sure what you're saying...
          • bane 3y ago
            The irony of your joke took me a minute. Bravo.
    • khazhoux 3y ago
      Obviously not. The goal is to measure people's results. It might occasionally take a relatively-long time to find a seemingly-simple solution. But if an engineer /always/ takes a long time to find every solution, and upon inspection the problems were not actually difficult, then you most likely have a low-productivity engineer on your hands.
      • groone 3y ago
        That sounds really subjective
        • khazhoux 3y ago
          Somewhat, but not entirely so. Managers can and should read git logs and bug tickets and design docs, and understand the architecture enough to have a reasonable sense of what the work entails. And managers should be engineers themselves and know that sometimes simple-looking work is actually very tricky… but at the same time it’s very unlikely that /every/ task looks like this.
  • boxed 3y ago
    The "solution" to a problem can be to totally redefine it. Another guy might redefine it EVEN MORE. So you get three people: 1. solved the original problem, took 2 days and thousands of lines of code 2. changed the problem, took 20 minutes 50 lines of code 3. changed the problem in another way, took 2 days and thousands of lines but this solution solved TEN problems Now, which one is "better"? It makes no sense.
    • khazhoux 3y ago
      In all your examples the solution came in 1-2 days. How about this common example? One guys merges one small change every week, of low complexity/difficulty by any measure. His teammate fixes several bugs every week, adds a feature or two also, and is on slack non-stop helping others out? This is daily life in every tech company. It’s true that in some cases it’s hard to accurately rank between two people (because the work is multidimensional) but in many many cases the discrepancies in productivity are obvious.
      • boxed 3y ago
        No, case 2 took 20 minutes.
• paulcole 3y ago
  > You can't measure any productivity that has any cognitive component Understanding and measuring productivity can be valuable to a business. Sure they can't measure productivity for some roles as precisely, simply, and accurately as say counting the number of jelly beans in a jar. But that doesn't mean productivity can't be measured in a way that is useful to the business. There's just tradeoffs involved.
  • distortionfield 3y ago
    Anecdata but: In my almost ten years of software engineering engineering, I’ve never once seen an organization deploy developer productivity metrics and do anything useful with them except bludgeon developers that management already don’t like with the number that came out of The Machine ©
    • FireBeyond 3y ago
      Obligatory: "Y.T.’s mom pulls up the new memo, checks the time, and starts reading it. The estimated reading time is 15.62 minutes. Later, when Marietta does her end-of-day statistical roundup, sitting in her private office at 9:00pm, she will see the name of each employee and next to it, the amount of time spent reading this memo, and her reaction, based on the time spent, will go something like this: Less than 10 min.: Time for an employee conference and possible attitude counseling. 10-14 min.: Keep an eye on this employee; may be developing slipshod attitude. 14-15.61 min.: Employee is an efficient worker, may sometimes miss important details. Exactly 15.62 min.: Smartass. Needs attitude counseling. 15.63-16 min.: Asswipe. Not to be trusted. 16-18 min.: Employee is a methodical worker, may sometimes get hung up on minor details. More than 18 min.: Check the security videotape, see just what this employee was up to (e.g., possible unauthorized restroom break). Y.T.’s mom decides to spend between fourteen and fifteen minutes reading the memo. It’s better for younger workers to spend too long, to show that they’re careful, not cocky. It’s better for older workers to go a little fast, to show good management potential. She’s pushing forty. She scans through the memo, hitting the Page Down button at reasonably regular intervals, occasionally paging back up to pretend to reread some earlier section. The computer is going to notice all this. It approves of rereading. It’s a small thing, but over a decade or so this stuff really shows up on your work-habits summary." --Neal Stephenson, Snow Crash
• ebiester 3y ago
  It's not that "devs think it's okay" - it's that we accept that sales thinks it's okay and we don't have the experience or judgement to say otherwise unless we've been in a sales org. The fundamental point I think everyone misses is that as organizations get larger, the network cost of running is higher and nobody has solved that problem. Smaller problems are more quickly solvable and no amount of story points will change that.
• dboreham 3y ago
  Lots of delusion and gaslighting in this area.
• khazhoux 3y ago
  > You can't measure any productivity that has any cognitive component. So you're saying that it's impossible to measure developer productivity at all, since it's cognitive work? Strong disagree. All of us here that work with other developers know that some of their peers get more done than others. Or conversely, that there's a few in the team who don't seem to get much done. The minute you make even that simple assessment, you've measured productivity. One of the jobs of eng managers is to then make this measurement as accurately, realistically, and fairly as possible. This guides bonuses and raises, which should reflect people's contributions. I'm not defending McKinsey's proposal here, but I agree with the general notion that it's possible to measure productivity and this is something management should always be doing.
  • Scarblac 3y ago
    But not very precisely. I know who is a lot better than others and who are a lot worse, but the rest are all in the pretty large group that is somewhere in the middle. Especially because there are also skill differences and the differences in job title and salary that come with that. So the level of difficulty of the work people get to do is also different, and so on.
    • khazhoux 3y ago
      Correct. It's brutally hard to measure with precision, in part because the work we do is so multi-dimensional. But it's not too difficult to divide people into at least three groups, of low, high, everyone-else.
      • tonyedgecombe 3y ago
        Yet I've seen plenty of companies that get that completely wrong. They will fire the most productive member of the team without realising what they have done. The problem is people realise they can gain as much from playing political games as they can from improving productivity. Once that starts everything goes to shit.
  • hiAndrewQuinn 3y ago
• barrysteve 3y ago
  I mean you can. We take exams at school for basically the same reason. You have to set up an institution or structured lessons to get the higher levels of cognitive measurement. A company can use an educated guess for cognitive ability. Usually made up from completed tasks. Selling features that don't exist is a side-effect of the company culture. It's easy to observe the business culture in the West is often well divorced from academic truth seeking. As a matter of fact and good business.
  • boxed 3y ago
    Tests in school don't require creative problem solving. We can know this to be true, because if it did then checking the results would require it as well, which would mean we'd need 10x the number of teachers.
    • rrr_oh_man 3y ago
      > Tests in school don't require creative problem solving I’m not sure you can make such a broad statement.
    • staunton 3y ago
      > We can know this to be true, because if it did then checking the results would require it as well This argument is blatantly false. (I mean the argument not the claim it's arguing for) As just one counterexample, writing a mathematical proof often requires a lot of creative problem solving (it's not done a lot in school for this very reason). However, checking that a proof is correct is a rote task, even automatable (see proof asistants).