Working Long? Rethink Why

Are you working long? My column, Management Myth 10: I can Measure the Work by the Time People Spend at Work is posted today.

People who work long hours think they also work hard. They are. But they are often not working smart. If you have a lot to do, you want to work smart, not just hard and long. What do you do if you have a manager who believes this myth?

  1. Send the manager a copy of the column.
  2. Run an experiment and gather some data. It's difficult to argue with numbers. Here's how I did it back in my manager days:
    1. Run two weeks of 40 hours. We all agreed we would work no more than 40 hours. We policed ourselves. We measured our output in terms of features. We counted the equivalent of story-points. We also measured our Fault Feedback Ratio (number of bad fixes to total number of fixes).
    2. Run two weeks of the number of hours you want. You want 60 hours, fine.
    3. Choose the number of hours. Police yourselves. Everyone puts in the same number of hours. Measure your story-points. Measure your Fault Feedback Ratio.
    4. Run two weeks of 40 hours. Everyone puts in 40 hours. Report on how easy/difficult this is. Measure your story-points. Also measure your Fault Feedback Ratio.
    5. I tried to do another experiment of 30 hours, but I couldn't get people to leave at 30 hours. I couldn't leave at 30 hours. The experiment failed. We all met during the second day, had a big laugh, and said, “Can we do 35 hours this week?” We barely met 35 hours. We could not police ourselves to leave on time. We all stayed at work until we were there darn close to 40 hours that week and the following week. If you do this, make sure to measure your story points, and fault feedback ratio.
    6. Now, compare your results, recognizing that fault feedback ratio is a lagging indicator, especially if you work in two-week iterations.
  3. If you work in kanban/flow, use cumulative flow and see if your average time to complete a feature goes up or down depending on the time you spend at work. I am curious. Track your fault feedback ratio.

Your data will tell you more than your gut will. You want evidence for your beliefs.

Remember that our brains get tired. Even if we move around and provide our brains oxygen, water, and a little food now and then, it's not enough. Our brains need a break.

You and I have had our best ideas in the shower, in our dreams, while talking with others, while not working.  There's a reason for that. There's a reason that after I draft an article I let it sit for a while. If I let my subconscious work on it for a while, and I'm fresh, I can do a much better job when I return to it.

Don't just work long. Work smart.

9 thoughts on “Working Long? Rethink Why”

  1. Amen, amen, and amen to this post and the Management Myth 10. You have summed up my collection of thoughts on this matter of “presentee-ism” so well! I don’t know if I have the freedom to try the above experiment, but I’m going to play with it.

    I’ve been researching productivity and applying agile methods to personal productivity, with good results.

    I also find it interesting that you don’t completely follow the OHIO rule (Only Handle It Once). I don’t either. Especially for communications like blog posts. I want my thoughts to be “fully baked” and presented as concisely as possible. Well-written means a lot of editing.

    1. Jenn, I was working with a team who was convinced that more time was better. So was our management. I was tracking our Fault Feedback Ratio and our defect trends, so I knew it wasn’t. I said, “Let’s experiment and see. If I’m wrong, fine. If you’re wrong, please, please, please, let’s stop the overtime. Because I think it’s killing our forward progress.”

      I have a theory about code-writing. I know that when I pair-write English, as in an article, I don’t so much put-it-away time. I’ve pair-written with Esther Derby, Gil Broza, Lisamarie Babik, Shane Hastie. Maybe more? When we ping-pong, we need more time. When we pair-write, we need much less. When I write by myself, I need put-it-away time. I believe the same thing about code. If you pair, you have built-in review. If you swarm around a story, even better. If you do it yourself, you better be ready to write it three times. Or, maybe I was just a not-very-good developer. Although, my code was quite reliable once it worked.

  2. Pingback: Five Blogs – 14 November 2012 « 5blogs

  3. Johanna, very interesting! I never really thought about “pair-writing” (or swarm-writing) before. But, it’s true. I guess I could say it’s true for thinking, too. When I’m wrestling with thoughts, I “put out the word” to friends and get lots of great feedback on my thinking that helps me refine what I want to say a lot quicker. I need to give the “pair-writing” or “swarm writing” a go…

  4. I am convinced that you’re right, but how to apply this methodology from the developer side?. It is almost impossible to convince a leader or boss that this really works.

  5. Pingback: Time is not results | Project Aria

Leave a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: