Comment by pavon | Hacker News Reader

Comment by pavon | Hacker News Reader

Parent Full thread

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.

Why 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?

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

It 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"?

Mostly, 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).

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

Yep 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

That sounds like it's a time when it's the responsibility of the manager to start communicating clearly with their colleague, rather than thinking they need to figure everything out just by looking at the situation from the outside.

Treat your employees/subordinates/colleagues like they're responsible adults, and they're more likely to act like it. That means, among other things, talking to them when you notice something that seems off, rather than just thinking it's your job as the Big Important Manager to solve all problems in your own head.

Treat them like they're bad children, or like they're all constantly looking for every way possible to get more money for less work, and you're more likely to get disinterested, frustrated, and rebellious employees. There's nothing more likely to make someone act like a child than treating them like one.

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

I'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."

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

Reply on news.ycombinator.com