klogger roles, adoption, rules of the road
From: Bill Kearney Re: K-Logs and continuous education
people are *never* going to use k-logs in 99% of the current corporate
environments. Yep, that's NEVER. Why? Trail of evidence, that's why.
Traditionally, supervisors and managers play an information filter role,
K-logs only amplify the importance of this role. Assuming everyone klogs
(and we can have a good thread or two on adoption rates and on
prerequisites to adoption and sustained use), the volume and disorder of
information increases. Unlike databased, well-structured data, the
narrative form of klogs requires human editorial skill to summarize,
prioritize, and refer-in-context.
For those into technography (http://www.coworking.com), the role of
meeting scribe (typically an editorially neutral role) may demonstrate
some key leadership skills; klogging literacy, ability and will to
listen well, and mediation/moderation skills. (Do you think we can
explore klogs as technographic tools since so much time is spent in
Tools don't solve peopleware problems. The distrust, innumeracy,
obfuscation and incompetence in your scenario are neither universal nor
mandatory. These are deep issues best addressed directly, forcefully,
and with skill. I can't imagine klogging under these conditions.
So what conditions are needed for klogging to succeed? What should be in
an HR manager's guide to klogging? In a line-manager's guide? In a CIO's
guide? What are the rules of the road for a klogger at your company?
Imagine this, an underling in the company posts an item to the k-log
that's "ahead" of his boss's schedule. The other readers of the k-
log see the underling's approach and LIKE it. This, unfortunately,
undermine's the boss's perception of timeline and control. Guess who
get's fired? Not the boss. Yes, the boss is stupid in this
Now, take it to the other extreme. The underling posts an item to
the k-log. The boss sees this but notes, from the meta-data, that it
was posted "after" the time it was due. In fact, it's posted when
the boss perceives the underling should have been doing other work.
Again, the underling hits the street...
This was proved to me when I developed a prototype of a handheld
application for sales. To summarize the management saw the meta-data
collected during the sales events as a way to literally measure an
average time to sale number. Thusly, they expected to be able to
reverse that number back against the sales force as a means to weed
out the sales people that weren't selling "fast enough"
I was, of course, horrified. I tried to explain to them a concept I
call "quantum data". There's some data (meta) that if you LOOK at it
you will alter it. They didn't grok the concept. The project tanked
and, eventually, so did the company.
The employees are surrounded by situations that demonstrate to them
that management is going to wield information as a weapon. They're
not going to help load the gun.
Yes, this is stupid. But overcoming this is a less-than-trivial