KM in the Jerkplace: Episode Two -- Knowledge Engineering for Solitary Scrum Masters

(c) http://3.bp.blogspot.com/

Installment Summary: The Big Four knowledge survivalist jumps into the awaiting arms of the engineering camp for a once mighty developer of media software – back when hardware mattered. At first the opportunity is virgin territory. This inviting place to plant the knowledge flag is signified by efforts to source and build a search capability for leveraging the company’s collective assets. The initial optimism is however tempered by factional infighting and an unwillingness to fly those engineering colors under the SAME flag.

The Factory Gates Open for Knowledge Engineering

A week before I was to ship out as a SharePoint business ninja within IT, I hitched onto a passing knowledge raft. This water-logged trial balloon was powered by the knowledge-seeking curiosities of the engineering arm of Keen Core Technology – arms dealer to Hollywood, TV, and recording industries, and now under siege by an unceasing array of disruptor insurgencies from all sides of the media production spectrum.

While I had worked along-side IT and engineers with MBAs (a.k.a. “management consultants”) I had never been subsumed into the belly of the engine room: that is IT itself. I learned software-making as a repeatable cycle in need of documentation as-in coding the coders. I learned about daily stand-ups as the perfect antidote for task-drenched programmers who would rather be writing code than getting sucked into meetings.

My mission at Keen Core was to classify the wikis, channel the documentation stream, and socialize the release cycle of the half-dozen or so product development teams. Ultimately this meant distilling all these outputs into a single automated helping of digestible knowledge called “search.” The fact that there was no enterprise-wide answer to the perennial how-do-we-know-what-we-know question meant two things to the engineering crew of Keen Core:

1. Conceptual – how do we boil this ocean of applications, file-shares, lapsed repositories, and group-based collaborations from Outlook to Google Docs?
2. Practical – once boiled, how do we care and feed this resource so we can retreat to our safety zones in the comfort of knowing we can test our forward-leaning hunches against our collective history?

The Knowledge Safety Net

From a theoretical perspective the wish list that brought me to Keen Core began and ended with the same staggering and sober realization: we can scale the production of code but we don’t have a clue how to trap, catalog, and ultimately leverage the by-products of that effort.

This overwhelming sense of an organization’s inability to get out of its own way is not well-served by a top-down inventory of all assets – whether they live in the U.S. Patent Office or under “the digital landfill” as AIIM's John Mancini would say.  Rather than over-analyze the backlog of dumpster-grade documents, we looked to establish the safety net – not the uber knowledge archive.

There was nothing random to this sampling. Domain experts come out of the wood work – reluctantly sometimes because they’re often “heads down” …

• On some failure-is-not-an-option mission, or
• Closing in on some new shortcut to faster, better, cheaper.

These are not the sycophants of social media in search of the likability badging trophy. 

These are the folks who build stuff. They might not communicate effectively and their managerial skills lapsed long ago – if they ever had them. They are socially speaking apolitical, meaning they are drawn to fixing problems, not towards handling them. They are by-and-large drawn from the ranks of engineering and they are my brilliant, argumentative, recalcitrant, misunderstood people.

These are the ones who emerge when the call goes out for who-knows-how-stuff-works. And like their own circles, the documentation they travel in lands off the documentation radar. It lives on the outskirts of any centralized repository that confers authority, explains connections, or unpacks the experience that inspired it. In the case of the Keen Core safety net it was little more than providing a link to an obscure server I might or might not find password accessible. But after a series of non-threatening prods I had my unofficial off-the-map collection of references that the engineering teams swear by.

Not the sanitized intranet they were used to swearing at.

The Bake-off

The legendary chef Julia Child once said, “Always start out with a larger pot than what you think you need.” She might as well have been describing the process for picking an enterprise search engine. This proof-of-concept or PoC is your due diligence for matching internal priorities and selection criteria to your bake-off results. PoCs demand an improbable mix of reference able work product – no matter where it comes from, the application particulars, or the sub par referencing used to catalog the electronic version of what lives inside organizational roles and responsibilities.

