It was July 2008, I had reached the height of my Twitter addiction (yes, it was worse), and Twitter was struggling to maintain a stable service.  Twitter was down for hours at a time, and there were a few days when we saw more of the Fail Whale than we did of each other.  During these dark times, my faith in Twitter was shaken.  Although we can laugh now, I had serious doubts about the future of the fledgling platform.

With a little time on my hands, I did what any self-respecting developer would do, I created a clone of the Twitter API and readied it for the moment that Twitter took its last dive.  Fortunately, Twitter regained some of its footing and was able to replace a few of its tires even as the car continued to roll. [I think the car metaphor came from Biz, but I can’t find the reference.]  The product that I had been working on as a Twitter replacement (named “Iron Feed”) looked like it might stay on the shelf.  Rob La Gesse, a friend and partner on this project, provided advice, moral support, and lots of help in testing each piece of the code.  I recall altering the code for Snitter, an early Twitter client, and chatting with Rob using Snitter over Iron Feed for several days.

As Twitter grew stronger, we realized that Iron Feed wasn’t a Twitter replacement, and so we decided that maybe it would find a home as an enterprise service.  After all, the Iron Feed users were stored in Active Directory, the code was built with enterprise tools, and SQL Server was used for the database.  I began coding a web user interface on top of the API and Rob brought on a talented designer named Chris Van Patten to provide the theme for the site.  Overall, we probably completed 95% of the development.  And that was when we simply ran out of steam.  Rob began a new role with Rackspace and I continued doing whatever it is I do.

The code is still there and maybe I’ll pull it out again some day, but even though the service didn’t see a day of use, the experience was invaluable.

I provided the history of Iron Feed to document it for myself, but also to establish a certain degree of experience in thinking through the needs of an enterprise microblogging service.  My product was called Iron Feed for a reason.  While free products that run in beta on the web are fine for consumers, corporate users have a lower tolerance for downtime and glitches.  As I designed Iron Feed, I tried to build something that wouldn’t fail on the client side.  Even if almost every component on the backend was smoking hot, the front end had to maintain its cool.

I’ve worked with GroupWise, Lotus Notes, and Exchange/Outlook.  Although I’ve never been a communications tool developer, I’ve written plenty of interfaces and workflow applications for these services.  My most valuable experience, though, is simply as an end user.  I’ve had to suffer with tools that didn’t do the job and I’ve listened to the grumblings of my co-workers as they’ve struggled to do their jobs with inferior software.

In listing the important features of an enterprise microblogging service, some of my suggestions may seem painfully obvious.  Unfortunately it’s these very obvious things that we techies seem to often overlook.

1. Effortless, Single Signon
2. Front-and-center Launch Button
3. All-in-one messaging (non-email)
4. Incentives vs. Requirements

Signon

An integrated single-signon feature is essential.  Many people in my office use Lotus Notes Sametime, but many other people (including me) don’t, and we’ve been very resistant to its use.  One of the big reasons for ignoring the tool is its requirement that we remember a separate password.  It sounds like a small thing, but no one wants to keep track of the extra password.  We always forget what it is and have to request it again.  For some reason, we don’t have the option to change it.  We can’t keep it in sync with our network password.  As a result, chat tools go unused in my office.  A microblogging service would need to be integrated with existing security or its a non-starter. 

Launch

The tool should be handy.  It should be so handy that it takes almost no effort at all to launch it.  I’m not sure if the best location would be a tab in Outlook, a button in the browser, or maybe even a system tray icon.  Somehow, it would have to be so handy that it would never become an afterthought.

RSS Too!

The tool should include more than just microblogging.  This is a great opportunity to bundle other non-email message formats into a single interface.  While you’re scanning your microblog messages, why not also have an easy way to scan RSS feeds?  I’d like to see RSS used for more things in business, such as workflow and system notifications.  This would be a great time to bundle these items.  Could they be contained in Outlook?  Yes, but not in the way that you might think.  I’d make it a web app that lives inside of Outlook.  Don’t try to force it into the Post format that Outlook supports natively.  I’ve tried the RSS and Twitter clients for Outlook.  They translate the messages into Posts.  It’s just not easy to read non-email messages in that format and I think a different approach is needed.

Incentives!

A few months into my first job, we were all ordered to maintain a log of the things that we worked on throughout the day.  A green-screen mainframe app captured our hours and spit out a report for all of the directors to “study.”  We all resented the chore and I’m sure we all invented ways to fudge things to make life easier.  People will resist microblogging tools in the enterprise.  They’ll resist it because it’s new, or because it’s more work, or simply because they think you’re using it to monitor them.  To lower the amount of resistance, it’s extremely important to use incentives.  Don’t create requirements.  If you establish requirements, people will post minimal amounts of useless information and eventually the stagnant updates will kill the system. 

Although the list will vary for each organization, I’ve put together a few suggestions for ways that enterprise microblogging can be encouraged:

• Create single automated accounts (bots) that people can choose to subscribe to for community posts.  These might include lost-and-found items and “for sale” posts.
• Incorporate personal accounts from other services into your enterprise client (such as Twitter or Facebook).  This is highly controversial, I know, and you’d want to set some clear guidelines for the usage of personal accounts (apply the “be smart” advisory), but it might be a great way to get people involved with their corporate microblogging client.
• As I suggested earlier, incorporate other items into the client, such as RSS feeds.  There are many work tasks that require users to monitor reports and logs.  Setup those items as RSS feeds in the microblog client.  The feeds can display normal warnings and notices.  If there is an urgent error, pop that into an account so that it appears in the user’s microblog stream.
• Train your managers to interact with their direct reports by asking questions about microblog posts.  This is an opportunity for a manager to show interest in the daily activities of his or her staff.  This type of positive feedback will encourage further use, but training will be required.  Many managers will not understand the importance of the feedback loop.
• Encourage managers to find articles of interest on the Internet to share with staff.  Ask questions about the article.  (e.g. “Should we be doing this?”)
• Managers should be allowed to share humorous items such as a favorite comic.  Again, emphasize the “be smart” rule.

The success of microblogging in the enterprise depends on much more than just the tools.  The most important thing to realize is that workers won’t automatically see this as a good thing.  If you are a developer or an implementer, you probably have a very clear view of how an organization can benefit, but workers will just see it as another task to throw onto the pile.  It will be your job to get creative, show people how additional communication tools can benefit projects with real examples.  With the right introduction, these tools can vastly improve organizational communications, but just remember that most workers won’t share your enthusiasm until you answer the question, “What’s in it for me?”