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.'"
Comment removed (Score:5, Informative)
Re:Not all companies are the same (Score:5, Informative)
Actually, I would say that this sounds like most Scandinavian companies. I live in Finland, and you're not expected to put in more than your 7-8h per day. Mandatory time tracking systems will not allow you to put in more hours than you're getting paid for, and if you do, you have to keep that time off work. The company can even be fined if you work too much overtime, so it is in the company's interest to make sure you don't work too much.
Whenever we get new foreign people here, they think they can impress with working long hours. But they learn quickly. And working weekends, that's a completely unknown concept. For example, if you work on a Sunday, the company have to pay you up to 400% of your normal salary. I can count on one hand then number of times I've been called in for emergency work during weekends during the past 10 years. I'm a senior developer for a quite critical system.
So, welcome! We have a quite advanced technology sector and practically everyone speaks fluent English here.
Re:here in america (Score:4, Informative)
We have salaried employment here in Norway too for leading and particularly independent positions, you just wouldn't qualify for one.
If they're either a) counting hours or b) tie you to a partially or wholly fixed work schedule or c) expect you to be on call when they want you to work, you're disqualified. Of course they can expect you to show up for meetings or such, but if you're explicitly or implicitly tied to office hours the employer can find themselves at the wrong end of a lawsuit for back pay. In the same vein if you can only work at the office you're disqualified, if they don't acknowledge work in places they don't control you're not independent. Third and probably the biggest is that you choose your work, if you're assigned specific work instead of areas of responsibility you're not independent either.
In the US, I have the impression that making you a salaried employee is almost unconditionally an advantage for the employers, a lot less employee rights and practically no extra restrictions. In Norway, it's a lot more that you can't both have your cake and eat it too. If you want to make your employees independent, you lose a lot of the control that employers normally like to have. Thus it becomes much more of a balancing act, is this really the kind of employee you'd trust to just do good work on their own? If so here's your paycheck, you're not getting overtime or domestic travel costs and you're off the corporate leash but we'll of course be following up on the results you deliver.
Re:Not all companies are the same (Score:5, Informative)
If there are 2 people working 60 hours a week, it could also be 3 people working 40 and most likely more efficient as they won't be burned out.
That depends on whether the task can be broken down into three pieces, and on the degree of communication required.
The other option (and often the more realistic one) is to extend the schedule by 50% -- still two people, now working 40 hours per week, but for, say, six weeks instead of 4.
This issue is the fundamental point of Fred Brooks' "The Mythical Man Month".
Re:Not all companies are the same (Score:5, Informative)
Actually, I would say that this sounds like most Scandinavian companies. I live in Finland, and you're not expected to put in more than your 7-8h per day. Mandatory time tracking systems will not allow you to put in more hours than you're getting paid for, and if you do, you have to keep that time off work.
I live in the United States, and at several jobs the mandatory time tracking system would not allow us to put in more hours than we were getting paid for.
All this meant was that the bosses required us to lie on the time tracking system, and not record the 20-40 extra hours we were putting in every week.
Re:Measuring results (Score:4, Informative)
Hasn't been my experience across a half-dozen entities of varying sizes, but YMMV. (excepting very precise software such as nuclear control or avionics, but that's an entirely different world from business code)
Except for one entity that had used the same process for 40 years and wrote excruciatingly detailed specs for every change they made, and QA'd the heck out of the changesets and the developers. Problem was that it was taking them 9-15 months to get any of the changes spec'd and deployed, and their industry had evolved from one with three year change cycles to a fast-paced fashion-type industry with major market changes every 6 months. Getting your heavily spec'd, perfect software deployed in 12 months wasn't really helping when the competitors were updating their web sites and methods of selling every six weeks.
sPh
Re:Measuring results (Score:5, Informative)
I'm a manager and I find scope creep works both ways. My job is largely protect my team from customers and sales guys who want to change the requirements AND to protect the sales guys and customers from coders who constantly want to leave out or do a halfassed implementation of important features. As much as possible I tell customers and salespeople that their requests are not in scope and would cause schedule delays and cost increases and I tell employees to implement the features as they were originally agreed with customers or sales.
Sales guys are generally a lot worse than customers. Customers generally know what they want and know they don't know what we can do. Sales guys don't know what customers want and don't know that they don't know what we can do.
Of the development guys, the most dependable are the firmware guys, who almost always have a clear idea what they can do with hardware. Then the hardware guys, who are prone to mistakes but know very well how much time it takes to design hardware to meet reasonably well-defined specs. At the bottom of the barrel are the software guys. They can do amazing things but have absolutely no idea how long it will take to do them and can't communicate their status to managers and can't communicate with customers (with a few blessed exceptions).
Re:Teams and goals (Score:4, Informative)
Not sure I'd call it insightful. This is the situation with every team; different people always have different strengths and weaknesses. It's also one reason Agile rarely works the way the "experts" say it should (everyone is supposed to know all about the project and can pick up any task - just doesn't happen in real life).
When Fred Brooks wrote the original Mythical Man-Month and suggested the Chief Programmer Team approach to software development, a homogeneous team was quite the opposite of what he posited. The Chief Programmer Team was supposed to operate like a surgical team, with a designated lead and various supporting specialists. Not interchangeable grunts.