Yammer And The Federation Of Work: Going The Wrong Way

Yammer has decided that they are going to go down the old Basecamp path, and force people who work with different companies to have separate logins:

via email

Dear Stowe,

We want to make you aware of a change to Yammer that will have an impact on you. You currently have more than one email address registered to your Yammer account. We’ve decided to move to a one-email-per-account model. This means that we will soon remove secondary email address(es) from your account.

Why are we doing this?

As Yammer evaluates its plans for future product features, we’ve realized that allowing users to have more than one email address linked to their account could result in potential problems. For example, admins from different networks might seek to apply conflicting settings to an account which is in both networks. There could also be confusion between work and personal Yammer accounts. We believe that cleanly separating Yammer accounts based on one email address per account is the best way to avoid these problems from occurring in the future.

How does this affect you?

• We will create a separate Yammer account for each of the following company email addresses that you have: stowe@js-kit.com and stowe@ninety10group.com
• When you want to switch between these Yammer accounts you must first log out and then log in with one of your other email addresses.
• Your same password will be securely copied to each of your new accounts.
• Soon, our desktop and iPhone applications will allow you to be logged into more than one account at the same time. Just register each account on the application and you will be able to toggle between accounts.

If you have any questions or concerns, please contact help@yammer.com

We appreciate your patience, and apologize for any inconvenience that this change causes you.

Thanks for using Yammer,

The Yammer Team

This is a particularly bad move. First of all, it will lead to the same Federation of Work problems that I wrote about years ago vis-a-vis Basecamp:

Basecamp and The Federation Of Work

I have run up against what I think is a basic flaw in the Basecamp model.

Many times in the past few months, I have started a project up with a group, or groups, who like me are already using Basecamp. The problem that arises: Whose Basecamp implementation to use?

I would, of course, rather manage projects that I am involved with in my own Basecamp instance, while the others have the same perspective. But what happens, quickly, is that I have a bunch of memberships in other Basecamp projects, which do not collate into a coherent single view.

What’s missing is a fundamental insight: the federation of work.

Basecamp lacks the notion of federating project work. While I can invite my pal, Greg Narain, to join a project I am running, Basecamp is only willing to consider Greg as another individual, not as the owner of his own Basecamp instance. As a result, Greg must login to my instance to participate, and the status of the project does not show up on his dashboard.

The solution? 37 Signals should rework their participation model to reflect their new-found success: there are thousands of Basecamp users out there, and more of us will be running into this limitation. More important, perhaps, is that a federated model more accurately reflects the nature of the world. I am involved in a dozen or so projects, and I would like to have a single, coherent view of what’s going on across the board, as do all over my partners-in-crime.

Certainly, a single company still needs to be the administrator for each Basecamp project, but that doesn’t mean that we need to login at ten different instances everyday.

Basecamp should look at the federation model of Jabber and other successful bottom-up, federated tools. Within Jabber, I can login to my local server, and IM with any other trusted server in the world. The servers simply have to establish a trust relationship. In the Basecamp world, I should be able to invite Greg to participate in a project, and when he agrees, he should be able to simply point at his own Basecamp instance, rather than having to create a brand new, easily forgotten login.

At any rate, Jason and company are well-known for rejecting new features, but this is more than that, this is a fundamental need that should have been forseen from the start. And, in a way, it’s just another indicator of the success that the product enjoys.

When I wrote that in March 2006 it led to an argument with Jason Fried of 37signals, who basically said I was an edge case. I pointed out that success would lead to more of this sort of use — individuals working with many project groups in many companies. I said he would have to fix this falw, and years later they hacked an afterthought onto Basecamp to make it easier to switch accounts.

Yammer is headed down the sam cul-de-sac. This is a bad move, and one that irks me personally since I sketched out a vision of federated businesses collaborating through Yammer a year ago to the CEO, David Sachs. Obviously, I didn’t make the case persuasively enough.

Consider this idea. Imagine tens of thousands of companies that are managing work using a service like Yammer. Imagine if a company, AdjectiveNoun, could post a request for proposal, and distribute that to all companies and individuals that are following the company. Responses to the RFP could be directed to a defined context in AdjectiveNoun’s Yammer implementation, and would be streamed to AdjectiveNoun staff.

I think this is a breakthrough idea, and the first company to do this well will explode.

But you can’t get there without a federated model of work, and a global namespace. So Yammer is going to ultimately unjigger this mess they are creating. Probably not until some upstart comes along to upset things.

Maybe I’ll see one this week at Techcrunch Disrupt, who knows?