Enterprise Architecture: Is commitment a worst practice?

There is one sure thing that will kill any project! That is the belief that you must give yourself utterly to it. It's the death of marriage, it is the death of any work environment. To say, I must deprive myself of other things while I give my attention only to you in a foolish practice within large enterprises...



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 leaders managers rack up the debt and only make the minimum payment -- they try to do a bunch of little things to keep the overworked developer happy without solving the problem that made him unhappy to begin with. As a result, the developer begins to cost more and more to keep: bigger raises, more "personal days", more inactive time at work, negative effect on others and so on.

So, going forward you need to encourage commitments where it makes sense and likewise ask for commitments that don't violate other commitments...