5 ms·
> You can't measure any productivity that has any cognitive component. Are you able to elaborate on why this is true please?
by 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 agoHow many units of thinking did you perform today? How do you charge or how are you payed per thinking unit?
- RandomLensman 3y agoHow much profit did that thinking create at the end of the year (or whatever the horizon is)?
- Scarblac 3y agoI 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 agoYou 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 agoI 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 agoYou 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 agoYup, 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 agoIf 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 agoWhat 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 agoWhat 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 agoYou 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 agoThat'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).
- khazhoux 3y agoObviously 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 agoThat sounds really subjective
- khazhoux 3y agoSomewhat, 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 agoThe "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 agoIn 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 agoNo, case 2 took 20 minutes.