On the other hand, new terms and language can help us point to and see new ideas and new opportunities for action. Here’s a recent post from Bob Sutton that sheds light on these challenges and is worth thinking about.

One of my best friends in graduate school was a former physics major named Larry Ford.  When behavioral scientists started pushing for precise definitions of concepts like effectiveness and leadership, he would sometimes confuse them (even though Larry is a very precise thinker) by arguing “there is a negative relationship between precision and accuracy.”   I just ran into a quote from the amazing Nobel winner Richard Feynman that makes a similar point in a lovely way:

We can’t define anything precisely. If we attempt to, we get into that paralysis of thought that comes to philosophers… one saying to the other: “you don’t know what you are talking about!”. The second one says: “what do you mean by talking? What do you mean by you? What do you mean by know?

Feynman’s quote reminded me of the opening pages of the 1958 classic “Organizations” by James March (quite possibly the most prestigious living organizational theorist, and certainly, one of the most charming academics on the planet) and Herbert Simon (another Nobel winner).  They open the book with a great quote that sometimes drives doctoral students and other scholars just crazy.  They kick-off by saying:

“This is a book about a theory of formal organizations.  It is easier, and probably more useful, to give examples of formal organizations than to define them.”

After listing a bunch of examples of organizations including the Red Cross and New York State Highway Department, they note in words that would have pleased Feynman:

“But for the present purposes we need not trouble ourselves with the precise boundaries to be drawn around an organization or the exact distinction between an “organization” and a “non-organization.”  We are dealing with empirical phenomena, and the world has an uncomfortable way of not permitting itself to be fitted into clean classifications.”

I must report, however, that for the second edition of the book, published over 20 years later, the authors elected to insert a short definition in the introduction:

“Organizations are systems of coordinated action among individuals and groups whose preferences, information, interests, or knowledge differ.”

When I read this,  I find myself doing what Feynman complained about.  I think of things they left out: What about norms? What about emotions?  I think of situations where it might not apply: Doesn’t a business owned and operated by one person count as an organization?  I think of the possible overemphasis on differences: What about all the times and ways that people and groups  in organizations have similar preferences, information, interests, and knowledge? Isn’t that part of what an organization is as well?  I could go on and on.

I actually think it is a pretty good definition, but my bias is still that I like original approach, as they did such a nice job of arguing, essentially, that if they tried to get more precise, they would sacrifice accuracy. Nonetheless, I confess that I still love trying to define things and believe that trying to do so can help clarifying your thinking.  You could argue that while the outcome, in the end, will always be flawed and imprecise, the process is usually helpful and there are many times when it is useful pretend that you have a precise and accurate definition even if you don’t (such as when you are developing metrics). ”

Richard Feynman On The Folly Of Crafting Precise Definitions – Bob Sutton:

Ten ways to create a knowledge ecology

TUESDAY, JUNE 28, 2011 AT 7:08AM

A tweet yesterday prompted me to remember sage advice from Dave Snowden which I took to heart in my work with social tools at the BBC. “You can’t manage knowledge but you can create a knowledge ecology”. I thought it might be useful to others to list the ten most important things I learned about doing this.

1, Have a variety of tools rather than a single system. Not everyone sees the world the same way or has the same needs so mixing up different tools with different strengths allows people to find one that works for them. Avoid single platforms like the plague.

2. Don’t have a clear idea where you are headed. The more fixed you are in your aspirations for your ecology the less likely you are to achieve them. Be prepared to go where people’s use of the tools takes you and enjoy the ride.

3. Follow the energy. Watch where the energy in the system is and try to copy the factors that generated it. Get others interested in why energy emerges and they will want some of it themselves.

4. Be strategically tactical. You can have an overall strategy of behaving in certain ways depending on how your ecology develops. It is possible to sell this as a strategy to those who need strategies.

5. Keep moving, stay in touch, and head for the high ground. Keep doing things, keep talking about what you are doing and why, and have a rough idea of where the high ground is.

6. Build networks of people who care. Don’t try to manage your ecology by committee but cultivate communication and trust between those who care that it works and have the commitment to do something about it – whoever they are and whatever their role.

7. Be obsessively interested. Notice everything that happens and consider why. Tell great stories about what you are observing.

8. Use the tools to manage the tools. Blog about what is going on with your corporate blogging, ask questions in your forum about security, tweet when something is changing in your ecology and ask people why it is interesting.

9. Laugh when things go wrong. If you are pushing limits and exploring new territory things will occasionally blow up in your face. Having a sense of humour and enjoyment of the absurd will help you stay sane.

10. Unleash Trojan Mice. Don’t do big things or spend loads of money. Set small, nimble things running and see where they head.

(- The Obvious? – Ten ways to create a knowledge ecology)

The paradox of organic approaches to change is that while they appear to be simple and mundane, they also appear to be the only thing that works with any regularity in complex situations. For all the rhetoric of bold plans and audacious goals, the reality is that most change occurs inch-by-inch.

- Posted using BlogPress from my iPad

That, of course, is an immense issue and would could barely scratch the surface in the hour we had. For those who are interested, we’ve uploaded our slides to Slideshare.

We used two recent TV ads from GE and IBM to kick off the discussion. On the surface, each provides a sense for the promise of information technology to make health care more effective:

In the tradition of all good technology vendor advertising, both also completely gloss over the complex organizational adaptation and evolution necessary to bring these hypothetical worlds into being. They also gloss over the existing institutional and industry complexity that needs to be understood and addressed through a combination of design, leadership, and management.

Fred  Brooks, professor of computer science at UNC and author of The Mythical Man-Month : Essays on Software Engineering, draws a critical distinction in the final chapter of the book, which is titled "No Silver Bullet," between accidental and essential complexity. His point is that software is so difficult to design and develop because it must successfully model the essential complexity of the domain it addresses. Technology and software efforts can stumble on a variety of barriers and roadblocks, but failing to understand and address essential complexity is the worst.

Health care provides its own mix of accidental and essential complexity. If the decision makers aren’t careful to draw distinctions between accidental and essential, then a great deal of time and effort will be expended without corresponding returns. On the one hand, we may simply succeed in "speeding up the mess" as my friend Benn Konsynski so liked to put it. Or, we may obliterate  essential complexities in a quest for uniformity and productivity that is blind to those complexities. Or, finally, we may invest the appropriate level of design time and talent in systems that account for essential complexity and eliminate accidental complexity.

Resources

We drew on a variety of excellent resources in preparing for this talk and wanted to make them more easily available here.

Here are several books that provide useful context and background

• From Novice to Expert: Excellence and Power in Clinical Nursing Practice, Commemorative Edition, Benner, Patricia
• The Innovator’s Prescription: A Disruptive Solution for Health Care, Christensen, Clayton M.
• Better: A Surgeon’s Notes on Performance, Gawande, Atul (my review – Better thinking about performance improvement)
• The Checklist Manifesto: How to Get Things Right, Gawande, Atul (my review – Checklists for more systematic knowledge work)
• The Strategic Application of Information Technology in Health Care Organizations, Glaser, John P.
• Who Killed Health Care?: America’s $2 Trillion Medical Problem – and the Consumer-Driven Cure, Herzlinger, Regina
• The End of Medicine: How Silicon Valley (and Naked Mice) Will Reboot Your Doctor, Kessler, Andy (my review -Business models for health care: Andy Kessler’s take on the future of medicine)
• Normal Accidents, Perrow, Charles

Here are pointers to a variety of health care related web resources worth paying attention to:

• HIMSS – Health care Information and management systems society
• CHIME – College of Healthcare Information Management Executives
• The Advisory Board Company – Health Care Performance Management Solutions and Services
• The Health Care Blog
• WSJ Health Blog
• CMS – Centers for Medicare and Medicaid Services.
• HL7
• IOM – Institute of Medicine. The following two reports are essential reading: 
  • To Err is Human: Building a Safer Health System – 1999
  • Crossing the Quality Chasm: A New Heath System for the 21st Century – 2001
• ICD-10

This TED video from Jane McGonigal makes a persuasive case that I need to invest some more time looking at the world of online gaming for insight. Watch the video  and see if you don’t come to a similar conclusion.

First, one caution; when I do use slides I don’t design them to be standalone documents. There are too many bullet points in the world as it is. What I’d like to do here is highlight and elaborate on some of the key points I was trying to make.

Peter Drucker first called our attention to the importance of knowledge workers decades ago. The rest of us are slowly catching up to his ideas. One shift in focus that I’ve begun to emphasize is toward the knowledge work itself and away from the notion of knowledge worker as somehow distinct from other kinds of workers. Trying to distinguish who may or may not be a knowledge worker as opposed to some other kind of worker simply perpetuates pecking order games that do little to further the mission of an enterprise. We all do knowledge work  to some degree or another, we are all doing more knowledge work than before, and the important question is how to do that work more effectively.

The notions of visibility and observability have been central to my thinking for some time now. The evidence is clear that dealing with complex problems and thinking requires a certain amount of corresponding complexity and mess in our working environments. To those whose focus is on stability and operational control, mess, of course, is disturbing. So disturbing that we ridicule those who deviate from the presumed ideal. We do so at a greater organizational cost than we realize, however, when we ignore the complexity in the environment that is driving the mess.

I introduced the following simple map to suggest just how unavoidably messy the real world of knowledge work can be. The x-axis maps the inherent structure of the knowledge "stuff" we encounter; the y-axis maps the degree to which knowledge stuff is individual or social. It didn’t take long to identify a multitude of items and objects that you might routinely encounter as you go about your work.

It’s tempting to simplify this reality in some way. Many years ago P&G was famed for teaching its managers to distill their arguments into one-page memos. Too many consultants and speakers opt to squeeze all of their output into slideuments; which merely transfers the problem somewhere else. Senior executives rely on staffs to filter the stream at the risk of filtering out the essential insight or data point that truly informs.

The strategy I prefer is to accept the fundamental messiness and seek ways to tame it enough to make it manageable. Part of that relies on exploiting the natural pattern-seeking, pattern-matching capabilities of the human mind. Part relies on enlisting the pattern management capabilities of the other human minds in the system to supplement your own capacity. Both of which also need to be tempered by appreciation for the limits of those same capabilities.

Taming the mess breaks into three layers of practices:

1. Hygiene. The proliferation of objects in a physical office offer a host of clues about their contents and relative importance; size, shape, color, location on a shelf or desktop, position in a stack, etc. In a digital environment you need to provide the equivalent of those clues explicitly and consciously. Seemingly mundane decisions about the file names you choose, for example, can make large differences when you are later scanning through a page of search results. Most of today’s systems provide little real assistance in this arena; you and your teams need to develop their own standards for naming files, managing versions, and other details of the knowledge stuff they work with.
2. Metadata. i wish there were a more homespun term for this layer. One of the central tricks to taming the flood of data and information that constitute your digital world is to add more data to the flood. The ability to tag the items you create or encounter with labels that are meaningful to you greatly leverages the other tools at your disposal. Merge those tags with the tags of those in your social network and you shorten the path to finding what you are searching for still further, either on your own or through your network’s help.
3. Context. One of the least appreciated aspects of messiness in the physical world is the context it provides. There’s a story attached to each pile and object; a story that can be triggered by its context. The power of this context is why students do better on tests when they take them in the same classroom they took the course in than in a random room. A filename in a directory listing or a document displayed on  a monitor lack this ready context and are poorer for it. The alternative is to become more mindful of the importance of context and make an effort to capture it explicitly and contemporaneously. This is rationale behind such notions as narrating your work, and developing a digital portfolio.

There is a payoff to all of this for both individuals doing knowledge work and the organizations they contribute to. Once again Peter Drucker said it first; "the most valuable asset of a 21st century institution will be its knowledge workers and their productivity."  Economic growth in this century depends on our ability to improve knowledge work productivity; until you can see it, you can’t improve it.

How might we best go about improving knowledge work, both practices and outputs, in today’s complex organizational environment? Are there paths other than simple trial and error that might lead to systematic gains?

Frederick Taylor and his followers built their careers on finding the one best way to carry out a particular physical task. Later proponents of this way of thinking transferred their approach to defining the one best way to carry out information processing tasks. John Reed of Citibank launched his career by applying factory management principles to automating check handling. Reengineering essentially rebooted these approaches for a richer technology environment, but held to the premise that outputs were a given, tasks could be well-defined, and processes could be optimized.

Peter Drucker, in his typical way, pointed out that the key to understanding and improving knowledge work (PDF) was that there was no defined task to be optimized. Knowledge workers start by defining the task at hand and an output of suitable quality. This is not an approach which lends itself to conventional improvement or optimization approaches.

Two useful approaches come to mind. One would be to identify and shadow individual knowledge workers deemed to be particularly effective. Observing, understanding, and emulating their personal practices would be time well spent. A second approach would be to identify a class of knowledge workers who have been dealing with the problems of knowledge work in the modern enterprise long enough to have developed practices and approaches that might be broadly adaptable to knowledge work activities in general.

Both of these approaches are well worth undertaking. Today, I’d like to take a look at this second approach. A recent blog post by Eric Raymond prompts looking at a group I’ve often thought of as the leading edge of modern knowledge work– software developers. Over the last half-century, this group has been inventing and developing the technological infrastructure that shapes our modern enterprises. As such, they have been the first to encounter and address the challenges of knowledge work. Certainly any group responsible for the Internet and the invention of open-source software will have lessons for the rest of us as we try to bring forth our own examples of knowledge work products.

Raymond, among many other things, is the author of the excellent The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary. He also maintains the always interesting and provocative blog Armed and Dangerous. In a recent post, “the social utility of hacker humor”, Raymond dives into the number of the behavioral norms that he believes characterize hackers and software developers. The entire blog post is well worth your time, but let me call your attention to the following excerpt:

…every once in a while something erupts out of them that is a game changer on a civilization-wide level. Two of the big ones were the Internet and open-source software. These two movements were intimately intertwined with hacker culture, both produced by it and productive of it. The origins of our tribe go back a bit further than either technology, but we have since re-invented ourselves as the people who make that stuff work.

And I don’t mean “make it work” in a narrow technical sense, either. As long as there are people who laugh at INTERCAL and RFC1149 and the Unix koans of Master Foo, and recognize themselves in the Jargon File, those same people will care passionately that computing technology is an instrument of liberation rather than control. They won’t be able to help themselves, because they will have absorbed inextricably with the jokes some values that are no joke at all. High standards of craftsmanship; a subversive sense of humor; a belief in the power of creative choice and voluntary cooperation; a spirit of individualism and playfulness; and not least, a skepticism about the pretensions of credentialism, bureaucracy and authority that is both healthy and bone-deep.

[Raymond, Eric S. Armed and Dangerous. "The social utility of hacker humor"]

Substitute “knowledge worker” for “hacker” and I believe we will find parallels worth exploring.

This is still in the working hypothesis stage. I can think of a number of practices that might prove worth emulating and some useful entry points into learning more.

Practices worth investigating

Serious software developers have adopted a number of practices as they’ve struggled with the challenge of designing, developing, and evolving products that are pure thought stuff. To the extent that knowledge work is also a process of developing outputs that are themselves largely thought stuff, these practices ought to have analogues. Here’s a preliminary list, in no particular order.

• Version control/source code control. Final outputs and products grow through a process of successive refinement.� “Track changes” in MS Word seems inadequate to the task as do informal conventions on controlling successive iterations of final output documents.
• Issue Tracking/Bug Tracking. With multiple cooks and multiple tasters, the review processes of getting from a possible finished product to a definitive finished product revolves around identifying and systematically addressing both feedback and proposed responses from a multitude of sources. Software developers have invested in tools and processes to support that inevitable process; why not translate that process to the equivalent process of vetting a final report?
• Agile Development Practices. The software world has long struggled with managing the process of getting from germ of an idea to finished product in a finite amount of time. They’ve tried and generally abandoned a variety of approaches (like the waterfall model) that pretend to turn a fundamentally iterative and evolutionary process into a faux-linear process. Their processes now accept this iterative reality at the same time that other knowledge work fields like the law are discovering old ideas of project management that have been abandoned because they don’t and can’t work on knowledge process outputs. Can’t we shorten the learning curve given that we know how it played out before?
• D.R.Y. – Don’t Repeat Yourself is a heuristic that software designers and developers have employed to excellent effect in multiple settings. It rarely applies directly to final delivered systems; rather it’s a process of seeking and finding common subsystems and repetitive activity sequences that can be carved out and solved in a general way that can be applied across future efforts. What pieces of our knowledge work efforts are we repeating to no useful purpose?
• Modules not Monoliths. You eat elephants one bite at a time and you solve big, complicated, problems by breaking them into more manageable pieces. The software development world has followed this logic to a fare-thee-well. A typical webpage is built by assembling pieces from multiple sources on the fly. Meanwhile, the typical consulting report is still a single giant Word or PowerPoint file that overwhelms the typical email system when mailed to a client.

Some sources of ideas

Here’s a quick list to some further reading that looks promising:

• The Design of Design: Essays from a Computer Scientist, Brooks, Frederick P., Jr.
• The Mythical Man-Month : Essays on Software Engineering, Brooks, Frederick P., Jr.
• F.P., Jr. Brooks, “No Silver Bullet Essence and Accidents of Software Engineering,” Computer, pp. 10-19, April, 1987. This is a chapter in the 25th Anniversary Edition of The Mythical Man-Month but a little searching will find copies of the original article by itself.
• Open Sources: Voices from the Open Source Revolution (O’Reilly Open Source), Dibona, Chris
• Producing Open Source Software: How to Run a Successful Free Software Project, Fogel, Karl
• The Pragmatic Programmer: From Journeyman to Master, Hunt, Andrew
• Ship it! A Practical Guide to Successful Software Projects, Richardson, Jared
• Coders at Work, Seibel, Peter
• The Psychology of Computer Programming : Silver Anniversary Edition, Weinberg, Gerald M.
• Manifesto for Agile Software Development

Where do we go from here?

Some next questions on my mind worth exploring:

1. What can we do to pursue this path more systematically?
2. What other practices are worth investigating?
3. How best do we translate practices from the development world to the broader world of knowledge work?

A skill worth developing as far as you are capable, although few  of us will reach his level of mastery.

Part 2, Part 3, Part 4

In general these open ended discussions of culture are unsatisfying. They make gross assumptions on the basis of little data. Dave Snowden’s principles of knowledge management (see Rendering Knowledge) provide important pointers to a better answer with his emphasis on the behavior of individual knowledge workers.

Enterprise 2.0 as the extension of ERP

Michael Idinopulos of SocialText noted a shift in the debate at the recent Enterprise 2.0 conference in Boston. In a post titled The End of the Culture 2.0 Crusade?, he observed that:

Last week, the Enterprise 2.0 world turned a corner. Nobody pounded the table for cultural change. Nobody talked about incentives or change management. Nobody talked about transparency or modeling collaborative behavior.

Instead, people talked about process.

…

This is the most pragmatic shift in focus since the inception of Enterprise 2.0. It will have huge effects on the pervasiveness of social software in the enterprise, because it shows a clear path to the business value companies can realize from their implementations.

I’ve been arguing for some time that social software achieves widespread adoption only when workers use it in the flow of work. Asking your colleagues to step outside their daily processes and tools to share what they know or network with others won’t get you very far. (Trust me, I’ve tried.) Bringing your colleagues collaborative tools and practices that make their daily processes better, faster, cheaper, and more interesting does work. It’s all about process. Improve the process, you win. Don’t improve the process, you lose.

This point of view squares with Ross Mayfield’s that broken business processes contribute to email overload and that

(Employees) spend most of their time handling exceptions to business processes. That’s what they are doing in their inbox for four hours a day. E-mail has become the great exception handler.

While this is a very attractive position, it is incomplete in an important, and potentially dangerous, way. If you focus Enterprise 2.0 efforts solely on business process you may get scale, you will likely avoid the issue of culture, BUT you risk missing an opportunity for great leverage.

Leaving Process for Practice: Leveraging Knowledge Work as Craft

Focusing solely on Enterprise 2.0 efforts as an extension of existing business processes treats Enterprise 2.0 as a residual, clean-up, effort. It presumes that the goal worth pursuing is the efficient execution of well-defined processes. It reduces Enterprise 2.0 to an afterthought to ERP.

There is an assumption in this process-centric view that all relevant behavior can be reduced to business rules in the automated system. Exceptions are viewed as system failures or design failures. Moreover, failures in the system are attributed to resistance on the part of system users and operators. Instead of interpreting failures as resistance, what if we start by treating them simply as data?

If you start with process, your goal is uniformity at scale. Ideally, every situation should be treated in exactly the same way. This is eminently logical if you are calculating payroll withholding taxes. It is clever when you extend that logic to treating airline seats as a perishable commodity whose price might vary depending on the day of the week. Can you push in this direction forever?

Are there situations where uniformity and scale are not the appropriate criteria? Of course. The realm of art and craft is all about uniqueness and the value of limited scale. What happens if we opt to start from the art and craft end of the spectrum?

One choice is to accept the dichotomy. There is a class of problems suited to process thinking and a class of problems suited to art and craft. Another choice is to continue to force fit problems into a process view of the world. This has been a successful approach. Consider the number of problems that have been transformed into algorithmic problems well-suited to automation — inventory control and demand forecasting to name two.

A third choice is to ask how to improve art and craft without presupposing that uniform process is the goal. This was the approach started by Vannevar Bush, Doug Engelbart, and their intellectual heirs. This approach spawned much of the technology environment that we operate within today. Oddly, we’ve largely ignored their motives in creating this technology; to support more effective ways of wrestling with intellectual problems.

Engelbart, and those working on his agenda, started building new technology tools because our previous tools and methods were inadequate for the problems we had to solve. They built tools to support new kinds of problem-framing and problem-solving practices. We’ve adopted the tools without considering the practices and behaviors they were designed to enable.

Culture as the sum of shared behaviors

Those who lay the blame for failed efforts to introduce knowledge management or Enterprise 2.0 tools on organizational culture are picking up on this behavioral issue. They are doing so, however, at the wrong level of detail. Organizational culture is a convenient shorthand for the practices and behaviors that constitute "they way we work around here." Changing culture is hard because it’s an abstraction; there’s nothing to push against to get it to move.

While changing behaviors can also be hard, as anyone who’s tried to adopt a new habit can attest, it is possible. Change the right behaviors and eventually you have a new culture. The opportunity in Enterprise 2.0 technologies lies in the new behaviors that become possible. The challenge is that these technologies do not dictate a single set of obvious behaviors. In fact, it is possible to adopt the technologies and make no behavioral changes at all. 

Focusing on behavior is still a challenge. Technology opens up possibilities while setting few constraints. The activities we are interested in here are equally unconstrained by business process; we’ve defined them as the behaviors that don’t fit within the mantle of process. We need to go back to observing how work is currently being done, ask what flows smoothly, see where things get stuck, and design alternate ways to make use of the new range of available tools. We’ll visit those questions tomorrow.

LATE BREAKING LINK: As I was about to publish this post, John Tropea of Library Clips posted a lengthy piece on Have we been doing Enterprise 2.0 in reverse : Socialising processes and Adaptive Case Management. I’ve only just skimmed it, but it’s squarely part of this evolving conversation.

Recap

Greg Lloyd, CEO at Traction Software, kicked things off. pulled together some key threads of the conversation and gave us a better label – “observable work.” His initial summary:

I believe that principles of open, observable work – like open book financial reporting to employees – is a simple and powerful principle that people at every level of an organization can become comfortable using. In my opinion, wider adoption of observable work principles can succeed with support and encouragement from true leaders at every level of an organization – as Peter Drucker defines that role: “A manager’s task is to make the strengths of people effective and their weakness irrelevant–and that applies fully as much to the manager’s boss as it applies to the manager’s subordinates.” Enterprise 2.0 and Observable Work

Greg also pointed to an excellent post by John Tropea at Library Clips:

why do I have close to total awareness of people in my personal life that requires low effort, but yet in the workplace I don’t have this ambient awareness!

In fact it may be more crucial to have micro-blogging/activity stream networks in the workplace as we share and work on the same/similar/related goals and tasks within our teams, across teams, workgroups, and enterprise wide…so the more we are aware, the more we can be on the same page, and have better coordination, cooperation and collaboration…surface opportunities (emergence), have the best people on the right tasks, and generally have the ability to be more responsive and adaptive.� Ambient awareness is the new normal, c’mon already!

Mary Abraham raised a cautionary voice:

I found myself saying “TMI” when I first read a terrific set of posts by Jim McGee, John Tropea and Jack Vinson regarding the benefits of information transparency among knowledge workers and the importance of making knowledge work more visible. Granted, I was “catastrophizing” as I imagined a workplace where every thought was expressed in writing before it could be edited for appropriateness or sense. I imagined my daily e-mail deluge multiplied many times over once I moved from messages directed at me to a stream messages directed to the entire firm.� I imagined a tsunami of triviality swamping me daily as I struggled to be productive. I imagined having to hide myself in a technology free cave in order to get any work done. TMI

There is excellent commentary attached to each of these posts.

Other related posts and observations that have found there way into my filters include:

• Observable Work: The Taming of the Flow
• Invisible work – spray paint needed

Foundations

Like Greg Lloyd, I would highly recommend becoming more familiar with Doug Engelbart and his body of work. Greg provide an excellent starting point with his post on Traction Roots – Doug Engelbart.

It’s also well worth taking a look at Dave Winer’s work and thinking in this arena. The following two links are good entry points to his efforts:

• Narrate Your Work
• Before There Was Twitter, There Was Dave Winer’s Instant Outliner

Paths Forward

I’m greatly encouraged by the discussion and debate we’ve already triggered. Greg suggested #owork as a useful twitter tag to follow these discussions. Here are some questions and ideas that i think are worth pursuing. Please feel free to join in the discussion and the effort as it unfolds;

• What can you do to make your own work more readily observable?
• How might making your work observable be immediately beneficial to you, even if no one else bothered to pay attention?
• Who else benefits if your work is more observable?
• How do you benefit from others making their work more observable?
• What risks and challenges do you need to manage as you make your work more observable?