I'm looking for a reference to something I thought I read but can no longer find.
Technical people can work up to 6 hours a day on technical work.
They may be at work longer, reading email, going to meetings, getting coffee, but they can only effectively do 6 hours of technical work a day. (Yes, for short periods of up to a couple of weeks, people may be able to do more. But once they get tired or they're not taking care of their personal lives, they can put in as much time as you want, but you won't get nay more out of them.)
in case you're wondering, I've measured this (number of technical hours of work per day) on some of the assessments I conduct. In several cases, people were only accomplishing about 4 hours of work per day (too many meetings). At the most productive places, the average was just under 6 hours per day.
Let me know if you have a source for this.
Later… I was catching up on blogs and found Ole Eichorn‘s Tyranny of Email. In the essay, he talks about working in three-hour chunks. On page 15, he explains:
Here's another reason for three: it kinds of “fits” into a workday. For example, you get in at 8:30, check email, pick up voicemail, do all that. Then you shut everything off and work for three hours, 'til say 12:30. Now you break for lunch. You get back at 1:30, check email, pick up voicemail, do all that. Then you shut everything off and work for another three hours, 'till say 5:00. Then you check email, pick up voicemail, play foosball, run around and bug everyone, etc. You've had two nice periods of time to get work done.
I think I may have seen this in Robert Glass’ 55 Facts & Fallicies book. Unfortunately, my company is moving this week, so it’s buried at the bottom of a box and I can’t check.
I was speaking to a co-worker about this several months ago, He was reading:
“Agile software development with scrum” and “Agile project management with scrum” both by Ken Schwaber
Hope this helps you find what you’re looking for.
Okay, I spent about twenty minutes longer on this than I intended, and I still didn’t find even a close reference to what you seem to want. I started out thinking that you were paraphrasing, anyway, so I was hoping to find the “real” quote for you.
Having said that, I think you are looking for something by DeMarco and/or Lister (Peopleware 2/e or Slack), Constantine (Constantine on Peoplware, The Peoplware Papers), or Csikszentmahalyi (Flow). Maybe McConnell, but I doubt it.
I hope this helps jog someone’s memory for you.
This sounds like something Watts Humphries would have written or if not, something he would have measured.
I’m sure I’ve read it too, but can’t remember where. Any references in Peopleware?
Here’s a non-technical reference:
http://www.context.org/ICLIB/IC37/Hunnicut.htm
“Through the depression years, the six-hour day functioned as W.K. Kellogg and Lewis J. Brown, the company president, hoped. Jobs were created as the company payroll grew. Plant employees seemed delighted to have more time of their own, especially so since their weekly paychecks were only a little smaller. Workers were paid for seven hours during the first year of the six-hour day, but beginning in the second year, total wages were raised back to the nominal level of the eight-hour day.
Productivity was up, both because of the introduction of new technology and because of Kellogg’s innovative approach to hours and work incentives. In essence, the management of Kellogg’s was sharing the benefits of that increased productivity with the workers in the form of free time.”
This may not be exactly what you were looking for, but is in the same spirit with some numbers behind it.
http://www.caseplace.org/cases3117/cases_show.htm?doc_id=96442
It’s probably not in any books that I’ve read, but on mailing lists and maybe other web-resources, XP gurus have said that pair programming is tiring enough that most XP teams only do pair-programming 6 hours a day.
In “Productivity Management In The Development Of Computer Applications” by John E. Keane, Marilyn Keane and Mark Teagan the following appears: “Actual Productive Time: Expecting a full eight hours of productivity per day is unreasonable because of interruptions, time devoted to nonproject communication, personal business, and other unscheduled activities. A Bell Labs study indicated that approximately 30 % of a programmer’s day is spent in such nonproject activities. In addition, training, holidays, vacations, illness, and other absences have a direct effect on elapsed time and should be provided for in estimates. Keane uses a figure of 80%; IBM 75%.”
As this was written in 1984, we did not have e-mail and surfing the net to deal with. I have been teaching the concept of “productive time” for years. I hope the above helps.