The end of summer is a good time to think about...time.
Maybe it's just the change of seasons, but the end of summer seems to make everyone especially reflective. We all look back fondly on the warm, sunny summer days, and, here in Boston, we look forward less fondly to another long, cold New England winter. And we also think about all the jobs around the house that we had planned to complete during the summer, but somehow never got around to starting.
I was thinking about time this week, and the first time that I had heard the phrase "COB" (i.e., close of business). It was my first job out of college. In the middle of the day, my boss sent me an email requesting (demanding, actually) that I complete a task "by COB." To be honest, I had absolutely no clue what COB meant. I was a recent college graduate, and was trying very hard to learn and memorized what seemed like an endless stream of acronym related to the company's products and technologies. After I was unable to find a definition for COB in any technical documents, I was able to find a co-worker who, when he stopped laughing, was able to explain the term to me.
It's an interesting phrase, "COB." It implies that there is a closing time for the business conducted, or work performed in any given day.
As I'm writing this blog entry, it's late at night in Boston. (The Red Sox just defeated the Chicago White Sox in a night-time baseball game, so, all's right with my world.) My calendar day is closing, but I just noticed that some of my project team co-workers just returned from lunch. It's already tomorrow for them as they are based in Brisbane. The rest of the project's team is based in China, the UK, the Czech Republic, Germany, Sweden, and elsewhere in the US and EU.
Given the geographic diversity of the project team, is there every a COB? I think that the answer is...rarely. The wide variety of locations involved means that there's almost always someone at work on the project.
It's really not that unique these days to work on a team that is not located in the same place. In order for the team to be successful, everyone has to be aware of everyone else's timezone, and make effective use of email and on-line chat tools to communicate. One useful thing to do is to always refer to time (for example, in the scheduling of video or teleconference meetings) in terms of UTC, so as to avoid errors in converting between timezones.
But, beyond any scheduling or communications tools, I think that the most important things to keep in mind involve how you perceive a couple things.
First, the perceptions of "remoteness." It's natural to view the rest of the world relative to your location, your home, your city, your country. For example, on my project's team, I sometimes think about my UK and EU and APAC co-workers as being in remote locations east of me, and my western US co-workers as being in remote locations west of me. [1] The reality, however, is that on this project, everyone is remote. Some offices host more or fewer team members than other, but there really is no "central" office for the project. So, it's important to keep in mind is that it's not "they" who are remote. We all are. No one is "satellite" or 2nd class team member by virtual of their physical location.
Second, the perception of just what a "day" is. Everyone's personal working day is a finite thing. There's a beginning and an end. With a widely dispersed team, however, if you can organize things properly, the calendar days can blend together into a much more flexible and fluid construct. It's sort of like a ship at sea. The ship doesn't turn off its engines at 5:00PM local time. Instead, the crew is divided into teams that work in shifts that are seamlessly put together. It takes effort and organization to ensure that tasks are handed off cleanly between shifts, both on a ship and a software engineering project. You have to be sure that your work can stand alone if a fellow team member is relying on it at a time when you are unavailable. For example, in testing it is extremely important to fully document all bugs that you find with stack traces, server log files, and example code that illustrates the bug. If any of this information is not included in a bug report, then anyone trying to recreate and fix the bug will have to request the information from you, and it may be several hours until you see this request for additional information. The key is to remember that your "day" doesn't exist in a vacuum, but that it is part of an ongoing stream of time and effort, where calendar days can blend together.
I have to wrap up this post now. I have to send some answers to questions to my friends getting back from lunch in Brisbane, and send some questions to my friends who will be sitting down to breakfast in Brno in a couple of hours. It's all in a day...
References:
[1] A note on Bostonians - some of us still see Boston as the "hub of the universe." http://www.boston-online.com/glossary/hub.html
