Jun 22, 2012
Within all of us there are two minds: the professional and the employee. Actually, there are probably many more but I am just going to talk about those two. On the one side, the professional is focused on his/her craft and building skills. Professionals are passionate about their discipline and look for ways to be creative and innovative. The professional seeks challenge and isn't afraid of failure. The employee side, however, is focused on his/her job as it has been defined: meeting expectations, following the rules, and other forms of job preservation/advancement. The employee side seeks comfort and safety. The employee avoids risk through routine. Innovation is limited to small optimizations of the status quo.
Both sides are important. You get dependability from the employee. You get excellence from the professional. Depending on the field, one aspect may dominate another. For example, in an unskilled field, the employee dominates the professional. The job is easy to learn, there is no career to build, and you are easily replaced. You show up on time, you do as you are told, and you go home. The best you can do is show yourself to be dependable and hope for a promotion to lead others in the tasks that you have learned. In a high skill job, like a doctor, the employee part is minimal. You see a lot of passion about the craft and much less interest in the details of employment. Doctors can easily shift from one practice to another but the focus is the same - solving challenging problems, contributing to the field of medicine, and delivering excellent patient care.
Why am I even talking about this esoteric decomposition of the human psyche? Because it has profound implications on knowledge management and Intranets. The thing is that advanced skill and knowledge are wrapped up in the professional side of the person and that side wants to interact with his/her field (inside and outside the company). It is far more rewarding to share brilliant insight on a large professional network than to a small group of co-workers. The few co-workers that are as passionate as the professional are probably already on that external professional network too.
This is why the knowledge management aspect of intranets (like blogging and micro-blogging and most wikis) tend to fail so often. The dream of using an Intranet as a catalyst to synthesize all of the great ideas trapped in the brains of an organization never is achieved. The professional's brilliance is drawn to a larger stage. The most successful bits of Intranet are the ones that serve the employee: the company directory, forms, and templates. Templates are the things that are most often passed off as knowledge but I would contend that they are more focused on routine and consistency than thinking and knowledge.
This is why I have such low expectations for the "Social Enterprise" solving knowledge management through tools like Yammer that emulate what is happening on the public web. The single reason for Twitter's success is its openness. With an open network like Twitter (or Google+), I can connect with a stranger on the other side of the world through the simple bond of being interested in the same thing. We can learn from each other and build off each others' ideas. Our motivation is our interest — the professionals within each of us. If you narrow down that pool to just the people you work with (a great percentage of whom are involved in totally different professions), the shared interests get fewer and much more mundane: holiday schedules, cafeteria menus, etc. This makes the value of content shared hardly worth the cost and effort of implementing these tools.
If the Social Enterprise is to work, I predict it will be on open networks that can also support private group channels. Personally, the network that I think comes the closest is Google+. Perhaps LinkedIn. I guess Facebook has the functionality but Facebook has become a place for the hyper-personal and that clashes too much with our professional contexts. I would love to hear about companies that are using public networks to connect employees. Perhaps this would be putting your social network links in your corporate directory profile or creating circles and lists for co-workers. Anyone doing anything cool? I ask this question to the professional in you.
Jan 18, 2011
I have a complicated relationship with personal information management (PIM) tools. I love PIM software and services that promise to remember everything that I once knew. I am tempted by every new information gadget that comes down the pike. But I have also been burned lots of times too. I spent hours on corporate intranets documenting my knowledge only to have them shut down. I used proprietary software like the The Brain which became inaccessible when I switched computing platforms (note: now The Brain supports Linux and Mac OSX as well as Windows). My Google notebooks are now barely supported by Google. And now we have news of Delicious's uncertain future.
Because of these experiences, I have been fighting my urges to use services like Evernote, SpringPad, Yojimbo, etc.. Instead, I have been sticking with humble text files. In an earlier post, I described how I am using TextMate as a blogging tool. I have started to use it as a knowledge management tool as well.
I don't pretend that I have the features that products like Evernote do, but here is what I can do:
-
Create notebooks with multiple pages by using TextMate's project feature.
-
Organize pages into folders.
-
Create todo items and other tags that I can summarize by using the ToDo bundle
-
Search using "Find in Project" or Spotlight.
-
Collaborate with others using GitHub or another code hosting service.
-
Store and organize binary files like diagrams created in OmniGraffle.
The truth for me is that the greatest benefit of any PIM tool is simply the act of recording and organizing the information. These activities help me remember and process information into actionable knowledge in my head. You can do that with any tool. The second most important aspect is search and recall. This is where the open format of text files really excels. It would be really frustrating to try to retrieve some information but not have access to the software to consume it.
Apr 02, 2010
While reading Andy Hunt's excellent book Pragmatic Thinking & Learning: Refactor Your Wetware
I couldn't help but return to a conclusion that I reached long ago: "knowledge management," as an enterprise practice and class of software, is a false promise. Furthermore, traditional corporate training programs are doomed to failure.
I was first struck by this realization around ten years ago when I was working on a project for a department of the federal government. The premise of the project was to "capture the knowledge" from a generation of experienced staff that were on the cusp of retirement. This department was structured so that knowledge was concentrated in minority of senior employees. Underneath them there was a thin layer of mid-level staff; then a large group of juniors. The strategy was to video pre-retirees reminiscing about their experiences and the department could somehow do something with that "knowledge." The idea was dead on arrival and the prime contractor (that originally pitched it) knew it. I remember suggesting an alternative strategy of setting up an apprentice program where people could learn by doing rather than watching TV; but I was laughed out of the room. They had no interest in "capturing knowledge." Their primary business was hiring retirees and staffing them as consultants at the department. Failure was more profitable than success.
Ever since that experience, I have been keenly interested in the process of learning. As a technologist and a consultant, I am always learning so I have developed tactics that work for me. What surprised me in reading Pragmatic Thinking & Learning is that there is actual scientific theory that supports many of the tactics that I employ. What I like most about the book is that it talks about thinking and learning as a personal process that you have to do yourself. The most a teacher or a computer can do for you is provide information — data. To turn that information into knowledge, you have to internalize it into something that is meaningful to you. You need to put the information into context with other things you know.
Most corporate professional development programs ignore this truth about learning. They practice what the book calls "sheep-dip" training programs where training classes "dip" employees in information that quickly wears off. The only way that you learn from these classes is to apply what you heard right away. The learning happens after the class. This is why I like the idea of "drop-in labs" so much. I think the industry is starting to accept this "learn by doing" philosophy. Knowledge management experts are talking less about repositories and more about communities and workspaces. Emphasis seems to be shifting from the assets to the learning process.
On a personal level, being more conscious of these ideas is helping me be more deliberate about how I learn. The book advises setting SMART (specific, measurable, achievable, and relevant) objectives and using techniques like SQ3R (Survey, Question, Read, Recite (summarize), Review). But most importantly, learning has to be fun because we learn best through play. Yet another reason to work in a field that you love.
Pragmatic Thinking & Learning lives up to the high standards set by the The Pragmatic Programmer: From Journeyman to Master
and other books on the Pragmatic Bookshelf. It will be required reading for anyone that I hire.
Aug 19, 2008
My career spans across the domains of a software developer and a knowledge worker. I participate in software development projects and I also do the things that your typical knowledge worker does: communicate information through reports, presentations, and other knowledge assets. One thing I have noticed from this perspective is that software development has been improving from the adoption of open source tools, behaviors, and practices while most knowledge workers live in the comparative stone ages of siloed working habits. As someone who loves living out in the country and working with people from around the world (and is also trying to reduce his carbon footprint), I look forward to the day when knowledge workers start to harness the techniques that distributed open source development teams have used to effectively produce quality software. Here are some places to start.
-
__Using Mailing Lists and IRC.__Mailing lists (and sometimes IRC) are the core channel of communication within open source development teams. Point to point emails (and, shudder, phone calls) are discouraged because they lead to duplicate communication and there is no centralized record of what was said. IRC is preferable to point to point instant messaging for the same reason. Frequently once there is a critical mass of substance on a topic, a wiki page (mentioned later) will be used to capture and organize the idea as it develops.Especially in the world of IRC, it is important to include some social value (i.e. fun) in the dialog. Otherwise, the people who have all the answers have little benefit in participating. I have worked on projects where everyone worked within arms reach of each other, listened to music on their headphones but constantly communicated over chat. I liked this way of working because if you had a complex thought in your head that would unravel if you were interrupted, you could ignore the conversation and catch up when you got to a good stopping place. I realized the secondary benefit much later: when the team was broken up and staffed on other projects, the conversation kept on going even though people were spread all over the world.
-
__Using Wikis.__Most open source projects use wikis for documentation. Wikis have a number of advantages over Office/Sharepoint: they stress information over formatting; they have excellent history and version comparison; they encourage referencing information (through links) over duplication (copy/paste); there is no local copy to synchronize; and they don't require special client-side tools to contribute. Every time I open a word processor, I challenge myself whether this needs to be a "document." My general rule of thumb is that I only do it for proposals, deliverables, and contracts where the audience needs their own local copy.
-
__Managing Vision and Tasks.__Even though I have worked on several software projects that wound up going nowhere, I have to say that an even higher percentage of knowledge work is wasted. You could argue that the act of knowledge work leads to learning which creates knowledge. But running around in circles without any results is demoralizing. I like developing software systems because you see tangible results. I wish knowledge work was more results oriented. The better managed software projects maintain a road map which communicates an overall vision of what is going be achieved broken down into milestones. Gantt charts just don't capture the "why" like a road map does. I think knowledge work could benefit from the same understanding. People should be responsible for mapping their individual activities to a shared set of goals and priorities.Open source projects rely heavily on issue tracking systems to manage work. Bugs and enhancement ideas all go into the issue tracking system where they are prioritized and assigned. If you have an idea for a new feature, you create an issue, assign it to yourself and start working. Maybe someone else shares your interest and starts to collaborate with you. In distributed teams, where you can't see people working, you need other ways to keep track of what people are doing - not just if you are given the role of "project manager." An issue tracking system would be a good way to achieve this.
-
__Holding Sprints.__Open source projects have long understood that effective collaboration depends on communication and trust, which are most efficiently achieved through face to face interaction. For this reason, many open source projects hold sprints (also known as hackathons) where people work closely together (as in 2 to a computer) and mix hard work with an equal balance of socializing and play. In a typical office setting, people need to rush home at quitting time to attend to their home life. If they normally work from home and travel to a sprint, they are more likely to hang out after work and get to know their colleagues.I think the sprint technique could have huge potential in knowledge work. It would get people together to share information and it would create networks for people to use in solving future problems. One big thing about software sprints is that they are centered around solving a specific problem or accomplishing a goal. I think that knowledge workers would really respond well to this sense of purpose.
-
Componentizing.Good developers know how to break down their software into re-usable components and reuse them. Most knowledge workers live by copy/paste (or Save As). Copy/paste not only creates redundancy that is hard to manage, it also frequently inserts unwanted content into your document. If you want to re-use something as it is, try to reference it. Granted, software has the advantage of build processes that assemble the appropriate parts to produce a cohesive product. Technical documentation (in XML) is often built like software. Most other stuff (particularly anything written in an Office (Microsoft or Open) is not.A while back I produced a coding standards document for my company. I based it on the Sun Microsystems' Java Coding Standards. Rather than copy the whole thing and then edit the parts I wanted to change, I referenced the original and created a small addendum document that discussed where we were deviating from Sun's standards. While this does not create a polished deliverable, it conveyed the necessary information which is what I was trying to do in the first place.
-
__Designating a Committer.__In large open source projects, lots of developers submit their code to a small team of committers who review everything before committing it to the source code repository. Knowledge workers are constantly creating assets and dumping them into places where they are often never read. Sometimes these assets are never reviewed but are randomly discovered. Then it is up to the reader to determine if the information is valid. Because of this, most companies are swimming in information of wide ranging quality and accuracy. Search technology vendors claim the answer is in sophisticated retrieval systems. I would argue that more attention to the review and categorization of information at the intake end is needed. The committer for knowledge work would be a subject matter expert with librarian skills. This committer would know about what has already been done, be able to judge quality, and see opportunities to create shared resources. In open source projects, the committer is a position of status earned by climbing up through a meritocracy. The analogous knowledge worker position in most companies is really low on the totem pole. Peo
ple who move up the latter in the knowledge world tend to drift away from the content and their distance leads to neglect.
I don't think these practices should be that difficult to adopt but they are rare outside of software development. The obstacles are probably mostly based on culture. Old habits are difficult to break. I think another issue is that knowledge assets are commonly thought of as a by-product of the work rather than the purpose of the work (like software is). Therefore, there is less urgency in addressing the quality of the assets. But if institutional knowledge is a priority of the organization, the assets themselves need greater attention and investment.
Further reading:
Dec 29, 2006
We just posted Episode 4 of the Malcontents podcast. In this issue, Bryant and I talked about the Fall CM Professionals Summit and the Boston 2006 Gilbane Conference. Topics included Localization and Blogs and Wikis in a Knowledge Management context.