Hacker News Reader

Comment by lennysan | Hacker News Reader

As a manager, especially when I'm not coding in the project, I need some way to know how hard the engineers are working, and whether there's anything I can do to help them be more productive. I have no doubt there is a clear correlation between hours worked and results produced. I think as long as you give engineers the flexibility in their work schedule, I can't imagine not counting hours.

View on HN

"I need some way to know how hard the engineers are working"

You get what you measure.

If you really want to know how many hours your engineers are sitting in front of a keyboard and screen in your office, you can find a way to get that information. If you tie compensation to that figure, your engineers will definitely give you plenty of butt-in-seat time (or quit).

If you do not have other ways to evaluate their output, though, you may not get much more than that. They might just read Hacker News all day. You can put in measures to block Hacker News, but at that point you have an escalating battle of not trusting your employees and putting in increasingly draconian measures until you have created a call center environment where your employees have a set number of minutes a day they are allowed to go to the bathroom, and have to get really good at holding it otherwise.

How many good developers do you think will be left at that point?

I did jump over some points along the continuum there. But the point is, if you do not have some level of trust in the relationship with your developers, you're probably screwed anyways.

"I need some way to know how hard the engineers are working."

Why? And what does "hard" even mean? (working more hours?) The goal is good results, not hard workers.

"...clear correlation between hours worked and results produced."

Working zero hours will produce zero results, so there is obviously a correlation, but this correlation cannot be linear, and may not even be positive in all cases. I would expect working 100 hours in a week would would make for worse results than 40 hours.

Hours are not a measure of output, or efficiency, or results; they are a measure of time.

My point is that there's it's very difficult to measure the productivity and "results" of knowledge work, and you need to look at all the data. This includes looking at hours worked, plus the quality of the end product, the way they work with others, the clients impression, and the success of the product in general. This is a complex problem the requires a holistic approach.

I'm going to take the opposite position of the last post I made and give some reasons for measuring hours worked.

It is important to track hours worked per feature or bug in order to improve future estimates. You also want to know if things are taking longer than expected, and why. You may also want to know if finishing and committing fixes and features too quickly leads to more bugs and maybe encourage developers to take more time and get it right the first time.

Is this the kind of thing you have in mind when you want to measure hours worked? That I can certainly agree with.

"My point is that there's it's very difficult to measure the productivity and "results" of knowledge work, and you need to look at all the data. This includes looking at hours worked..."

I agree with jimbokun: measuring "time spent" can be useful in many cases, but it does not measure productivity or quality of work. I understand how difficult it is to measure productivity, but the answer is not to use a poor metric just because it's handy.

> As a manager, especially when I'm not coding in the project, I need some way to know how hard the engineers are working

You could just ask them in a clever manner, you know.

Reply on news.ycombinator.com