Blogs

I recently changed jobs -- from Knowledge Engineer at a product company to knowledge manager at a services firm. Other than the Greater Boston location and uppercase K in the title, the two roles could not be more different. The fact I'll hit the ground running on my search engine configuration feet suggests that the same skills fit both posts.

Au contraire. Little about the daily conduct of knowledge work is plug and play.

Even something as definitive as a release number greeting the market on a release date is only as repeatable as the cohesion required to build it in the first place. The code is frozen. The output is captured. But the collective pieces are moving and those fickle market requirements are hardly static.

Knowledge is not a Product (and other ground rules)

We tried to operationalize this at my former job, using inputs from customer service and engineering to forge a common metadata schema, (a.k.a. knowledge standards) across a searchable range of shared apps and repositories. But a couple of bumps threatened to block adoption -- each one traceable to a product-centric view of KM that plays out in two ways:

1.       Knowledge is containable to an object (the code base that forms the product release). Thus knowledge is beholden to a release calendar and accountable to the folks honoring that schedule.

2.       Any factors falling outside the knowledge-as-object container (customers, rivals, methodologies) are at best diversionary, and at worst, risks to the fixes, improvements, and new features included in those next releases.

In theory point #2 is not even seated at the engineering table. The front office humors marquee customers and market analysts as an input at the inception of a release cycle. In practice there is little collaboration or consent. It's not that sales and engineering butt heads. It's that they live in distant galaxies.

Distant Galaxies

One group is aloof and disconnected. The other uses their ignorance to mask the overreach of promising the moon to pacify large accounts.The leadership in product companies plays the peacemaker between R&D and sales.

That may not be the  modus operandi in the tech industry. But that's the good governance model that KM requires to support the business. The assumption needs to be that we're all on the same team. We are all on the same page with the exception of internally confidential matters. In reality we weren't even all in the same firewall or bound by a common set of access permissions to the same systems of record. Silo-bound was the de facto standard for storing information. No degree of crawling them and configuring a front-end for searching these resources was going to change that.

Confusing Delivery for Value

The services side of KM is helped immeasurably by the fact there are no clear boundaries between doing projects and selling them. Often there's little control and command in the back-and-forth required to do meaningful collaboration. Also, doing KM is just plain easier when you're selling the expertise from the advice we give, not the code we write.

Consulting firms may wrap those wisdom pearls in slides and frameworks. But they ain't selling PowerPoints and matrices. They're selling rationalizations for change. That's a different set of expectations than providing a stable and responsive environment for analyzing a set of conditions or automating a business process. 

Some customers are interested in technology for technology's sake. For the rest of us a product company can seem fixated on the delivery side, even when the buyer is moved by better mousetraps than shinier, newer toys. That's the kind of investment best leveraged by managing client relationships and process know-how. That's a world KM is the cost of doing business in.

But the most exacting search and rigorous taxonomy won't stem the resistance to breaking down the boundaries cast by well-marked turf battles, half-hearted acquisitions, and the vacuum left by governance free information access policies. Enterprise search can't persuade an experienced software developer that he'll know his stuff better by drinking the KM cool-aide. But he might know his stuff better once he gets to know your stuff too.

That's a world where teaming is not limited to individual teams. But if you can't open source within your own community, what's the point of running a KM program?