Knowledge working open source style
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: