*Welcome to End of the Office, our new blog post series detailing the motivation that has led us to dedicate ourselves to retaining a fully distributed workforce rather than consolidating in a single office as so many companies do. In the coming weeks you will see posts from a number of Intrideans explaining the various benefits of distributed teams as well as the perils and pitfalls of traditional office settings.*
Arrive at the office. Log in to computer. Check email. Morning standup meeting. Check bug tracker. Someone asks me a question. Break off a development branch. Code for five minutes. Conversation starts happening two desks over; overhear topic I know about, join conversation. Check email again. Get pulled into a production bugfix, stash my five minutes of code. Switch branches. Deal with bugfix, back to work. Nevermind, it's already time for lunch.
If you think that having all of your employees together in an office will be a boon for productivity because they will have ready access to each other, think again. If you feel the need to have everyone in the same place so that you can keep an eye on them and make sure they're doing work, solve your trust issues or improve your hiring process. If you want your employees to be happy and productive, set them free from synchronous obligations.
One of the greatest gains from a truly distributed team is the natural de-emphasizing of synchronous activity. When the natural communication channels of a business are email, corporate chat, instant messaging, and [microblogging](http://www.socialspring.com/about#stream) the employees are freed up to prioritize their attention rather than having it overridden by the burdens face-to-face meetings (or a phone calls).
### Makers and Managers
Most companies include two classes of employee: makers and managers. Makers are responsible for producing output; in a web development shop, the makers are developers and designers. Conventional wisdom places the role of managers as overseeing the makers. In a successful distributed team, managers do the opposite: they oversee everything *except* the makers so that the makers can achieve the focus necessary to complete business objectives.
This requires, more than anything, faith in the self-direction of your employees. A fully distributed team can only be built through extremely careful hiring. Each employee must be able to function and make small decisions without "running it up the flagpole." If your team has to "sync up" for every minor task assignment your makers will lose the productivity flow from being asynchronous.
If you have external stakeholders in a project, you should do everything you can to block them from having direct contact with the makers. Clients and customers don't understand that interrupting a maker mid-stream is going to completely wreck productivity, nor should they have to. Instead, project managers, client liasons, and other roles should be fully utilized as buffers between the people who do the talking and the people who do the making.
### Fluid Schedule
Another aspect of a fully asynchronous workflow is having a fluid work schedule. Few jobs truly require any kind of synchronous time commitment. Makers need to be able to find their own rhythm of productivity, something that is simple to do with an asynchronous team and nearly impossible to do with a synchronous one.
I find that I work best in three "chunks" of time during the day: a chunk in the morning, the afternoon, and the evening. Ideally these chunks are punctuated by two to three hour breaks during which I can take care of non-work related errands, eat meals, etc. When I'm forced to work on a different schedule than my natural rhythm I find myself waning in productivity but unable to do anything about it. For some people the "nine to five" schedule might fall perfectly in line with their rhythm. Others might prefer to do an intense single block of work in the evening. There is an infinite spectrum of ideal schedules and all can be accomodated in an asynchronous team.
### Asynchronous Tools
The adoption of tools that encourage and support asynchronous work is key to the success of an asynchronous team. Task management systems should ideally include either robust notification systems or other ways to "catch up" on a time period of activity quickly. Communication systems, similarly, should ideally have a way of denoting the "last read" items so that everything new can be consumed quickly and easily without manual scanning.
Synchronous activities such as phone calls, meetings, or even instant message sessions should be quickly distilled into asynchronous tools after the fact. Ideally there should be **no part** of your project that requires synchronous communication to move forward. This means less understanding-by-conversation and more well-written documentation around the project. If you have to have a conversation to understand something, also write the key points of the conversation down so that in the future someone can understand the same thing asynchronously.
### An Asynchronous Office?
Some people like having offices. Some people like working in offices. The existence and utilization of an office is not *necessarily* an automatic blocker to an asynchronous workflow. I would argue, however, that offices encourage synchronous work by default while distributed teams encourage asynchronous work by default.
If you are in an office but want to adopt an asynchronous work style, you will have to institute a policy discouraging the kinds of small, distracting communication that interrupt workflow. Employees should each have private space and focus that is protected from interruption as much as possible. Even if you're all in the same building, use the asynchronous tools as your primary means of communication. Make sure that knowledge is documented, not conversational.
Put simply, adopt an asynchronous workflow and you will see each of your makers operating at his or her maximum capacity.
