Hitchhiker's Guide to Software Architecture and Everything Else - by Michael Stal

Friday, May 30, 2008

There is no business like office business

In the last weeks I enjoyed small talk with several software engineers from various companies. Topics included technology and architecture, but also office work, management, colleagues and career paths. And several times I heard from companies where a couple of characteristic metrics for measuring engineer productivity exist. Let me exaggerate a little bit:

  • One of the wide spread metrics is office availability. I am speaking about engineers sitting in their offices or cubicles from early in the morning until late in the evening. This is something I fully understand for projects being in critical phases or delayed. Of course, I also did it and will do it in the future. But I also heard about engineers staying in their offices very late to send an implicit message to their management. Something, like "Look, I am working so hard for the company. If you don't promote me, you should suffer from remorse." However, the truth according to several studies is that you cannot be productive for 8 hours or more per day, at least not over a longer time span. Even worse, if you stay in office, your bug rate will increase significantly and the results will be not better than staying in office for less time. I know the stories about employees in Silicon Valley or Redmond sleeping near to their office PC. There is a reason why eXtreme Programming does recommend reducing work time to under 40 hours per week. And all of you believing in 16 hour work days, no matter wether you are good (engineer) or evil (manager): productivity in such overload situations is not possible. You either have many simple tasks or spend significant time twiddling your thumbs. Today, I read an article that an increasing number of IT workers suffers from the burn-out syndrome or other diseases which are caused by work overload.
  • Another wide spread metrics is internal visibility. Do you remember Bertrand Meyer's "bubbles don't crash"? Management tends to rather promote engineers who spend significant time presenting and chatting to management. If you don't provide a steady stream of good news (even if you invented this stream of good news) to the right persons, they won't even notice your existence in the worst case. Often, not the real results count but management visibility which is measured by .. guess what .. Powerpoint presentations, Word documents and Excel sheets. Don't forget that e-mails and meetings represent additional, important means in this context. Considered from this perspective, virtual reality has already conquered the world.

There are a lot of lessons we can learn from these statements.

  • First of all, Work/Life balance may be a buzzword, but from a useful one if you ask me. For example, if I recognize that my productivity is dropping to almost zero,  I am leaving office, go for running or biking, and then continue with my work, often until late in the evening. Such extended breaks provide me with a significant productivity boost. It might appear unbelievable, but I am definitely more productive that way than if I had spent the breakout time for office work.
  • If I need to concentrate I will also work at home from time to time rather than spending the time in the office. With my phone constantly ringing, colleagues dropping by, and other continuous interrupts, offices don't really provide an adequate environment for creativity and brain workers. Ok, I am missing my colleagues and the social interactions after a short time. Thus, home office is the exception. Fortunately, there are so many opportunities (phone conferences, meetings) to interact :-)
  • Effectiveness and efficiency are/should be the only things that count. It does not matter when or where you created your results. However, you need to make sure, managers are aware of your work and what you achieve. Marketing your own person is an important issue in a universe where managers can't afford tracking all work results from all engineers. If you coach some colleagues as a mentor and if you promote their visibility and career path, inform your managers. Improving skills of co-workers and other more indirect results offer high business value to a company.

Interestingly, all these points are also valid for architects. However, home days are often a bad idea in those hot project phases when creating or enforcing software architecture. For an architect, communication represents the most important instrument. Communication works best in Face-to-Face meetings. But, nonetheless, also in these situations you need to plan your recreational breaks to enforce Work/Life Balance.

3 Comments:

  • There's also an interesting thought from Lean that's related to this.

    If you are working more than 40 hours a week regularly (normal workload), what happens when workload peaks (ie..missed schedules, etc)?

    You have to leave a little slack if you want to absorb the surprises.

    No wonder Google lets their employees do their own thing 20% of the time. If their projects get into trouble, they have a cushion built right into the work week.

    Working crazy hours is actively harmful, not only to your health but also to handling the unexpected.

    By Anonymous Evan, at 4:39 PM  

  • The 20% at Google helps employees leverage their creativity. An engineer may use the time for setting up her/his own project or participate in someone else's project (available from a project list). Nonetheless, a company may put pressure on you to prove what you actually accomplished in your 20% "spare time" which I would consider as counterproductive.

    Spare time is the time where no one expects or should expect from you to accomplish work goals. Since most of us enjoy their work, at least most of the time, the differentiation between work time and spare time might be very difficult. For example, should I consider writing this comment as work or spare time?

    I have decided to differentiate work time (where I need to accomplish work-related tasks), spare time (time where I really do recreational activities such as Sports, Music, ...), and a kind of twilight zone (where I do some relaxing creational work or competence ramp-up without anyone expecting me to do so). I believe, we should balance work time + twilight zone with spare time.

    It is as simple as this. The more work time, the less time remains for life. The more spare time, the less time remains for work. You need each of these areas to enjoy the other. 8 hour working days are challenging for creative and brain-related activities as well as for activities involving a lot of social interactions.

    By Blogger Michael, at 11:20 PM  

  • I have to agree with you on a few points, but the one that jumps out at me is working from home.

    Most office have the setup completely wrong for developers and architects alike. When they ( architect / developers ) are in the design stages they need to concentrate, which means, at least for me, need quiet. Unfortunately in most places these days they are setup with cubicles right on top of each other and the noise at times drives you mad. People talking loudly, having meetings right next to you, people laughing, phones ringing, printers printing, faxing going off, etc...

    They say that once a developer/architect loses their concentration it takes an hour to get back to he point when they were interrupted.

    I realize that there are times you need to be on site in the mix of things, but for me when it comes to design and when the meetings are over, I head to my home office and knock it out.

    Now that we are more now than ever in a virtual world with high speed access everywhere we look, I do not see the need to have to have people in a cube 8-12 hour a day. As long as the work gets done and as long as people are available as needed for whatever reason, off site working condition should not be an issue.
    Well at least that is how I see it...

    Thank you for the post, I really enjoyed reading it.

    By Blogger Kevin Saitta, FDLC, at 11:59 AM  

Post a Comment

<< Home