5 ms·
Yes. I've never been a manager, but when working as technical lead productivity was the one thing I've never bothered trying to measure, as a metric or even an
by pavon 4y ago
Yes. I've never been a manager, but when working as technical lead productivity was the one thing I've never bothered trying to measure, as a metric or even an informal impression. Estimating how long something is going to take is really difficult, and as a developer I constantly run into something I thought would take a few hours, and then hit a snag that took a week to rundown and fix. That is despite being a programmer myself, and being very familiar with the codebase and program area. If I can't set a reasonable bar for my own productivity, how can I do so for my team mates, let alone how could a manager removed from the day-to-day work do so? I've felt like the people who thought they could measure productivity were the ones where were fooling themselves.
Instead, I looked at a number of things. Are you making progress? Are you getting help quickly when you stop making progress? Does your code have lots of bugs later on? Do you take constructive criticism well? Do you give constructive criticism well? Do you help out your team mates? But how fast you got work done is not something I considered at all, as long as you were showing up, not wasting exorbitant amounts of time, and not putting in extra hours if there wasn't an emergency, I figure it will get done when it gets done.
Eg, I cared about work ethic instead of productivity, and that is much harder to gauge with work from home. Without it, I feel like I have to start judging based on perceived productivity and I hate that.
That said, I personally love WFH and so do my team mates, and I know them and trust them so it isn't an issue, but I wonder about how new people will work out.
- itsdrewmiller 4y agoWhy do you find those characteristics more challenging to track in a WFH environment? Shouldn't things like commits, PRs, bug reports, etc. be better indicators than your in-person observations anyway?
- pavon 4y agoYes many of the things I listed are just as easy to track with WFH, and even before WFH online interactions were a significant part of those. It is the showing up, putting the hours, and not wasting too much time part that is hard to track remotely.
- danaris 4y agoIt sounds like there's something of a disconnect there. If someone is making a reasonable number and quality of commits, fixing bugs, and communicating reasonably with their colleagues, does it matter if they're "showing up, putting in the hours, and not wasting too much time"?
- pavon 4y agoMostly, but if they aren't, is it because they keep getting tasks that are genuinely hairier than we expected, or because they are slacking and then making excuses? If you distribute work completely randomly then eventually it should all even out, but if you let people specialize, or self-select work, then it isn't unreasonable for someone to be more likely than others to get "surprises". With on-site (and open-office even more so), it was much easier to differentiate these two. I don't want to give someone a luke-warm performance review because their work was taking longer, when in reality they were solving harder problems. I also don't want to push things like pair-programing on someone who really doesn't like it (and I assume it is worse over Teams or what not than in person).
- jrumbut 4y agoThis is one of the understanding gaps I've seen in these discussions. If you have an employee who is producing very little work, you're face with a decision about whether to put in a ton of effort to try to turn the situation around or put a ton of effort into firing them and hiring a replacement. If you know the person has been showing up and doing normal office stuff that's a huge signal in favor of "this person is making a genuine effort so I need to go the extra mile on my end." It's harder to get that kind of signal remotely. This isn't to suggest remote work is wrong. It's just that, for managers, dealing with these kind of situations was a big part of the job and now has gotten much harder.
- bigfoot675 4y agoYep this has been my experience as well, and it has popped up more than I expected, honestly. And this is the type of thing to affect a team's productivity for months at a time since it requires taking action, and then finding a backfill, all before the team gets the support they need
- SergeAx 4y ago> Estimating how long something is going to take is really difficult No one says it is easy, but it is not impossible too. It is okay to change one's estimation after several hours/days of work. But after months working on the same codebase estimations are getting better and better.
- jrumbut 4y agoI've always wanted to say, in response to a request for an estimate on a large project, "let me work on it a few weeks and then I'll tell you."
- SergeAx 4y agoAnd this is the right answer. No way anybody in their sane mind expect an off the bat estimation for a large project to be anywhere realistic.
- deleted 4y ago[deleted]