Thursday, December 07, 2006
Thoughts on the Forty Hour Workweek
Figured I would share a discussion I had last night with a co-worker and fellow architect...
We had an interesting conversation about another peer whom we both respect that is savage in his belief of working only a forty hour work week. This individual does so because he believes in agile approaches to everything in his life and absolutely, positively will not do anything unless it is sustainable. He happens to also be one of the more successful architects that I have had the privelege of working with.
This of course made me think that if I were to plot a chart on the number of hours my peers spend at work and another plot to show a measure of technical excellence would they be inversed? We started to also talk about tactics for accomplishing more work in the same amount of time and even came up with several politically incorrect ways of doing so.
Our first thought was that in corporate environments the need to communicate as a problem space grows more difficult as the size of population grows. Over time, an enterprise instead of forcing folks to keep up will ultimately slow down to the least common denominator which results in above average folks participating in multiple low information dense meetings.
Many people are already known to multitask in these types of meetings whether it is reading their blackberry (NOTE: I do not own one), using IM from their cell phone, etc. One perspective is that folks should eliminate low information dense meetings and use the time for better purposes. Being the contrarian that I am, I will of course desire to do the exact opposite and here is why.
Consider, yesterday your boss asked you to attend three low information density meetings that each lasted an hour and you were able to multitask so that you got a perceived six hours of work out of three. What would happen if you got your boss to consider sending you to a forth low information dense meeting that he didn't want to attend. You would be praised for removing one of his painpoints, he would acknowledge your desire to take on additional work and in the meantime, you would actually get even more time to do real work.
A highly respected VP always tells me that part of enterprise architecture is not the management of facts but the management of perception. Over time perception becomes reality and really good EAs manage to this notion of which by the way is also taught in many prestigious MBA curriculums.
Maybe the answer for me is to increase the perception of workload by inviting in a vendor or two from say the Smalltalk community to tell me about their value proposition while affording me the opportunity to do other things. An even better strategy would be to find an consulting firm who values Ruby on Rails who would immediately classify us as enterprisey and start at such a low information dense way that I am almost guaranteed to not only do twice the work in the same amount of time but in the process also outsource the analysis of the problem space to others who enjoy vendors attempting to determine the architecture for them.
There are only two outstanding questions. First, which consulting firm that loves Ruby should I choose first? Second, I suspect that folks will get it twisted and take this recommendation to seriously, if so, please read my disclaimer...
| | View blog reactionsWe had an interesting conversation about another peer whom we both respect that is savage in his belief of working only a forty hour work week. This individual does so because he believes in agile approaches to everything in his life and absolutely, positively will not do anything unless it is sustainable. He happens to also be one of the more successful architects that I have had the privelege of working with.
This of course made me think that if I were to plot a chart on the number of hours my peers spend at work and another plot to show a measure of technical excellence would they be inversed? We started to also talk about tactics for accomplishing more work in the same amount of time and even came up with several politically incorrect ways of doing so.
Our first thought was that in corporate environments the need to communicate as a problem space grows more difficult as the size of population grows. Over time, an enterprise instead of forcing folks to keep up will ultimately slow down to the least common denominator which results in above average folks participating in multiple low information dense meetings.
Many people are already known to multitask in these types of meetings whether it is reading their blackberry (NOTE: I do not own one), using IM from their cell phone, etc. One perspective is that folks should eliminate low information dense meetings and use the time for better purposes. Being the contrarian that I am, I will of course desire to do the exact opposite and here is why.
Consider, yesterday your boss asked you to attend three low information density meetings that each lasted an hour and you were able to multitask so that you got a perceived six hours of work out of three. What would happen if you got your boss to consider sending you to a forth low information dense meeting that he didn't want to attend. You would be praised for removing one of his painpoints, he would acknowledge your desire to take on additional work and in the meantime, you would actually get even more time to do real work.
A highly respected VP always tells me that part of enterprise architecture is not the management of facts but the management of perception. Over time perception becomes reality and really good EAs manage to this notion of which by the way is also taught in many prestigious MBA curriculums.
Maybe the answer for me is to increase the perception of workload by inviting in a vendor or two from say the Smalltalk community to tell me about their value proposition while affording me the opportunity to do other things. An even better strategy would be to find an consulting firm who values Ruby on Rails who would immediately classify us as enterprisey and start at such a low information dense way that I am almost guaranteed to not only do twice the work in the same amount of time but in the process also outsource the analysis of the problem space to others who enjoy vendors attempting to determine the architecture for them.
There are only two outstanding questions. First, which consulting firm that loves Ruby should I choose first? Second, I suspect that folks will get it twisted and take this recommendation to seriously, if so, please read my disclaimer...