Once I had my vetted safety net, I was clear to map them to the safe harbor of the search interface where memories get tested, experiments are run, and explanations are concocted.  That mapping included a healthy respect for the mismatch between Googling for cat videos that stick to our social billboards and researching a backlog of databases that live behind a corporate firewall. A PoC was undertaken to reduce the vast, uncharted wilderness of Keen Core to a single search box and a choice of search vendors – hence the “bake-off” that played out against the following design choices:

#1 – Fact versus Conceptual Search: Most business problems are not reducible to the distance of the closest pizzeria with the highest reputation ranking. In other words the answer is neither immediate nor obvious. It’s not persuasive on its own but needs the back-story to connect its relevance to the problem at-hand. That connection can only be provided by the searcher – not the search engine. The conceptual search idea was welcome by my colleagues as they were well-acquainted with the status and responsibilities of domain-expert-as-content-curator.

#2 – Single Answers versus Iterative: Because of their research-focused nature, most business or enterprise search problems are not only conceptual but iterative. They are greatly influenced by changes in time frame, authorship, formatting, narrative style, and context – the reason the artifact exists in the first place. Enterprise search results defy definitive or conclusive answers. They’re conversational – not just among peers but with the search interface itself which guides the searcher with:

1. Related events, 
2. People, 
3. Locations, and 
4. Organizations that suggest …
5. Further probing, 
6. Competing explanations, or even …
7. Complete redirections of our original assumptions.

This relatedness was realized in the proof of concept. Human-mediated tagging was neither doable nor desirable but the prospective search technologies proved up to the task for grouping these relations as search facets.

#3 – Search versus Source Dependent: The key to building our knowledge safety net is not so much keyword searching as enterprise sourcing: The ability not just to crawl volumes of pages, folders, and files but to evidence why anyone bothered to do so. Search scoping is essential because it brings the sense-making role of any single artifact apparent to colleagues with otherwise no shared experience beyond a common holiday calendar and pay cycle. Sourcing logic reinforces the cohesive logic of coordination across business lines and supporting functions:

1. Want to know what the customer sees before it’s out on your website? Search on marketing. 
2. Want to understand our products better? Search on training. 
3. Visual learner? Precede to training videos, etc. 
4. The more technical explanation? Go to the core requirements hammered out by account managers and the engineers who design to them.

Everyone at Keen Core understood the different lenses for sifting through the same content. The challenge was that only engineering had a seat at the bake-off table.

Enterprise Assets or Liabilities?

The good news is that each of these ingredients was factored into an enterprise search proof of concept for the engineering crew at Keen Core. The correct sources were indexed and configured to a search-driven interface reflecting both the nature of the index and the information-seeking goals of the searcher. Better still I got to run a true side-by-side comparison between two enterprise search vendors (Coveo and Google). The thinking here: My colleagues could base their tool of choice on their actual problem-solving.

The bad news is that Keen Core’s enterprise resembled a potluck more than a catered sit-down. The number of place settings changed with who wanted a seat at the table. The unsettled seating arrangements made it hard to move forward without revisiting some tired assumptions like:

• The Google Slam Dunk: Hey, wipe that Google web smirk off your enterprise requirements for Google Search Appliance. We’re talking two different engines here!
• The How Big-is-Our-Data Routine? What constitutes a fair test sample when a vendor solution crawls across diverse operating systems, repositories, and legacy apps (with licenses no one bothered to renew)?  
  
• The How-Open-is-Open Question? What's bothering your colleagues about access to resources? What's the important stuff we can get access to if we need it?  What are the content bottlenecks that hinder a silo-bound organization?

Conclusion: At every milestone selecting the right vendor was resistant to simple risk-to-benefit reductions. Multiple trade-offs were the norm. So were the dug-in heels of competing vendor camps. All of these larger lessons were lost to the conflicting agendas of poker-faced stakeholders – regardless of the actual bake-off winner.

Next week: The bake-off verdict is clouded by a crash diet spending plan courtesy of a stock delisting and a CEO whose blunt leadership style distances him from all non-depreciable costs -- including the company’s ingrained know-how on the building of its products.

***

The blog series KM in the Jerkplace is a work of fiction. Names, characters, businesses, places, events and incidents are either the products of the author’s imagination or used in a fictitious manner. Any resemblance to actual persons, living or dead, or actual events is purely coincidental.