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…
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.
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.
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.
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.
