I had breakfast the other day with a friend who was involved in a group ware company for many years. He introduced the very amusing idea that a good platform strives to be like Seinfeld; about nothing. That’s got delightful synergy with both the idea that a platform vendor strives to create a huge space of options for his developers as well as the the idea that the long tail is impossible to describe.

Then the discussion turned to group ware. We got to talking about the corporate culture shaping power of software.

The first time I observed that was with bug databases. The arrival of a bug database into a project always has a startling effect. It creates a way of organizing the work, call it BD, and it often rapidly displaces other means of organizing the work, call them OM. BD wasn’t just the bug database; it was a entire culture of how to work. Little things happen, for example, dialogs about the issues emerge in the bug comments and if the tool supports it these dialogs become central to the work. Big things happen like the emergence of entire roles such as bug finder v.s. bug fixer. Anxiety managers quickly learned how to leverage the BD culture. It’s a machine who’s crank they can turn. On the one hand, this was all just great.

But BD had a strong tendency to displace other methods, or OM. OM always lacked a name. It wasn’t a single thing you could name; it’s not even a small integer of things. BD doesn’t cotton to redesign or analysis. BD fails at solving any issue above a certain size. BD had a strong tendency to glue problems to individuals. All these preferences and tendencies of BD are a good thing, except when they weren’t effective.

I can recall a occasions when I would get a large problem solved only by changing the person a bug or collection of bugs was assigned to into a team. Conversely there are situations where the right answer was to assign a bug to a nonexistent person – i.e. the person not yet hired or the person who understands this mystery but who didn’t know it yet.

What was unarguable about the BD culture was it’s efficiency and efficacy. Sadly, in the end it excluded the the other methods required to solve key problems. Looks like a nail cause i got a hammer thinking would begin to dominate. Product hard to use, open a bug. Product starts up too slow, open a bug. Customer learning curve too steep, open a bug.

The BD v.s. OM syndrome has a second kind of displacing syndrome. Individual contributors quickly realize that if they want to part of the work culture they need to get hooked up and pay attention to the evolving BD status. This creates a network effect that strengthens ties between the BD culture and the labor. Which is good for the BD culture; but it’s train wreck if hired a given person for his exceptional skill that happens to be a member of the set of other methods. For example you’ll observe the graphic designer wasting a few hours a day reviewing the bug database status and individual bug updates so he can be a clueful participant in the work flow – but since you didn’t hire him for that it becomes cost not efficient.

In chatting with my friend the example we got to talking about was group calendaring. We had both experienced a syndrome where the firms we were working in had installed a group calendaring tool and almost immediately the firm’s entire problem solving culture had been transformed. In this case a GC culture would displace OM.

In the GC culture it’s easier to schedule meetings so you get more meetings. The software has strong opinions about meeting granularity; so you get mostly one hour meetings. Meetings tend to be family sized. The software makes it easy to invite more people, so more people get invited. Meetings by their synchronous nature are exclusionary. Not wanting to appear exclusive with members of the extended family of coworkers people tend to invite additional people. People, concerned about what might happen behind the closed doors of those meetings tend to accept the invitations.

That feedback loop that tends to push meetings toward family sized is the GC culture equivalent of the graphic designer wasting his time reading all the dialogs on bugs. You get brilliant team members attending 3 hours of meetings a day because they happen to know that once or twice during those three hours they will say “Ah, I’m not sure that works.” I’ve seen corporate cultures where that’s considered a day’s work for a brilliant guy. “I’m so happy you came to the planning meeting! You really saved our butt.”

This is, of course, part of the problem of the long tail. The organizational culture that adopts one of these highly efficient methods, call that EM so that BD or GC above are examples of EM, develops a power-law among it’s members. Those members who adopt EM enthusiastically gain a place higher up the curve then those who stick to the core competency. They become the elite and all the usual polarizing forces come into play.

None of this requires the introduction of Machiavellian agendas by the players. People are just “atoms in a jar” as the forces play out: synchronization, efficiency, displacement, cultural network effects, and emergence of the elite and consequential polarization.

I don’t think it’s over generalizing to say that when ever you introduce an synchronizing device you gain some degree of measurable efficiency at the cost of displacing nameless uncountable other methods that don’t synchronize well with the method you’ve adopted. If you can’t name them then it’s going to be even harder to measure them. Why bother to even try if they are uncountable.