[vvanpo]

> Hours worked is the #1 driver of any worker’s output: use your right to monitor.

I don't think hours behind a screen have ever had much of a correlation with productivity for me. Autonomy, stress, being tasked with solutions that actually make long-term sense, etc. must have a much stronger correlation. The enormous erosion of trust that having my hours monitored would have would certainly impact my output.

[pavlov]

Yes, it’s terrible advice if applied to engineering teams at least.

The number of hours that an individual spent staring at the IDE or punching commands into the CLI have no meaningful correlation with the organization’s long-term goals.

A manager who spends their time monitoring engineers’ screens is like a web developer who writes a CRUD back-end in x86 assembly. It’s the wrong level of abstraction for performing the job.

[cyrilgrislain]

People join forces in a Business, rather than working alone for ex, because they believe the collective sum of resources = inputs will produce greater collective sum of outputs. Responsible businesses are those who maximise the outputs. Otherwise, it is a waste of resources that are extracted from collectivity ($, labor, natural resources, infrastructure, etc). Inversely, that is also why the standard business forms are not best suited for artists to thrive.

So, as business is about maximizing output: no matter how much is your productivity, which is a ratio, if you apply it to one more hour of work, then you will produce more output. So there are 2 ways to go here for high-productivity workers: a) you are paid equal for same output, and allowed to work less. b) you work as much as others, then produce more, then are paid more.

There is plenty of science that proves that choosing option a) is a shot in own's foot on the long run. Note: 80% of harvard professors thing their students would rate them in the Upper half best professors. which is of course statistically impossible. Same for how anybody = we, self evaluate ourselves in anything: how good a driver, a parent, ... a worker we are.

How much hours one puts in is a fundamental parameter of how much one produces. Stays true even with diminishing returns, as long as productivity is >0.

There is this say, pardon my french: an idiot who walks will still gets further than a sitting genius.

[chenmike]

This is the weirdest sentiment out of the entire article. "Only hire A-players" and "monitor them". I know exactly 0 A-hire engineers who would tolerate being monitored. Why wouldn't they leave to go to one of the many companies that would love to have them and where they won't have someone breathing down their neck?

Perhaps it's a take on how bad the job market is right now, but I still disagree. There are far fewer job prospects out there but way more than 0.

[quickthrower2]

It also changes the focus: “what is good for the company” -> “what makes me look good and not get fired”. Following Elons antics I bet twitter LOC count is growing very fast!

[chrisweekly]

Yeah; code is a liability, not an asset.

[groestl]

I've spent years doing stuff that I'd better not done at all. So yeah, hours worked is not a good metric by any means.

[luckylion]

The problem is that you can only later tell what made sense long-term, who was able to handle autonomy etc.

I work for a company (as a contractor) that doesn't monitor hours worked for their employees and the team is incredibly unproductive. It feels like some have a second job while others are playing games. I'm sure you could get rid of 75% if the remaining people worked full-time for their full-time salaries.

[sirwhinesalot]

You'd think so but if people are playing video games or not working, adding monitoring won't increase your productivity, people will just do pointless busywork instead.

Cutting down the number of people will make everyone else more productive because they need to pick up the slack, but that doesn't mean the output will be higher quality, it will very likely be worse quality since you've taken a bunch of relaxed people and made them highly stressed.

To me it sounds like a failure of management and/or processes. The people are not motivated and their tasks are not being defined appropriately.

[luckylion]

If someone is doing pointless busywork, they might as well do real work, they're often similarly annoying.

People in bureaucracies aren't famously slow because their tasks aren't well defined, they're slow because it's tolerated. When you stop tolerating it, they either improve their attitude or get filtered out. I've found that to apply to all organizations past some head count. People settle in and do less and less. That's not a problem while the money is flowing in like water during a flood, but it becomes a problem when that changes.

[sirwhinesalot]

I don't know how it is where you work (I guess working as a contractor skews things) but where I work this is how things go:

- some tasks are estimated - a resource bound is set per sprint/per person - tasks are picked for a sprint such that the resource bounds aren't exceeded. - people work on those tasks until the next sprint.

Now, software engineering is notoriously hard to estimate. Hard to predict you can't work for 2 days because someone updated a package that totally follows semver except not really and it takes 3 days of debugging.

So tasks get estimated with a lot of slack because hitting the sprint targets is more important than doing more work. That's a process problem.

Even then what mostly happens is that some tasks end up wildly overestimated while others wildly underestimated, to the point they end up shifted to the next sprint (at which point one must question the whole exercise).

This all assumes the requirements for the tasks were in any way clear, often they aren't.

Either way, the outcome is that some weeks there simply isn't enough work assigned, while others there's too much. Sometimes there's an issue that's on someone to fix and everyone else is waiting for that before they can do their work.

What should they be doing with their time? Improve the tests? The docs? I guess, but unmotivated people doing boring work always ends up with a shitty output regardless of how many hours they dedicate to it.

Much better to trust people to get the job done, given them a reason why they do what they do, and set processes that let them work at a consistent pace. That's what Agile was originally all about.

[dalyons]

(I know you’re a contractor so you don’t get to choose but:) stop working in artificial sprints. In some cases they’re useful(external client stuff) but mostly they can be replaced with just working down a continuous backlog. Then you don’t have this weird artificial feast and famine game. I think from your last sentence you agree.

[sirwhinesalot]

Yes I most certainly agree, I was a manager for awhile and pushed for that but it got rejected by the higher-ups. Not a manager there anymore ;)

[gedy]

Agreed, kanban style is so much better than sprints

[wirrbel]

I’d still say that monitoring hours seems like a strange idea when the company itself has trouble setting expectations and delivering goals

[luckylion]

It's a shortcut because measuring output is too hard for any sufficiently complex work.

It's easy when you have a well-defined task that you know the average complexity for, e.g. first level support ticket responses. It's very different for e.g. the developer who looks into a ticket to find out why. Might be just 60 seconds because technical understanding + experience give you the ability to see what customer + support agents have missed. Might be 6 hours for a complicated bug and fix, might turn into a huge deal that takes days.

How do you handle that and accurately predict how much time that should take?

[wirrbel]

Basically you have just given reasoning for why there is a job description „engineering manager“.

I am actually all for monitored work hours and I clock in an clock out of my unionized 35h work contract. But frankly i expect from a sw eng Organisation more insight into their own development processes