3 ms·

I disagree. I think at least part of that is cultural (I'm in Australia), and part is about what "measuring actual results" really means. The idea that you onl

by timv 11y ago

I disagree. I think at least part of that is cultural (I'm in Australia), and part is about what "measuring actual results" really means. The idea that you only measure results is a worse situation for the engineering team than measuring time. If we only measure results, then a piece of work can be estimated to be "a week's work", and then the engineer is expected to deliver on that estimate and have it done by the end of the week, even if that means working overtime. I don't want that. I want to be able to tell my team that, if they did a solid week's work on it, and it's not done then that means our estimates were out and we'll adjust the plan. But that is measuring time - they did a week's effort even though they didn't get the intended result. The flip-side is that if something is estimated to be "a week's work" and they get it done in 3 days, then I don't expect them to take the next 2 days off. Rather, it means that our estimates were off (in the opposite direction) and we'll pick up some additional work this week. To me, "taking 2 days off" and "only working 5 hour days" are essentially the same thing. So if I had a team member who told me "the task I was assigned for this week is actually pretty easy, so I decided to just finish at 2pm each day", then I'd consider that wildly inappropriate and tell them so. In the same way, if a manager told an engineer "the task you were assigned this week is really hard, so you're probably going to need to work until 9pm each day" that would be wildly inappropriate. I don't care very much what hours my team work, as long as it's effective - which includes having enough overlapping office time do have in depth technical discussions, and so they can provide mentoring and advice to junior team members (or get advice if they are the junior). But if someone is "coming late and going early" (direct quote from the article, but the emphasis is mine) then they're not doing the job that they're hired for, and we need to discuss why. Most engineers aren't employed (paid) based solely on results - and don't want to be, they want to know that if they do their hours, then they've done the job. But conversely, if they haven't done their hours, then they haven't done their job.

facepalm 11y ago
But the job is presumably not "being there from 9 to 5", it is to implement X. So why are you saying "they are not doing the job they are hired for"?
- falcolas 11y ago
  I've yet to work at a job where my job was solely to "implement X". It is usually more along the lines of "apply 40 hours a week towards corporate goals." My team has a feature and bug backlog half a mile long; I could clone myself and still not run out of work. And even if I did manage to close out the backlog, there's more work which could be done towards company goals.
- deleted 11y ago
  [deleted]
- bildung 11y ago
  > But the job is presumably not "being there from 9 to 5", it is to implement X. So why are you saying "they are not doing the job they are hired for"? Most probably because measuring employees by results and not by hours usually means working overtime, not leaving early. If an employer sees you leaving early while getting things done, why shouldn't she just give you more work?
odiroot 11y ago
> So if I had a team member who told me "the task I was assigned for this week is actually pretty easy, so I decided to just finish at 2pm each day", then I'd consider that wildly inappropriate and tell them so. Why is it inappropriate though? Employee happiness is also a part of compensation. Or at least it should be. In a hypothetical situation I would gladly trade a few Ks off my salary for more flexible hours.
barrkel 11y ago
To me, "taking 2 days off" and "only working 5 hour days" are essentially the same thing. If they're the same thing, I guess you'd have no problem with a programmer who comes in and does 40 hours straight across 1.9 days, and takes the other 5.1 days off, right? Not right, I guess. Because there's something wrong with your statement: it's based on the assumption that all hours are the equivalent. But they're not. The longer you're at work, the more mentally fatigued you get. How many times have you worked on something in the evening, only to come back at it the next morning with a fresh mind and realize previous few hours of effort were a complete waste of time, and actually a different direction was needed? You need to step back from something in order to get perspective, both literally and figuratively. When you're tired, nearing the end of the day, it's very easy for your higher brain function to go to sleep and to start bulldozing your way through problems using willpower alone. And you'll do a dreadful job. Incorrect estimation is a completely different topic, because it's a different mechanism at work. Presenteeism is a symptom of management's inability to measure the productivity of an hour's labour during the day. An hour at 5pm might be only 10% as productive as an hour at 11am, or it could even be net negative. Nothing to do with estimates. Personally I believe I have between 4 and 6 hours of productive programming labour in me per day. I'm only good for meetings and occasional discussion the rest of the time. I don't try and write any complex code past 4pm, because I know from experience I'll write it much better the next morning.

by timv 11y ago

facepalm 11y ago

But the job is presumably not "being there from 9 to 5", it is to implement X. So why are you saying "they are not doing the job they are hired for"?

falcolas 11y ago
I've yet to work at a job where my job was solely to "implement X". It is usually more along the lines of "apply 40 hours a week towards corporate goals." My team has a feature and bug backlog half a mile long; I could clone myself and still not run out of work. And even if I did manage to close out the backlog, there's more work which could be done towards company goals.
deleted 11y ago
[deleted]
bildung 11y ago
> But the job is presumably not "being there from 9 to 5", it is to implement X. So why are you saying "they are not doing the job they are hired for"? Most probably because measuring employees by results and not by hours usually means working overtime, not leaving early. If an employer sees you leaving early while getting things done, why shouldn't she just give you more work?

odiroot 11y ago

> So if I had a team member who told me "the task I was assigned for this week is actually pretty easy, so I decided to just finish at 2pm each day", then I'd consider that wildly inappropriate and tell them so. Why is it inappropriate though? Employee happiness is also a part of compensation. Or at least it should be. In a hypothetical situation I would gladly trade a few Ks off my salary for more flexible hours.

barrkel 11y ago

To me, "taking 2 days off" and "only working 5 hour days" are essentially the same thing. If they're the same thing, I guess you'd have no problem with a programmer who comes in and does 40 hours straight across 1.9 days, and takes the other 5.1 days off, right? Not right, I guess. Because there's something wrong with your statement: it's based on the assumption that all hours are the equivalent. But they're not. The longer you're at work, the more mentally fatigued you get. How many times have you worked on something in the evening, only to come back at it the next morning with a fresh mind and realize previous few hours of effort were a complete waste of time, and actually a different direction was needed? You need to step back from something in order to get perspective, both literally and figuratively. When you're tired, nearing the end of the day, it's very easy for your higher brain function to go to sleep and to start bulldozing your way through problems using willpower alone. And you'll do a dreadful job. Incorrect estimation is a completely different topic, because it's a different mechanism at work. Presenteeism is a symptom of management's inability to measure the productivity of an hour's labour during the day. An hour at 5pm might be only 10% as productive as an hour at 11am, or it could even be net negative. Nothing to do with estimates. Personally I believe I have between 4 and 6 hours of productive programming labour in me per day. I'm only good for meetings and occasional discussion the rest of the time. I don't try and write any complex code past 4pm, because I know from experience I'll write it much better the next morning.