Friday, November 11, 2011
Enterprise Architecture: Is commitment a worst practice?
In an enterprise setting, commitment comes in many forms. First, there are people who are committed to adhere to office hours, nothing more, nothing less. The flip-side of this is that without an insistence on standard office hours, there are many that would work far more than they should. If a conversation with human resources starts with the notions of a forty, fifty or whatever set hours a week, then the enterprise is doomed to mediocrity.
Agility isn't achieved by standardizing the number of hours worked but by focusing on achieving a sustainable pace. The McGovern principle of work/life balance starts with acknowledging that you can only work as hard as you rest
The whole problem is a result of bad management logic where the thought centers around the notion that a time-clock is an accurate measurement of payment for work done. It's resultant from either a manager that can not comprehend what developers do, or a manager that is too far detached from the daily work of the peons.
For the record, I am not advocating doing away with the timeclock. In fact, I believe there are certain cases where it could be leveraged. If a person can get their work done in three hours and can get time to slack off, they can pay back some of their decompression debt.
In the same way that refactoring pays down design debt, The more overtime you work, the more "decompression" you need in the form of vacations, short-hour weeks and "dead air" (time spent at work not doing anything useful -- or worse, doing actively stupid things). If you never need any decompression, you can continue indefinitely. Sometimes you need to steal some hours now (to finish a project) in exchange for extra decompression later.
The problem is that most projects and
So, going forward you need to encourage commitments where it makes sense and likewise ask for commitments that don't violate other commitments...
Links to this post: