Forgot your password?
typodupeerror
Businesses Programming Stats

They Work Long Hours, But What About Results? 285

Posted by timothy
from the management-types-prefer-inaccurate-precision dept.
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.'"
This discussion has been archived. No new comments can be posted.

They Work Long Hours, But What About Results?

Comments Filter:
  • Measuring results (Score:5, Insightful)

    by DoofusOfDeath (636671) on Sunday October 07, 2012 @01:30PM (#41577353)

    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.

  • by Intrepid imaginaut (1970940) on Sunday October 07, 2012 @01:35PM (#41577395)

    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.

  • here in america (Score:5, Insightful)

    by nimbius (983462) on Sunday October 07, 2012 @01:39PM (#41577421) Homepage
    I measure "the rest of my life" in special "vacation time" hours tracked in a database to which i havent any access. I withdraw "vacation hours" to enjoy my life, and in turn the company I work for doesnt fire me for "the rest of my life" on their time.
    these hours, due to the nature of my salaried employment, are however competely subjectively interpreted and at any time i can be called to work during them. The hours outside of $start_time and $end_time for my job are also rather nonexistent. In the literal words of my boss, "we can call you anytime we want." So the problem with "work smarter not longer" is the fact that it is entirely antithetical to the structural composition of "salaried employment."
  • by randalotto (1206870) on Sunday October 07, 2012 @01:45PM (#41577455)
    The incentives are even worse if you're a lawyer. Inefficiency not only makes you look better for working long hours, but it objectively is better from the perspective of your employer. The more hours you work, the more you can charge the client. You solved a problem in 10 minutes because you're smart, know how to research and/or have worked on something like this before? Well shit... we were hoping it'd take 10 hours of research at $400/hour. The billable hour is terrible.
  • by Anonymous Coward on Sunday October 07, 2012 @01:53PM (#41577499)

    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.

  • by hey! (33014) on Sunday October 07, 2012 @01:57PM (#41577533) Homepage Journal

    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.

  • by DoofusOfDeath (636671) on Sunday October 07, 2012 @01:58PM (#41577543)

    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:

    • Specs change mid-project.
    • Developers are often given fewer resources than they say is necessary for a job.
    • Sometimes original project plans fail to anticipate technical problems that will be discovered as the software is being designed and/or validated.

    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)

    by betterunixthanunix (980855) on Sunday October 07, 2012 @01:58PM (#41577545)
    Why not just judge the team itself then, and let the immediate manager for that team decide who is valuable? A team will have goals that fit somewhere into the broader organizational goals; individuals on the team can advance those goals in different ways.

    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)?
  • by DoofusOfDeath (636671) on Sunday October 07, 2012 @02:01PM (#41577565)

    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.

  • by rsilvergun (571051) on Sunday October 07, 2012 @02:07PM (#41577617)
    about the long or even short term well being of workers. If you subscribe to this line of thought you're looking at workers as an asset. That plays well with workers that want to believe they're irreplaceable. Fact is, there's so many people in the Global Economy that you can easily find a worker that can do those kind of hours productively. Sure, he/she burns out. But again, Global Economy. Supply and Demand. There's a huge over supply of workers in a Global Economy, and always will be. And you don't have to train. Desperate workers will train on their own time and their own dime. A lot (most) will be crushed but the debt and stress. But as an employer in a modern, high productivity workplace the 10% that survive are more than enough.

    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...
  • by Hognoxious (631665) on Sunday October 07, 2012 @02:17PM (#41577681) Homepage Journal

    On the other hand, judging results by now many hours were worked is easy

    Actually that's quite hard.

    Measuring how many hours they were present, that's easy.

  • by Anonymous Coward on Sunday October 07, 2012 @02:37PM (#41577815)

    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.

  • by Anonymous Coward on Sunday October 07, 2012 @03:06PM (#41578047)

    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.

  • by hazah (807503) on Sunday October 07, 2012 @03:25PM (#41578165)
    As one on the recieving end of such treatment, all I can say is thank you for seeing the light. As I'm constantly able to use my "free" time to do research on random subjects, more often than I tend to read about different aspects of what I'm tasked on. Each day brings new insight as a result. This allows me to constantly be a number of steps ahead on my approach on each new project. It is a balancing act, and you have to be careful not to over do it, but having the freedom to make such decisions had been invaluable to me as a tool of self improvement. I would even say it had worked for me to do this whenever a mental break was required. A 5 minute read on an equally important though currently unrelated topic is enough time to step away from a problem to refresh yourself and see it in a slightly new way. Our greatest mistake is to treat human beings as machines and expect them to thrive.
  • by rsilvergun (571051) on Sunday October 07, 2012 @03:41PM (#41578289)
    because if they don't they can't compete with the 100+ guys gunning for their job. If it ends badly you blame it on the worker and replace him. When labor's this cheap you can have a bunch of projects fail and not care. You're thinking like a worker, not an owner. An owner has twenty companies he owns. When they fail he writes the failure off on his taxes and moves on. If they all fail he uses his money to buy a bail out from the government (capitalism for the poor, socialism for the rich).

    That trouble is, the way the world works doesn't match up with the economics we're taught in school :(. We're taught that if you work hard and play by the rules you'll win. But the big guys. The owners. The 'Capitalists'. They make the rules. You can't win like that. You can't even stay out of the gutter.
  • by Rob the Bold (788862) on Sunday October 07, 2012 @04:21PM (#41578481)

    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?"

  • by MrSenile (759314) on Monday October 08, 2012 @10:56AM (#41585299)
    I have to comment on this.

    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

"Just think of a computer as hardware you can program." -- Nigel de la Tierre

Working...