They Work Long Hours, But What About Results? 285
theodp writes "HBS lecturer Robert C. Pozen says it's high time for management to stop emphasizing hours over results. By viewing those employees who come in over the weekend or stay late in the evening as more 'committed' and 'dedicated' to their work, as a UC Davis study showed, managers create a perverse incentive to not be efficient and get work done during normal business hours. 'It's an unfortunate reality that efficiency often goes unrewarded in the workplace,' writes Pozen. 'Focusing on results rather than hours will help you accomplish more at work and leave more time for the rest of your life.'"
Measuring results (Score:5, Insightful)
Judging employees by results is great, if you have a good way to measure results.
This is notoriously difficult in creative, team efforts such a software development.
Re:Measuring results (Score:5, Insightful)
Its not really. Specifications -> result. That does depend on having a manager sufficiently on the ball to have constant contact with sales and marketing though, and able to tell them that scope creep will cost more and slow things down.
Really I'm amazed that results based metrics aren't standard everywhere, I've worked with companies where management doesn't care when people show up as long as they meet their milestones. A company that puts "time at your desk" before "results" will be eaten by one that has the two in the correct order.
Comment removed (Score:5, Insightful)
But if you're a lawyer... (Score:5, Insightful)
Re:Measuring results (Score:2, Insightful)
So what you're saying is that management has a real job to do, and that the managers need to have an actual clue about what they're doing?
Yeah, I can see how this doesn't work out very well in most companies.
Re:If I don't have a list of jobs to do, (Score:5, Insightful)
Well, if you worked for me and you left an hour or two early from time to time I'd have no problem with that. But in general I expect people who work for me to spend down time "sharpening their saw" by doing research and experimentation. So if you routinely had nothing to do for several hours a day, I'd expect you to find something to do that'll make you awesome on the next big project. If you didn't find something like that, I would. In that kind of work environment a few hours of "mental health leave" couple of weeks is no big deal, as long as you're doing a good job and getting better at it.
When I managed a development team I recognized that the occasional all-nighter or weekend session was necessary,but I had a policy that my guys had to take comp time *right away*, within a day or two. That wasn't popular; they liked the idea of comp time, but they'd have preferred to bank it. But the point wasn't to compensate them for their extra effort -- they were salaried employees -- it was to make sure when they were at work their minds were sharp.
I believe an engineering team needs three things: skill, energy and focus. "Dedication" is neither here nor there as far as I'm concerned, at least if by that you mean some kind of sentimental attachment to the organization. If you have the big three, you'll get whatever else you need. Too many managers don't manage, they work out a personal psychodrama in which there are good employees and bad employees. To me that's baloney, unless an employee is "good" if and only if he contributes to productivity and "bad" if and only if he does not. An employee who suffers unproductively for the company is neurotic, no matter what else you choose to call him, and shouldn't be encouraged to do that.
Re:Measuring results (Score:5, Insightful)
Its not really. Specifications -> result. That does depend on having a manager sufficiently on the ball to have constant contact with sales and marketing though, and able to tell them that scope creep will cost more and slow things down.
Really I'm amazed that results based metrics aren't standard everywhere, I've worked with companies where management doesn't care when people show up as long as they meet their milestones. A company that puts "time at your desk" before "results" will be eaten by one that has the two in the correct order.
A number of real-world issues can and do stymie your proposal:
In my experience, the best "metric" is having a seasoned software development managers, who's well versed in the details of the project and knows the software developers, to rate each programmer relative to the expectations of that programmer's position.
Teams and goals (Score:5, Insightful)
Let's say, as an example, that you have two programmers on a team, Alice and Bob. Alice writes large amounts of code, which has few bugs and which works consistently, and she is an expert in the languages and libraries that are used by the team. Bob is not great at writing code and does not have the language expertise that Alice has, but he is great at solving problems and figuring out what code needs to be written. If Bob is not around, Alice produces less because she is not as good at problem solving; if Alice is not around, Bob tries to write the code and does a terrible job. Can you really say that one of these employees is "better" or "more valuable" than the other? What about Catherine, the person who is a mediocre coder and a mediocre problem solver, but who is great at keeping the team's morale up and who can help motivate people to meet deadlines (but who is not officially in a management position, and who maybe lacks the qualifications when it comes to organizing budgets or making tough hiring or firing decisions)?
Re:Not all companies are the same (Score:3, Insightful)
Dear sir,
If this company is till in business, please let us know its name, and whether or not they're hiring.
Sincerely,
98% of the programmers on the planet.
This assumes we should care (Score:5, Insightful)
I guess my point is, don't count on your boss caring about your productivity dropping as your hours increase. If you trip and fall there's 100 guys waiting to overtake you in the race to the bottom that is supply side economics...
Re:Measuring results (Score:5, Insightful)
Actually that's quite hard.
Measuring how many hours they were present, that's easy.
Work to much results in not much getting done. (Score:5, Insightful)
As a member of the military, we do heavily take our cues from the Boss (Commander or Chief) When they go home everyone else feels safe enough to head home.
I learned a long time ago that was a pretty stupid thing to do. I've had a lot of bosses that hated their home life or didn't feel like driving accross town during rush hour, or were just burning time to make some regular events so they would stay late for no work related reason.
I get dirty looks when I head out the door on time or early to go to the gym, like I'm skating. The reality is my bosses know I'm a go to guy when things are screwed up, that I've been known to work 16-24 hour straight when they really go south, that I'll come in for however long it takes on the weekends, and can be packed and out the door to Krap-ic-stan on deployment without much fuss...if there is an actual reason to do.
Otherwise I head on home when it's time, take my vacation time without guilt, and ignore the drones' in the office snide comments, who make their own lives missereable while blaming it on work.
Re:How do you get work done during business hours? (Score:4, Insightful)
If you don't have time during your work day to do...you know...work, then that's a failure of management. Why are you donating time to the company just because the management they hire is an utter failure? People like you are the reason these worthless management people continue to hold their jobs in the first place, and it leads to some really warped and twisted expectations of what is to be expected of you and your peers.
As one of your peers, I'm telling you to knock it off.
Re:If I don't have a list of jobs to do, (Score:5, Insightful)
They'll do that in their own time (Score:4, Insightful)
That trouble is, the way the world works doesn't match up with the economics we're taught in school
Re:Measuring results (Score:5, Insightful)
That doesn't even make any sense. I mean, none. Unless you mean the manager isn't part of the team, in which case I'm not surprised you're throwing darts at a calendar for delivery estimates.
Darts would be just as good a tool as the standard practice of "Estimate it'll be done by the time the sales guys promised it" . . .
Actual meeting many years ago . . .
Boss: How long will it take you guys to do this new feature? (This was the first time I heard of this new request.)
Me: I just don't know. It's so different from what we've done before, my estimate is a wild guess now.
Boss: Well, just give me that.
Me: OK, I say two months at least. We don't even know what sort of unknowns we're facing yet.
Boss: Really? You think it will take that long?
Me: Like I said, I'm not sure. We'll have a better idea after we get into it a little and we see the kind of issues that come up.
Boss: But really that long? I thought maybe it would take 2 weeks?
Me: Well, I think it'll be longer than that.
Boss: Are you sure?
This question and answer are repeated and rephrased several times.
Me: (giving up) OK. Two weeks.
Boss: Are you just saying that to make me happy?
Me: Yes.
Boss: How long do you think it will take?
. . . and so on and so on.
I guess I could have told the boss we really needed to invest in a few days investigation and planning so he could have a better number to pass on up the chain. But I knew that the 2 weeks was the number that had been passed down to him anyway, so it didn't matter. And we had the culture: "If you're so smart, how come I'm boss and you're not?"
Re:Measuring results (Score:5, Insightful)
1. Often, there aren't really a lot of unknowns. There are lots of times where the programming task is something along the lines of "Put together a UI that looks like this and behaves like that, takes data from these places over here, and if the user hits the 'save' button shove that data back over here to save it." That entire task is well-defined and quite straightforward, and there should be very little unknown about how to do it.
That's all fine and good, but unless you are heavily indentured into the actual infrastructure of all the systems involved, you're still doing guess work.
'Put together a UI that looks like this and behaves like that'. Yea, so what tool are you using? The existing one? Well, it doesn't allow the buttons to be exactly where the user interface wants. You can't manually hack it. So we have to write a custom module for that. The save button is actually having to talk to a MSQL database over the firewall into a vendor turnkey server, so we have to open up firewalls, write a custom database connector for the MSQL database, and oh, wait, you said the filesystem is on NFS as well? Oh, apparently the background save data needs to be faster than NFS can provide, so we need some SAN local disk as well. Wait, you don't have that in the budget? We have to put it on existing NFS? But it won't be fast enough. Wait, it doesn't matter? Ok, whatever.
If you ever assume a project is 'straight forward and well defined', then you don't deserve to be a PM. It's never that simple. Ever. If you had any experience in the field, you'd know that by now.
2. Estimates provide valuable information to those deciding what to do next. If a developer estimates project A (worth $3 million) at 20 days, that's likely to be a better return on investment than project B (worth $4 million) estimated at 40 days. Somebody just looking at revenue would be more likely to pick project B, somebody looking at the revenue plus the estimate would pick project A.
Estimates appease the share holders and investors. They also help utilize personal hours on projects. Otherwise, there's no real point to them. And sadly, you are absolutely correct that projects utilize the lowest dollar. What they don't realize that a lot of times, PM's, like yourself, are providing them with cooked numbers, based on half-assed quotes, ideas, and expectations without any real input from IT professionals who know their business. You basically tell them exactly what you said. 'We want X'. Give us hours. You don't tell them the budget, or if you do, it's prior to any hardware or software or man-hours. So now the IT professionals have to fit the timetable into the pre-defined man hours. Then other times, the upper management already have promised a deadline on the project prior to getting even you, the PM, involved, so you're just trying to get the IT people to find some way to make the unrealistic time frame work. Feed your BS to someone who doesn't know it for what it is.
3. The procrastination argument is simply wrong. If a developer has estimated 20 business days to do something, he may scramble to get it done on days 18-25. If he's given no estimate, days 20-60 zoom right by and he still doesn't have it done, because he can just put it off until tomorrow.
Then you need to find better employees. When I give '20 business days' to do something, it is the estimate of 20 + 8 hour days. Not '20 days'. Based on your comment above, you equate 20 business days as 20 direct days. Well, I have news for you. IT professionals, like programmers, are doing more than project work. They can not, and will not, be applied 100% on a singular project. The only exception to this are hired consultants who are tasked with ONLY the project at hand. And they are paid hourly for that work, at a very costly sum. For salary employees, they have more than just your p