• Read more about End of the Office: The Joy of Asynchronizing

*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.

• Read more about Hire a Guard for Your Project

Of all of the new tools that I've picked up using for development in the past six months, there is one that has come to stand above the others for its nearly universal utility. That tool is Guard.

Guard is a RubyGem but don't let that fool you into thinking it's only useful for Ruby projects. Guard is essentially an autotest for everything. It provides a general purpose set of tools for watching when files are changed in your project and taking action based on it. You can use it to do just about anything, but common uses will include:

• Re-running automated tests after a file changes.
• Automatically compiling scripts or assets for a project (e.g. minification).
• Installing new dependencies that may be added to the project.

With a little creativity and a slight bit of Ruby coding, though, you can make your entire project's workflow run smoother and faster. It's like having a telepathic robot buddy who just goes around doing whatever you were about to do next without having to be told (except the first time).

Getting Started With Guard

Guard requires a basic Ruby setup. Once you have Ruby and RubyGems installed, simply run:

gem install guard 

This will get you started. If you want to make it easier for others to run your guards as well, you should also install Bundler to encapsulate the different guard gems you'll be using:

gem install bundler 

Once you have these installed, in the root of your project run:

guard init 

This will initialize a Guardfile in the project root that will be telling Guard what to do going forward. From here, you will want to install some of the Guard extension gems that let you quickly create automation for your project. Some of my favorites:

• guard-rspec: Automatically run RSpec tests based on easy-to-customize patterns. I use this on almost every Ruby project these days.
• guard-coffeescript: Compile Coffeescript into Javascript lickety-split. Even though Coffeescript has its own automatic build command with the -w option, I prefer Guard because it lets you define the configuration once and, in addition, run a single process for all of your project's automation.
• guard-process: This is the guard for anything they haven't made a guard for yet. Using this you can quickly and easily run shell commands as soon as files change, giving you the ability to do almost anything.
• guard-sass: Never write vanilla CSS again. Using Guard SASS you can automatically compile SASS giving you the full power of mixins, variables, and more for all your styles.

There's a full list of guards that include all kinds of magic (there's even guard-livereload that can automatically refresh your browser whenever you make a change to a project), and it's dead simple to create new Guard libraries if what you want isn't available (or you can just use guard-process).

Standing Guard

For any of the Guard gems you install, you can add them to your Guardfile by running:

guard init guardname 

Where guardname might be rspec or coffeescript, etc. That will fill your Guardfile with a basic implementation of the given guard and is usually enough for you to tweak the settings to your liking without further documentation.

There's a great example of using Guard for a big Rails project, but I'm not just using it for Ruby. I've used Guard on jQuery plugins, Node.js projects, even static websites that I've been building (more on that a little later).

To make it easier for others to jump into your project with Guard, it also helps to use Bundler to maintain a Gemfile that points to the various guards you're using for the specific project. Just run bundle init to get Bundler up and running then edit the file to look something like this:

source 'http://rubygems.org'  gem 'guard' gem 'guard-coffeescript' gem 'guard-process' 

Then run bundle install. Once your gems are installed and you've set up your Guardfile, just run:

bundle exec guard 

Guard will start up right away and your project now has some smooth automation action. Guard will even reload itself if you modify the Guardfile, so feel free to tweak as you go!

Guard in the Real World

I'm going to post just a couple examples of Guardfiles I've been using in my projects recently to give you an idea of its versatility.

Guarding a jQuery Plugin

Here's the Guardfile for Sketch.js, a jQuery plugin that I just released:

# Automatically build the source Coffeescript into the lib directory guard 'coffeescript', :input => 'src', :output => 'lib', :bare => true # Also automatically build the test Coffeescripts guard 'coffeescript', :input => 'test', :output => 'test', :bare => true  # Run Docco  guard 'process', :name => 'Docco', :command => 'docco src/sketch.coffee' do   watch %r{src/.+.coffee} end  # Copy the newly created lib file for minification. guard 'process', :name => 'Copy to min', :command => 'cp lib/sketch.js lib/sketch.min.js' do   watch %r{lib/sketch.js} end  # Use uglify.js to minify the Javascript for maximum smallness guard 'uglify', :destination_file => "lib/sketch.min.js" do   watch (%r{lib/sketch.min.js}) end 

This enabled my workflow to be instantaneous: I could immediately look at my work whether it was in my examples, my tests, or my documentation. Everything was immediately built and I never had to slow myself down with run and refresh cycles.

Guarding a Node.js Project

I've probably only scratched the surface here, but a simple Node.js project that I'm currently working on has this for a Guardfile:

guard 'coffeescript', :input => 'src', :output => '.', :bare => true  guard 'process', :name => 'NPM', :command => 'npm install' do   watch %r{package.json} end 

Notice that using guard-process I'm automatically installing new dependencies that may arise when the package.json file is altered.

Guarding a Static Website

I've come to really appreciate both Coffeescript and SASS as worthwhile abstractions, so even if I'm building something that's vanilla HTML I might have a Guardfile like this:

guard 'sass', :input => 'sass', :output => 'css' guard 'coffeescript', :input => 'coffeescripts', :output => 'javascripts' 

These are all basic examples, but that (to me) is the point: Guard is so simple to use and basic that you can drop it in every project you build. I've yet to run into something that I don't want to use Guard on.

Tip of the Iceberg

I've been expanding my usage of Guard into, well, everything that I'm working on. Thus far it's included Ruby, Javascript, and static HTML projects, but if I move on to other things Guard will be coming with me. For instance, I'd love to build a Guard to automatically recompile and run an Android application whenever the XML views change. The possibilities are limitless.

If you're not using Guard, give it a try on one of your current projects. I think you'll quickly find immense satisfaction in being able to simply cd into the project directory, run guard, and know that you are completely ready to roll. I'd like to see a Guardfile in every open source project I fork, every client project I clone...Guard is so useful that I simply want to be using it all the time. And that is the mark of a great tool.