Last week I attended the Traction User Group (TUG) conference at the invitation of Traction co-Founder Greg Lloyd (thanks for the invitation!). While it was your usual software user-group meeting with customer presentations and some software updates, they also designed in a larger discussion around the concept of Observable Work with keynotes from Jim McGee and Jon Udell as well as several of the customer presentations tying into the idea. I was disappointed to attend only one day, as the next day was going to be including an open discussion around observable work. It was also nice to see a number of people there who I normally only see virtually on Twitter. There was a very active Twitter presence all day at the hashtag #TUG2010. Please forgive the length of this post - I seem to be doing that a lot these days.
What is observable work? It's the idea that we should "unhide" our work - the work process, rather than just the final work product. Not only should we be publishing the work product (documents, websites, code, etc), but we should also be helping each other see how we got to the work product itself. This might be anything from talking aloud and with one another as we go through the process. But it could also be writing about how things are going or what we are doing from a day-to-day perspective as well. What did the intermediate draft look like? How did you go from that buggy code to something that was released? How did you do it so quickly? Or what was it about the work that was difficult? Traction's Greg Lloyd wrote up a series of discussions around the idea in June after the E2.0 conference, Enterprise 2.0 and Observable Work. I've written about it too, Explicit Work.
Jim McGee was the opening keynote - expanding on his Managing the visibility of knowledge work. He covered a lot of familiar-to-me ground on the topic of knowledge work and his developing ideas around observable work. I liked his comparison of an "observable work" environment (a photo of Al Gore's messy workspace) with a person sitting in front of a screen in a pristine office. All the messiness of the work is all there, it is just all inside the computer - and inside the knowledge worker's head, rather than in plain view for people to understand what is happening. And this is the problem with today's knowledge work. Our work products end up all over the place from personal filing systems to network drives to email to public spaces to document stores to archival systems to wikis and blogs and .... It becomes messy very quickly - it just happens that it is difficult to visualize the mess.
Getting into the meat of the switch to observable work, Jim talked about the idea of context - one of my favorite topics. Making your work visible provides people who are observing or who want to reconstruct your thought processes some of that valuable context. Ideally, an observable work trail would show dead ends explored, research reviewed, ideas tried on - all elements that might never end up in the final report but are key elements of why we are hired as knowledge workers in the first place.
Be careful where you tread. Jim had a short discussion of cautions for moving into an observable way of working, and a few others came up in questions and at other times through the day. Old habits die hard - no matter what we do, knowledge work is not as reproducible as factory work. It shouldn't be measured in the same ways. It's the overall output and lead time that counts anyway. (I struggled with this one a bit, because measures and efficiencies are something I watch for in my consulting practice.) And with measures come ways to game the system: set up measures that give you what you want, not measures which make people look busy. And a key thing to watch for in this world: knowledge work crosses boundaries. Making it visible just makes this fact all the clearer to people who like to think everything is locked up within the firm. This is particularly true as firms fracture and reform and fracture again. (And I just saw one in the Twitter stream several days later: concerns about trying observable work in hostile corporate environments - this wasn't discussed while I was there on Wednesday.)
PKM connection. I had an "ah-hah!" as I pondered what I heard throughout the day. This idea that the work process should be visible reminds me very much of the personal knowledge management discussions I've had over the years. One key element of that is knowing how I am working, so that I can consider ways to improve that work. I need to know what my "magic" is (to borrow something from Jim). Or in terms I've come across recently: what is my "moment of truth." I need to spend time looking at how I create this, so that I can get better at it in the future. I think one idea of observable work is right along these lines: if I can see it, I can think about ways to make it better / different. Jim talked about this as having good mental models - models of what and how I am working. In a software environment, good mental models make all the difference between software that is okay and software that is in tune with the way people work - software that actually helps people get things done.
No more drive-by shootings. One of the examples came from an IT department who were getting completely overwhelmed with "just one thing" work requests in the process of a major software implementation. The presenter called these their "drive by shootings" of the team because they seemed to come out of nowhere. The key issue for them was that no one knew how much work was in the queue - not even the team that had owned the queue. So, they built a request form on top of Traction that created items within traction. And these items were then published and tracked in a very simple way. Everyone knew how much work was getting completed, how many requests were coming in, and the status of those requests as they went through the process. They've been able to significantly drop their backlog, simply because they could see it. This is the kind of solution that many organizations could use to help manage their overwhelmed people. (There is more than just the form on top of Traction software - the key is the visibility and a process that made sense for them.) Another company described a similar example where they kept their "project scorecard" in a Traction space and as it was updated, they left comments and information about what changed and where to find more detail about the specific elements of the scorecard. This worked really well for them and was easy to get started.
Step away from the email. Several of the customer examples had a very familiar ring to them: people are spending too much time in email and they aren't getting anything done. And with the examples discussed, they were using Traction to help move their people away from email and into the web-based Traction software. In one case, the software became the central point for information about the company's products, and people could decide to subscribe to updates, rather than having the marketing department try to balance too-frequent emails with not-enough customer contacts. There was a similar example where internal emails were replaced with a topic-specific site within Traction that allowed people who were truly interested to follow, rather than blasting email out to thousands of people within the company. Another company had great success in using the tool as a place for a Question-and-Answer style service, where internal experts archive their frequent questions as well as cover new questions or twists on questions within Traction. Of course, getting people out of email takes some hand holding, but the examples discussed sounded like they had successfully made those transitions.
Intelligence. There were a couple presentations that talked about using Traction to help collect and track and analyze intelligence information - competitive intelligence and otherwise. One presenter took this in a completely different direction. Arik Johnson's topic was "Adventures in 21st Century Organizational Design." He's a (former?) competitive intelligence consultant and has set up the Intel Collaborative to bring together others interested in the topic. The reason I'm mentioning his talk is that he tossed out several interesting comments:
- Strategy should be a response to intelligence (about the world) - not a reason to go and find intelligence that supports your strategy.
- Forecasts are palliative. They are designed to make us feel better. They don't actually predict surprises - the things that the best companies can weather.
- Companies are unnecessarily complex.
And bringing it back to the observable work theme, Arik talked about competitive intelligence as something that happens all the time. But if you don't have an organized effort to do something with it, that intelligence is hidden from you.
Redux. Jon Udell provided the closing keynote, echoing a number of themes that were discussed during the day and bringing in new and wider perspectives on the idea of observable work. One of these tied back to Jim McGee's long-standing "craft work" discussions and reminded us that we all learn by observation: kids learn from their parents; apprentices learn from masters; etc. It is those people who narrate their work for the wider world that provide an interesting example of how observable work could be made to play in the 21st Century. I liked Jon's take on why narration is so important to people who observe it: they learn things that aren't said. Jon watched a video of a printer repair and learned that he'd have to really crank on something to get it open - something that wasn't written or spoken, it was shown. And Jon reiterated a concern that was mentioned in a few of the examples throughout the day: people don't want to be "observable" for many reasons, one of which is that they don't want to be seen as a "performer." They are either too shy to be in front of people, or they have a worldview that suggests people shouldn't be tooting their own horns. Another example mentioned this and found a way around by having people help others, rather than having them keep public weblogs - the helping was seen as less egocentric.
Jon closed with an interesting suggestion. People who are already "out there" need to teach others the possibilities and let them try out new ways of working. He combined this with a simple technical call for action: make things human readable AND machine processable. Example: the calendar on your kids' school website is easily readable by humans, but if it is a PDF, then machines can't do anything with that information - like put it into a personal calendar for reminders.
What does Traction get? From the Traction standpoint, the software can certainly support an Observable Work environment where people can track their activities, comments, tasks, projects, etc. And, of course, you can follow each other and pay attention to people or workspaces or the like. One of these days, I will get into a real installation of Traction and get to play with this myself. (I can't install on our company website due to the limitations of our hosting service.)
[Photo: archival photo of Eastons Beach, where we had a clambake in the evening, from the Providence Public Library archives on Flickr]