[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