Everything is connected ... really ... Putting meaning to work
Everything might be fragmented and miscellaneous, but work is connected, by reality itself.
Committing vast resources to the “fragmented and miscellaneous” aspect of our Internet-driven economy is a deer-in-the-headlights reaction to the superabundance of information. That reaction might be unavoidable, but it is also unfortunate, because information—and, in particular, unstructured content—is a surface characteristic of knowledge-based activities, not their essence. Focusing exclusively on new ways to handle or respond to the superabundance of information distracts us, ironically, from solving the most important problems of the Information Age.
It’s easy to succumb to the frenzy of gathering, creating and sharing information. Ditto for building better search engines and “social tagging.” Those activities sound perfectly rational, and sometimes you can point to cases in which doing them better leads to improved performance. Did you find an answer that you might not have found otherwise because you used a more advanced search engine? Were you more likely to find the right person for the job because skill search technology located the right set of experts for the project? Did it become easier to maintain and reuse the information in your manuals because you coded that content with the Darwin Information Typing Architecture?
What really counts
It’s not that we should—or even can—shift our attention completely away from information (and unstructured information, in particular). It’s that we have failed to address meaning in the context of work. Yet, that is what we need to do in order to transform our economic activities, both as individuals and as groups working toward common goals.
In one of the great ironies of creation of value by humans, we looked at the byproduct of knowledge work—that is, information—and saw in it both the problem and the solution for the central socio-economic problems of our times. We stopped looking at what we do, how we do it and how we create value. Our reaction to knowledge work has been analogous to focusing on the shavings on the machine shop floor instead of on how we create products with those machines.
You cannot—and do not—act on words. You act on meaning. You always have to convert words into meaning before you act. It’s the meaning behind information that counts. And sometimes you don’t need words at all.
Meaning? Yes, “the thing one intends to convey especially by language,” according to the Merriam Webster dictionary. Not the language itself, not the text strings and symbols that fill our books and screens, but the significant stuff that language intends to represent so that we can communicate what we understand. The connections among things. Causes and effects. In the context of work: the relevance or importance of those connections. The subject of logic, argument and epistemology. A pervasive, essential aspect of rational human activities that is accepted as critical to creation of value and economic progress, and yet an idea routinely dismissed as unusable, elusive and unmanageable at the same time. And the missing ingredient in our understanding of work and the creation of value in the age of information.
The knowledge worker
According to Wikipedia, the term “knowledge worker” was coined by Peter Drucker in 1959. It describes a person who “works primarily with information or one who develops and uses knowledge in the workplace.”
When knowledge management gained mindshare in the 1990s, consultants and commentators rushed to adopt the term, giving it broad acceptance as a description of trends in work in developed countries. Economists, business managers and consultants all asserted that competitiveness and innovation depended heavily on this new class of knowledge workers ... and far less on the productivity of laborers.
Since then, thousands of books, articles, Web sites, blogs and corporate white papers have been devoted to knowledge work and knowledge management—some from the perspective of technologies applied in such work, and others with greater emphasis on cultural change in the organization and increased frequency of collaboration.
Going back about 12 years, we find David Collins claiming in the Journal of Systemic Knowledge Management: “Over the last few years considerable attention has been shown in the analysis of ‘knowledge work’ and in the analysis of knowledge-intensive forms of organization ... By far the majority of those who use the term seem to agree, broadly, that there is a form of work that we might meaningfully categorize as knowledge work.”
Nevertheless, it appears that there is no unambiguous, universally accepted definition of the term knowledge work. Programmers, marketing personnel, Web designers, business planners, economists, any job with the word “analyst” in its title and hundreds of other job categories fit a commonsense understanding of the term.
Labels vs. understanding
Most managers are clearly knowledge workers. If you produce information products of various kinds—documents, analyses, art—you’re almost certainly a knowledge worker. If you apply software in your work, you get the label with little argument. If you use the Internet in your work for more than a couple minutes per workday, it’s highly likely that you’re a knowledge worker. And you certainly qualify if you use your experience and education in healthcare, finance, human resources and hundreds of other domains to get things done.
However, defining knowledge work as “working with information”—and, more recently, directing most of our attention to solving the problem of superabundance of information—simply doesn’t take us to a deeper understanding of how we can make knowledge work better.
The stunning reality is that we, as knowledge workers, often spend more than half our time doing work that has no formal description, no standards for best practices and no appropriate metrics. What’s more, that work is not formally or explicitly connected to specific outcomes, whether they are services or products.
Given the well-known impact of F.W. Taylor on industrial work and the open-ended opportunity for improving knowledge work, it is surprising that no one has attempted to analyze knowledge work as systematically as Taylor did, especially as expressed in the first and most important of his four principles of scientific management: Replace rule-of-thumb work methods with methods based on a scientific study of the tasks.
What we don’t know
One reason for that deep resistance to a Taylor-like approach to analysis of knowledge work is the assumption that the result would be dehumanizing assembly lines and rote work activities for knowledge workers. That claim is repeated frequently, but without any foundation. Until we develop and apply something analogous to Taylor’s “scientific management” to knowledge work, we simply do not know whether the outcome of applying such an approach would make that work more or less tedious or dehumanizing. By some logic, it should actually improve working conditions. Consider, for example, the opportunity to (1) reduce the ambiguity of tasks and (2) give workers more objective criteria for productivity and performance evaluation. That might result in better working conditions in general and substantially reduced stress in particular. But we don’t know that yet.
Looking more closely at knowledge work
If you view the world through the lens of information, it’s fair to say that “everything is miscellaneous” or “everything is fragmented.” But those are statements of the problem, not solutions. They are insights that present opportunities, but they are not the first or only challenges to which we need to devote our energy. Instead, we need to turn our attention to how people deal with realities, how they perform meaningful activities in the real world. And in that real world, everything is connected—by reality itself, by what exists, by what people do, by the relationships among all things.
We can list a few knowledge work activities that are common in most organizations, including:
- finding and processing information relevant to our objectives and converting that information into purpose-driven communications of various sorts, from e-mail to substantial documents;
- designing information processing applications to make information more useful to people and to other software applications (relational database applications are a good example);
- group knowledge work activities, including discussing the value of the ideas in information; and
- planning and managing the activities of knowledge workers.
There are countless others but, as noted above, we have no formal description, no standards for best practices and no appropriate metrics for such activities. And those high-level descriptions of familiar knowledge work activities mask the core role of meaning in knowledge work.
Putting aside for the moment the cultural and emotional aspects of knowledge work, what are the primary characteristics of such meaning-based work?
- interpreting information;
- converting information into more meaningful and useful forms;
- making judgments on the meaning, relevance and importance of the resulting abstracted information;
- integrating those abstracted objects and connections with prior knowledge; and
- associating those objects with real-world events, products or other realities of importance to the individual and/or the organization.
We already spend much of our time doing precisely those things, but we frame them not as meaning-based activities but as actions performed on information—usually with a variety of established information processing tools. (To illustrate the point, I created the chart on page 24, March KMWorld 2010, which is a simple way of underscoring that the development, transfer and integration of meaning are pervasive activities in businesses.)
Such activities are at the core of what most knowledge-based companies do. They are precisely how we create value. But we are doing those things very poorly because we have focused on the information aspects of the activities, not on what people actually do. To make matters worse, doing those things even marginally well—and in a consistent way that makes sense to us—is still time-consuming, frustrating and exhausting. And we perform those activities largely in isolation and without standards or best practices.
Feedback and metrics
We made a mistake by focusing too much on information, but we also bought into the misleading idea that knowledge work is completely different from physical work.
- We don’t account for feedback as an essential characteristic of work activities. If you strike a nail poorly or move clumsily and scratch a product on the assembly line, you can see or feel the effects. But there are few knowledge processes that give you feedback on the quality and impact of your activities. Most metrics for knowledge work look at bottom-line changes over long intervals. The chain of cause and effect is simply not clear.
- We fail to make explicit, measurable connections between individual knowledge work and group knowledge work activities. Most of the activities of individuals listed above would be more efficient and produce better outputs if they were (1) integrated with related activities performed by other individuals and (2) supported by common resources. Such a transformation is only possible and reasonable if those processes are analyzed carefully and deconstructed into well-defined component tasks. That’s exactly what happened in manufacturing.
That’s so wrong! In spite of the superabundance of information, it’s still all about how we work, what we do and how we work together.
Technologies and practices of meaning
With or without a formal Taylor-like process for analyzing knowledge work—even without acceptance among managers and theorists that meaning is the infrastructure of all work—practices and technologies that address and leverage meaning are insinuating themselves into knowledge-based activities. That’s a good thing. The adoption of meaning-based (or “semantic”) approaches and technologies is inevitable, but it is also painfully slow, and we are losing the opportunity to make dramatic short-term improvements in productivity and competitiveness because we are still so obsessed with information.
Many forms of information technology are, indeed, devoted to conversion of information into meaning or deal directly with meaning. Consider the semantic aspects of the following applications:
- Relational databases are meaning-based. A relational schema deconstructs real-world relationships into tables and relationships among tables.
- Project management techniques and tools associate the availability of specific skills with specific actions and specify the order in which such actions must take place.
- Personal information management software helps individuals organize their personal information resources and connect those resources to their activities.
- Social network analysis (SNA), insofar as it includes connections between ideas and people, traces the flow of meaning through organizations and unstructured groups.
But those applications are not framed as tools for capturing, managing and leveraging meaning. More recent practices and technologies do make that connection, but they do so as stove-piped applications, not as part of an overall semantic infrastructure for knowledge work.
Best-known brand of semantic technology
Today, the most visible meaning-based technology is the Semantic Web. There is no shortage of explanations of the Semantic Web. I can recommend Jeffrey Pollock’s Semantic Web for Dummies, but you are well served by first reading James Hendler’s post, “What is the Semantic Web really all about?” (http://network.nature.com/people/jhendler/blog/2009/06/16/what-is-the-Semantic-web-really-all-about).
Hendler, an expert and innovator in computer ontologies, was co-author of the Scientific American article that was primarily responsible for bringing Tim Berners-Lee’s new vision to a much broader audience, so he brings much more authority to his observations than, well, just about everyone else except Tim B-L himself. Hendler defines the foundations of the Semantic Web: “The Semantic Web is based on the relatively straightforward idea that to be able to integrate (link) data on the Web, we must have some mechanism for knowing what relationships hold among the data, and how that relates to some real-world context.”
At its heart, the Semantic Web is a standardized model for distributed creation and referencing of “linked data”—assertions about concepts and their relationships. Concepts are uniquely identified by uniform resource identifiers (URIs). Berners-Lee envisioned this vast web of Semantic metadata making documents more accessible to search engines, but the model can be used—is being used—for a variety of requirements, including development of standard vocabularies within domains and enterprises.
Hundreds of commercial tools—thousands if you include open source and academic products—have sprung up in this simple but fertile ground. Try Michael Bergman’s “Sweet Tools” resource at: http://www.mkbergman.com/new-version-sweet-tools-sem-web, which contains over 800 tools at this writing. You can also find any number of forums on the topic online, and you can get up close and personal with the SemWeb experts at Semantic Web Gatherings across the country (see meetup.com).
If interest in the Semantic Web is strong in the United States, it might be even stronger in Europe, where projects spanning countries and private/public boundaries are well funded.
You can find my own brief take on the Semantic Web at: semanticadvantage.com/pdfs/Sarkozy%20bites%20obama%20child.pdf.
We will have to continue to live in a world of fragments and miscellany, but a meaning-based approach provides the connections that enable substantive, measurable and persistent improvements to knowledge work.
The terminology of semantic applicationsYou can use words to describe corporate policies, disaster recovery procedures, the functions that a person or application performs and similar aspects of the realities of the enterprise. But you end up with ... just words. You aren’t one step closer to turning that information into value. You can’t find or manage that information predictably. You can’t build more complex and useful tools from words themselves. You cannot use that information to detect duplication of effort or anomalous activities.
To understand semantic applications like semantic networks or metadata systems based on Semantic Web principles, you have to start by adopting a very simple notion—that you must deal with concepts rather than words. A concept is a discrete thing (tangible or abstract), often correlated with a single meaning of a word or phrase. (Conversely, several different words or phrases might describe that same concept.)
It’s easier to put that distinction to work if you think of a concept as something that exists across the boundaries of natural languages. Unfortunately, that’s not absolutely true, because language influences our understanding of concepts. Most of us understand that even the names of physical things might have different connotations in other languages.
In semantic networks and other knowledge representation (KR) formalisms, a concept—often presented as a node in a graphic network of symbols (like circles) and arrows—may be described by several different words or phrases. The label is necessary, but the meaning of the concept is embodied in its relationships to other concepts. In most KR formalisms, relationships are labeled to indicate the meaning of the relationship. Relationships are also referred to as links, arcs or edges. (Unlabeled relationships among nodes are more characteristic of “mind mapping.”)
In the Semantic Web, whose foundational model is the Resource Description Framework (RDF) triple, relationships are often referred to as predicates. But Chris Menzel (now of Texas A&M University) noted in a posting to the Ontology forum that “ ... there are no predicates per se in RDF, there are only names [more specifically, uniform resource identifiers (URIs) and literals] that denote resources. Predicate itself just indicates a role that a name can play in an RDF triple—it is the name that ‘connects’ the other two names in the triple.”
In any case, such a relationship is an assertion that concept A is connected to concept B in a specific way. Central to any understanding of the Semantic Web and computer ontologies in general is that formalized relationships among concepts typically support inferencing by software applications—for example, that anything asserted as a characteristic of primates is by inference also characteristic of all humans, a subtype (or subclass) of primates. Human implies primate, but not the other way around. (Thanks, Samir Batla of EMC, for the example.)
I also propose that we make an explicit distinction between concepts and ideas. I define an idea as an expressed observation about reality, the equivalent to a simple sentence in natural language. You might think of ideas as concepts connected by syntax—but in a way that is more rigorous than in natural language. That distinction is very useful because in argumentation/discussion support systems (as well as in most mind-mapping applications), the nodes are usually ideas, not concepts. Labeled relationships between those ideas often reflect influence, causality, constraint (conditions) or opinion.