Blogs

Debt ceiling showdowns ... fiscal cliffs ... today's sequester deadline...

When passions flare, the temptation is always there:

Convince your dissenters that they're wrong.

The better long-term strategy and greater argument to make is that they need to participate. It's as true for our own fractured enterprises as it is for our dysfunctional political system.

A few months ago I switched shops from a Big 4 accounting firm to a high-tech maker of multimedia widgets for the news and entertainment industry.

These two employers couldn't be more different in terms of governance, power structures. and relationships to the markets they serve. One operates less as a business and more as a flagship member of a global cartel of financial services. At its roots the other is a scrappy and resourceful engineering culture that caters to the niche it created.

The one theme that runs across both enterprises is this: There is no there, there.

There is a notable absence of a system-based approach to building on, let alone winning with, the stuff in peoples' heads. There's no shortage of existing licenses on SharePoint, Google Search Appliances, Documentum, Social Schmocial ware and a full stock house of ECM vendor fare. In practice there is an astonishing lack of institutional know-how or the supporting architecture it requires for developing, leveraging, and collaborating across divisions, units, and geographies. 

I can understand the gutted architectures in juggernauts like the Big 4. They could dutifully hire whoever McKinsey tells them to hire, heck ... they could excavate and then eviscerate entire centers of knowledge. The upshot? No one's going to become any closer to finding  the answer to a project requirement inside their cavernous firewalls. That's because no network credential or set of market conditions can match the catalytic clarity of a marching order handed down from a senior partner. Yes, the wind is at your back in these high places when your search commands get executed by support staff rather than technology.

MASH Unit of Skunk Works

You'd think the climb from theory to practice might not be as steep in a smaller, less politically-charged and more market-driven outfit. After all, most engineers are by definition technologists, right?

That assumption may yet prove correct. Architecting project experience into an enterprise level capacity may yet hitch its star to some leaders' roadmap. In the meantime it feels like I'm setting up a health clinic on the outskirts of a hub without a center. The natives are listless and the patients are all surgeons. They could configure this knowledge thing on their own but they have a job to do first.

Hence it's not simply a question of curating their local drives to assimilate a collection of model practices and exemplary templates. That's because each engineer represents a protest vote against the adoption of enterprise anything in the form of lapsed licenses, half-migrated repositories, and an arsenal of network drives. In short, all the stuff they need to do their jobs that was never integrated into a post-merger corporate platform.

So how does one get their house of information architecture in order with the kitchen sink floating somewhere down in the water-logged basement of unassimilated acquisitions?

Take No Platforms

You don't flee the refugee camp. But you do take some big steps back from the knowledge diaspora and you listen good and hard. You send your invites to the squad members who lifted the larger team through their tribal bootstraps to serve customers, work around inertia, and most of all solve problems with little commitment or even recognition that they alone made the difference. Only their go-it-alone heroism stood between a golden opportunity and a black hole of squandered resources.

In Step Two you summarize what you hear, share it with your contributors, and then quantify those risks and opportunities for the purse-string community. Even more importantly than cost justifications is the need to keep your heroes engaged with the knowledge that their isolated successes have a role in supporting the larger community. You do this by asking them for advice about ...

• What assets to provision?
• Which collections to index?
• Where to maintain access permissions (and what becomes commonly searchable)?
• How to integrate siloed systems that hold different pieces of the same customer, product development, and organizational puzzles?

One notable absence here is to pick a tool or application. Whether this is done informally through follow-up meetings or electronically through virtual pulse-taking (please, no surveys!), it's important to focus on the problem at-hand, The tendency here is to race towards the technology fix (tool or feature-based solution) before fully unpacking the issues, (i.e. larger organizational context). Everyone has their favored approach and time-honored way of working:

"Don't mess with my routine, dude."

The bottom line is that we start too often with the tool, not the problem. A devout agnostic that focuses on the overarching business problem has a way of galvanizing communities that are used to operating in enterprise isolation. I conclude with a quote from a recent blog by legion Google Hacker and information therapist Tara Calishain who argues for a tool neutral approach from a research perspective in a recent post entitled Quit Trying to be the Next Google, Dammit:

"Technology is for the purpose of us. We are not for the purpose of technology. When we aspire to merely imitate an existing structure we are doing ourselves a disservice. Even a better Google is still a Google. But to focus on solving a problem and letting people do better those things that make us so uniquely us -- when that is your goal, you have moved outside history, and technology becomes merely an element of construction and not a force that bends you."

That's the kind of commitment we might not expect from the leaders we elect these days but from the allies we seek -- hopefully through the systems we build as information professionals.