Two companies (at least) are trying to apply the concept of Twitter to business intranets. This starts to sound more exciting when you wrap your head around the promise: complete elimination of status meetings.

Yammer and Present.ly are the companies people think of. But I wanted to share what we at CrowdVine (and a lot of other people in tech) are already doing, using a Campfire chat room.

The community around Campfire has a very developed sense of something that Yammer and Present.ly are just starting to realize — most business status can be generated passively.

Instead of intentionally updating my status to say that I’m filling out a work order, that I’m updating a piece of code, or emailing with our favorite client, we have our tools generate those updates automatically. Our status updates flow into the chat as we work, no special actions required.

I’ll quickly describe what this looks like technically, but what I really want is to explain how this works socially. CrowdVine keeps a Campfire chatroom open all day, not because we’re chatting all day, but just to have a place where we can reach each other. This takes the place of being in an office. We use a service, GitHub, to host all of our code. Any time we checkin code, GitHub sends a notice to Campfire (this is a service built in to GitHub). We also use a service, Highrise, to keep track of all of our client history. We have a script, available here, that updates Campfire every time we change a client record. For status updates that don’t fall into those categories, Campfire has a topic function which we update and which leaves an entry in the chat.

The first two types of updates (GitHub and Highrise) are passive updates. They update based on what we’re doing, but without any intentional action on our part. The last update is an active update. We have to make an intentional effort. That’s the way Twitter works.

There are some great buzzwords getting created by this niche. Ambient awareness, knowing what’s going on in your periphery. Asynchronous knowledge transfer, catching up with your coworkers when you have free time rather than going to a scheduled status update. Activity permanence, the ability to search an historical record of your updates (I just made this buzzword up).

People are rightfully jazzed about these concepts. You end up knowing more about the projects you’re working on, while saving time on meetings, and avoiding interruptions.

There’s one more benefit that I’m in love with, momentum. We started out with just the GitHub updates. We’d go through weeks where I was only talking to customers. Jay would be busy on code, filling the chat room with status updates, while I produced nothing visible. I felt like a major tool. Now when I’m talking to customers, I generate just as many status updates. I feel like we feed off each other and I push myself to finish my tasks so I can get the reward of a status update.

I’ve been learning about two concepts on the side, positive-reinforcement dog training and deliberate practice (focusing on the quality of your work, not just the quantity of your work). When I got into deliberate practice I realized that everything I was trying would go much faster if I could have instant positive reinforcement, like Pavlov ringing a bell at the instant that I completed a positive step.

In dog training, you use a clicker rather than a bell. With some treats you can transfer a small positive association with the sound of the click. Then with the clicker you can transfer that positive association to behavior. I’ve heard that some gymnasts are using clicker training to reinforce their movements. A movement completed successfully gets a click from the coach. The click reinforces the brain pathways that produced the movement and the gymnast’s brain is then more able and more likely to reproduce the movement.

The status updates are small rewards, like what you’d get from a clicker, and they reinforce two behaviors that are generally positive.

One, we’re rewarded for completion. A good idea, a chunk of code, a well written email are all worthless unless they are implemented, committed, or sent. Our automated updates tend to only happen when something is completed, a chunk of code is committed, an email is sent, or a client record is updated.

Two, we’re rewarded for breaking tasks into smaller steps. This is especially true of code. Rather than keep code checked out for weeks at a time, we are rewarded for breaking it into independent chunks that can be checked in. You might consider this gaming the system, and it is, but I’ve always been a believer in the Edsger Dijkstra quote, “The competent programmer is fully aware of the limited size of his own skull”. We’re rewarded for incremental work, and incremental work has the benefit of being easy enough to do well.

I heard a story about a programmer who gave up on his team’s campfire chat room because he found it distracting. His work, at the time, was to spend three months, by himself, building a data warehouse. From this story, I can extrapolate some helpful tips. Read the chat log at your leisure. Feel free to scan. Your feedback is not urgently required. It’s not supposed to be a burden.

The depth of ambient awareness, asynchronous knowledge transfer, and what-have-you, definitely depends on how much time people spend studying the updates. But the momentum benefit just depends on the idea that people will see the update, that there’s an audience that’s going to be impressed by your prodigiousness.

I have one more anecdote supporting the power of having an audience. I’ve worked for two companies that had continuous integration testing, a system that would run automated code tests after each code check-in and then send out a notification. The most common time a notification would be generated was when someone was in a rush to get out the door.

One company sent the notification by email. The other sent the notification to a campfire chatroom. For some reason, people at the email company seemed to check-in broken code all the time. People at the Campfire company almost never did. It’s hard to prove, but I believe the reason is that people at the second company were afraid that the notification would generate negative comments from the other programmers about what a lazy, inconsiderate programmer the person was. At the email company, it was as easy to ignore an email as it was to respond, and if you were going to respond, easier to respond to the culprit rather than the group. So there was less social pressure.

These notifications were a special kind of passively generated status. They said, “I’m screwing up right now.” You don’t want to generate that status.

The anecdote about broken tests is one reason I prefer my business microblogging tool hacked into Campfire. It’s nice to be able to talk about or respond to some of the updates. The other reason, is that it fits into a work flow rather than adding another place that I need to check.

If you’re a programmer, then Campfire is definitely ready for you. Almost every service you use has a Campfire hook. Check GitHub for a lot of tools including Backpack, Basecamp, Continuous Integration, Twitter.