Metrics are mostly bullshit because it’s not possible to measure productivity for most tech roles and its impossible to measure productivity for soft skills.
Metrics exist to justify manager decisions and convince their managers that things are working, regardless of what’s actually happening.
What metric do you use for a coder role? Sloc? Ok, make a bunch of garbage code. Tasks complete? Maybe, but there’s no quality metric so tech debt is invisible. Senior Engineers should be mentoring and influencing their team members. How do you measure that? How do you measure how well a TPM gets people to work together?
It’s bullshit used to justify the bullshit idea of “scientific management.”
I remember this one time when management started thinking about using “lines of code” as a metric for productivity of us software developers.
I very openly offered to craft a bunch ot code generators, namelly “loop unrollers” (which is something compillers do internally at the compilation stage in some situations for improve performance) for me and my colleagues to produce more code.
That idea for a performance metric was quickly shelved after that…
Metrics are mostly bullshit because it’s not possible to measure productivity for most tech roles and its impossible to measure productivity for soft skills.
Where are you getting this? It’s completely wrong. I work in IT and I have a timesheet to fill out on each ticket I do, and document what was done. You can look at my weekly hours and see exactly what I’ve been doing and how my time is spent. They don’t care if I put “watched youtube for an hour” if there isn’t immediate work, it just needs to be filled out. That is a measurable metric, in fact we let a guy go last month because he could only account for about 15 hours a week that he was working and when asked about it, he had no answer on any of it.
So I don’t know how you think it’s “unmeasurable”. Of course I could make shit up and fill in fake hours, but it will catch up when the work isn’t done and they start asking questions or the client starts asking what’s going on with their project.
What metric do you use for a coder role? Sloc? Ok, make a bunch of garbage code. Tasks complete?
And then when they see that you can’t do the job… you’re gone. that’s measurable over time, very easily. They’re going to see that you can’t perform the job based on your results.
Senior Engineers should be mentoring and influencing their team members. How do you measure that? How do you measure how well a TPM gets people to work together?
You put it on your calendar/timesheet that you had training with X employees, or helped so and so work on a project. It’s not hard and is a requirement in many Tech places. This is a way to make sure the team isn’t overwhelmed, work is done in a timely manner, and how we’re communicating with the clients, as well as many other things. The guy was let go because he was taking over 2 hours to do a password reset. I remoted in, changed it, gave the new password to the client and it was done in about 8 minutes. He just wasn’t up to snuff to handle even the simplest things. Measurable actions. 10 minutes vs 120 minutes is a massive difference for simple tasks that we have documentation on how to do.
Whether you agree or not, that is a metric used to measure performance and see where employees stand with the workload. So your first comment is such a broad stroke it’s completely wrong.
I’ll let you in on a secret: they can’t tell. There’s absolutely no way to know how productive someone is. It’s a popularity contest with extra steps.
Also it’s such a “junior” level of understanding the process it’s downright cringeworthy.
What you describe is measuring work going in rather than results coming out, when it’s the latter that matters and you actually want to minimize the ratio of the former to the latter (it’s literally the definition of “efficiency”), not maximize it - some of the most effective and advanced software development involves lots of time of what looks like “sitting on your hands” (i.e. analysing the problem) so that a correct and complete result can be delivered directly and without wasting time because “unexpected” things were found, often with less time spent coding than analysing (in management speak: you spend time turning your known unknowns into known knowns so that you can address them upfront instead of wasting time of multiple people later (or worse) due to “unforseen” gaps and problems in the software.
It’s a massive sign that management hasn’t got a fking clue what they’re doing when, in IT they’re engaging in the whole “tracking hours going in” rigmarole, because that actually measuring and ultimatelly rewarding the very opposite of what is good for the company - unless we’re talking about an IT Consultancy, that company’s (or that division within the company’s) product is not lots of well tracked hours worked, it’s software that correctly serves internal or external customer needs, it’s problems solved, it’s good integrations that are completed and delivered in a timelly fashion without the stupid ping-pong between teams as they found “stuff we forgot about” because they didn’t spend time analysing it upfront since they were being measured in “coding hours” (or are too junior to know the value of it or never worked in an effective IT environment).
In IT measuring time-in does nothing to help deliver good results: generally it just incentivises rushed coding that produces little more than constant fires and hence constant firefighting (which, and this is the most hilarious part, then gets measured as hours spent working hence a good thing)
And this is is just the time static stuff. Then there’s all about preparimg for tomorrow whilst you’re doing for today (i.e. maintenability and extendability considerations) which are how you can keep productivity high as the codebase grows, an outcome which is not only not even dectable by simply measuring “hours in”, and requires a time investment which is actually punished when all that is measured is “hours in” because it looks like time waste.
I’m sorry but you’re probably working under a management team that has no clue about software development processes and, worse, you’re celebrating as a great thing the visible artifacts of management incompetence.
Metrics are at best guidelines to help ground subjective observations. They all have huge gaping holes and if you want to plug those you’ll spend more time measuring than working. The best guide of if you are doing ok is how good other people think you are doing. Does the PO think you deliver fast enough given the complexity, do you help out other devs when possible, do other devs respect the quality of your work?
The best Software Designers have much lower rates of “surprises” in Production (i.e. stuff is put in production and only then people figure out something is missing, is not quite doing what’s necessary or worse).
Doing analysis upfront does help with doing the right code from the start (or close to it) rather than often going down directions that turn out not to work well and having to go back, AND it also helps with doing the right software design from the start (say, figuring out that you need a certain kind fast access persistent data stored hence need to structure the design taking it into account that you’ll have database access), AND it also helps with implementing the right Requirements with the right features (say, have the full details to integrate with other systems or how figuring out that “static” data elements are actually something that does change at sometimes, at an “admin” level rather than during normal use at a “user” level, so the whole thing needs some kind of admin layer).
This kind of stuff gets reflected in a more broader “customer” (internal or external) satisfaction of the “this software/software-changes usually do what we need straight out of the box and we don’t need to go back and forth to get it right” kind, which is even harder to measure and takes time.
First, I never said I was in programming. Second, the topic was that there is no way to track productivity, which is just wrong. May not be 100% accurate, but it can be tracked.
If your job can be accurately measured in all aspects, then it can also be scripted. If it can’t be scripted, there’s something that’s not possible to measure.
I used to drink that Kool aid too, before I spent a couple of years actually seeing what managers are doing.
Oh no! This will definitely negatively impact my CSAT! Lol, cool.
Edit: To be clear, I don’t actually think that you can be replaced with a small script (although, password reset is automated where I work). I think there are unquantifiable things, and I think you’re actually selling yourself short when you imagine your work can he represented with pure metrics.
Metrics are complete bullshit. They exist for the mananager to believe he’s doing things rationally. But in practice metrics only make your work worse.
Oh, then they might lay you off first because you’re underperforming compared to your peers.
I’ll let you in on a secret: they can’t tell. There’s absolutely no way to know how productive someone is. It’s a popularity contest with extra steps.
This is bullshit. There are dozens of ways to tell, even remote. Metrics exist for a reason.
Metrics are mostly bullshit because it’s not possible to measure productivity for most tech roles and its impossible to measure productivity for soft skills.
Metrics exist to justify manager decisions and convince their managers that things are working, regardless of what’s actually happening.
What metric do you use for a coder role? Sloc? Ok, make a bunch of garbage code. Tasks complete? Maybe, but there’s no quality metric so tech debt is invisible. Senior Engineers should be mentoring and influencing their team members. How do you measure that? How do you measure how well a TPM gets people to work together?
It’s bullshit used to justify the bullshit idea of “scientific management.”
I remember this one time when management started thinking about using “lines of code” as a metric for productivity of us software developers.
I very openly offered to craft a bunch ot code generators, namelly “loop unrollers” (which is something compillers do internally at the compilation stage in some situations for improve performance) for me and my colleagues to produce more code.
That idea for a performance metric was quickly shelved after that…
Where are you getting this? It’s completely wrong. I work in IT and I have a timesheet to fill out on each ticket I do, and document what was done. You can look at my weekly hours and see exactly what I’ve been doing and how my time is spent. They don’t care if I put “watched youtube for an hour” if there isn’t immediate work, it just needs to be filled out. That is a measurable metric, in fact we let a guy go last month because he could only account for about 15 hours a week that he was working and when asked about it, he had no answer on any of it.
So I don’t know how you think it’s “unmeasurable”. Of course I could make shit up and fill in fake hours, but it will catch up when the work isn’t done and they start asking questions or the client starts asking what’s going on with their project.
And then when they see that you can’t do the job… you’re gone. that’s measurable over time, very easily. They’re going to see that you can’t perform the job based on your results.
You put it on your calendar/timesheet that you had training with X employees, or helped so and so work on a project. It’s not hard and is a requirement in many Tech places. This is a way to make sure the team isn’t overwhelmed, work is done in a timely manner, and how we’re communicating with the clients, as well as many other things. The guy was let go because he was taking over 2 hours to do a password reset. I remoted in, changed it, gave the new password to the client and it was done in about 8 minutes. He just wasn’t up to snuff to handle even the simplest things. Measurable actions. 10 minutes vs 120 minutes is a massive difference for simple tasks that we have documentation on how to do.
Whether you agree or not, that is a metric used to measure performance and see where employees stand with the workload. So your first comment is such a broad stroke it’s completely wrong.
This metric is not measuring how well you do your job, it measures how fast you do it.
It’s not meant to see if the team is overwhelmed, it’s meant to ensure the team is overwhelmed.
Bingo.
That all sounds like a deeply mismanaged process.
Also it’s such a “junior” level of understanding the process it’s downright cringeworthy.
What you describe is measuring work going in rather than results coming out, when it’s the latter that matters and you actually want to minimize the ratio of the former to the latter (it’s literally the definition of “efficiency”), not maximize it - some of the most effective and advanced software development involves lots of time of what looks like “sitting on your hands” (i.e. analysing the problem) so that a correct and complete result can be delivered directly and without wasting time because “unexpected” things were found, often with less time spent coding than analysing (in management speak: you spend time turning your known unknowns into known knowns so that you can address them upfront instead of wasting time of multiple people later (or worse) due to “unforseen” gaps and problems in the software.
It’s a massive sign that management hasn’t got a fking clue what they’re doing when, in IT they’re engaging in the whole “tracking hours going in” rigmarole, because that actually measuring and ultimatelly rewarding the very opposite of what is good for the company - unless we’re talking about an IT Consultancy, that company’s (or that division within the company’s) product is not lots of well tracked hours worked, it’s software that correctly serves internal or external customer needs, it’s problems solved, it’s good integrations that are completed and delivered in a timelly fashion without the stupid ping-pong between teams as they found “stuff we forgot about” because they didn’t spend time analysing it upfront since they were being measured in “coding hours” (or are too junior to know the value of it or never worked in an effective IT environment).
In IT measuring time-in does nothing to help deliver good results: generally it just incentivises rushed coding that produces little more than constant fires and hence constant firefighting (which, and this is the most hilarious part, then gets measured as hours spent working hence a good thing)
And this is is just the time static stuff. Then there’s all about preparimg for tomorrow whilst you’re doing for today (i.e. maintenability and extendability considerations) which are how you can keep productivity high as the codebase grows, an outcome which is not only not even dectable by simply measuring “hours in”, and requires a time investment which is actually punished when all that is measured is “hours in” because it looks like time waste.
I’m sorry but you’re probably working under a management team that has no clue about software development processes and, worse, you’re celebrating as a great thing the visible artifacts of management incompetence.
I’m a senior dev. This is exactly it.
Metrics are at best guidelines to help ground subjective observations. They all have huge gaping holes and if you want to plug those you’ll spend more time measuring than working. The best guide of if you are doing ok is how good other people think you are doing. Does the PO think you deliver fast enough given the complexity, do you help out other devs when possible, do other devs respect the quality of your work?
Even then, the measuring should be multilayered.
The best Software Designers have much lower rates of “surprises” in Production (i.e. stuff is put in production and only then people figure out something is missing, is not quite doing what’s necessary or worse).
Doing analysis upfront does help with doing the right code from the start (or close to it) rather than often going down directions that turn out not to work well and having to go back, AND it also helps with doing the right software design from the start (say, figuring out that you need a certain kind fast access persistent data stored hence need to structure the design taking it into account that you’ll have database access), AND it also helps with implementing the right Requirements with the right features (say, have the full details to integrate with other systems or how figuring out that “static” data elements are actually something that does change at sometimes, at an “admin” level rather than during normal use at a “user” level, so the whole thing needs some kind of admin layer).
This kind of stuff gets reflected in a more broader “customer” (internal or external) satisfaction of the “this software/software-changes usually do what we need straight out of the box and we don’t need to go back and forth to get it right” kind, which is even harder to measure and takes time.
First, I never said I was in programming. Second, the topic was that there is no way to track productivity, which is just wrong. May not be 100% accurate, but it can be tracked.
If your job can be accurately measured in all aspects, then it can also be scripted. If it can’t be scripted, there’s something that’s not possible to measure.
I used to drink that Kool aid too, before I spent a couple of years actually seeing what managers are doing.
Lol ok. I guess we’re done here
Oh no! This will definitely negatively impact my CSAT! Lol, cool.
Edit: To be clear, I don’t actually think that you can be replaced with a small script (although, password reset is automated where I work). I think there are unquantifiable things, and I think you’re actually selling yourself short when you imagine your work can he represented with pure metrics.
Metrics are complete bullshit. They exist for the mananager to believe he’s doing things rationally. But in practice metrics only make your work worse.