Knowledge Workers – Eugene Eric Kim

High-Performance Knowledge Work: Practice, Practice, Practice

Published October 6, 2008 by Eugene Eric Kim

I talk a lot about the goal of being a “high-performance” knowledge worker, of achieving “high-performance” collaboration. I’m certainly not the only one. But what does it truly mean to be “high-performance”? (N24)

One way to answer that question is to think about fields where the answer is more clear, such as sports, music, and medicine. Last year, I wrote: (N25)

Medicine is a great model for what’s in store for other types of KnowledgeWorkers in this rapidly changing world. I know very few KnowledgeWorkers who spend as much time learning and honing their skills as doctors do. Can you imagine what we could accomplish in this world if we did? T (N26)

My friend, Lisa Chu, founded a violin school for kids, and she often blogs about the discipline required to achieve greatness. Recently, she quoted Brian Johnson, who wrote, “The higher the greats climb, the GREATER the need for practice.” (N27)

Think about the work that world-class athletes, musicians, and doctors put in to stay on top of their game: the discipline, the training, the emphasis on fundamentals. Do any of us Knowledge Workers really apply the same standards to our crafts? (N28)

Jor Bagh

Published February 29, 2008 by Eugene Eric Kim

I spent the afternoon working in IIE’s Delhi office, located in Jor Bagh, a charming residential district that contrasted sharply with the Delhi I had seen the night before. On the ride over, Sanjay explained India‘s political situation regarding health care, education, and other infrastructural challenges. (MWF)

India is a study in contrasts. There is tremendous economic disparity. Over a million people in Delhi (about eight percent of the total population) live beneath the poverty line. The infrastructure is poor, to say the least. The roads are bad, the power unreliable, the water scarce and undrinkable. And yet, India has a burgeoning population of skilled and intelligent Knowledge Workers, especially in technology. (MWG)

To its credit, the current government is trying to do something about its infrastructural woes. It has committed to tripling its expenditures (percentage of GDP spent) in health and education over the next five years, and similarly increasing its expenditures in other areas, such as potable water. (MWH)

After enjoying a delicious lunch of samosas, dhokla (which I tried for the first time), and gulabjamun, Cheryl Francisconi rejoined us and introduced me to Ajit Motwani, the new head of IIE India, who regaled us with stories of his eclectic past and who introduced me to lime water, water with lime juice, sugar, and salt, sort of an all-natural Gatorade. (MWI)

(MWJ)

(MWK)

In the afternoon, Cheryl and I took a taxi to the airport, where we experienced an incredibly surreal traffic moment. At one point, we crossed a six lane bridge, with rickshaws and buses pulled over on the sides and middle of the road. No one was paying any attention to the lanes, and no one was slowing down either. It felt like I was playing one of those racing video games, except with quadruple the traffic. And yet, it didn’t feel disorderly either. Somehow, everything just worked. (MWL)

As we watched similar madness in the terminal later, I observed to Cheryl that Open Space must feel comfortable to folks in India, because they’re so used to ordered chaos. That sparked a long conversation about process and culture that continued well into our flight to Patna. (MWM)

At the airport, we met up with Sanjay Pandey and Narendra Gupta, who will be a guest participant at the meeting over the next few days. Narendra is from Chittorgarh, a small town in the state of Rajasthan, and his background is fascinating. I’m looking forward to chatting more with him and watching him work tomorrow. (MWN)

The Chandler Project

Published February 28, 2008 by Eugene Eric Kim

Almost 20 years ago, in my old stomping grounds at Dr. Dobb’s Journal, Mitch Kapor published an article on software design. He wrote: (MU0)

The lack of usability of software and poor design of programs is the secret shame of the industry. Given a choice, no one would want it to be this way. What is to be done? Computing professionals themselves should take responsibility for creating a positive user experience. Perhaps the most important conceptual move to be taken is to recognize the critical role of design, as a counterpart to programming, in the creation of computer artifacts. And the most important social evolution within the computing professions would be to create a role for the software designer as a champion of the user experience. (MU1)

His manifesto stuck with me over the years, and when I started organizing the first FLOSS Usability Sprints with Aspiration, one of the first people I contacted with Mitch. Mitch not only agreed to sponsor our event, but he put me in touch with Mimi Yin and Katie Capps Parlante, two of the leads of the Chandler project. Both Mimi and Katie were enthusiastic about working with us, and Chandler became one of our first participating projects. (MU2)

At the time, Chandler was a lot of design and very little code. What intrigued me, though, was their design approach. They were aggressively committed to User-Centered Design, which was totally unique for an Open Source project. In many projects, Open Source or otherwise, interface design plays a secondary or worse role in the overall project. The interface is often designed after the fact. With Chandler, interface design played a core role in the overall design. (MU3)

Last fall, Chandler participated in the fifth incarnation of our sprints, and it was amazing to see how much progress the team had made. Not only was there working code, but there was an active developer and user community, and there was an ongoing commitment to their design approach. The project was also about to face a major transition, having reached the end of its incubation phase under Mitch. (MU4)

After reconnecting with Mimi and Katie, I decided it was time for me to start using Chandler. The timing for me was good. I had been a very happy user of todo.txt for personal use and a reluctant user of Basecamp for group projects. I wanted something that could replace both. The fact that it was a cross-platform desktop application was also appealing, because I regularly use three different platforms (Linux, Mac, and Windows) and because some of the people I’m currently working with do not have consistent access to the Internet. (MU5)

The Why of Chandler (MU6)

At its core, Chandler is a task manager in the spirit of David Allen‘s Getting Things Done methodology. You have items that you can organize into collections and prioritize as “Now,” “Later,” and “Done.” If you add a date to an item, it will appear on your calendar. And you can assign items to others. (MU7)

You can view your list of “To Do” items by collection, in a calendar (if they have dates), or in a dashboard view that provides an overview of all the different things you have to do. (MU8)

Simple, right? Well, yeah. That’s a good thing. But if you dig a bit deeper, you can see that this simple design has some very powerful consequences, and it all centers around this notion of the item. (MU9)

Items have titles and descriptions, which are free-form text. They have priorities and possibly dates. Items can belong to as many or as few collections as you’d like. Items can be shared with or assigned to others. (MUA)

The notion of an item is pretty generic, and in fact, you can see it in a lot of other applications as well. Email is the classic example. An email message can be thought of as an item. In fact, many people use their email as task managers. If they want to share an item, they email it to others (which is how Chandler works as well). If they want to categorize an item, they move it to a folder. If they’re lucky (for example, if they use Gmail), they can give an item multiple tags. (MUB)

But email has downsides. The interface is not optimized for task management, although there are plugins that help. Most clients do not support tagging, which means that you have to copy items to multiple folders, and those items do not stay in sync. And email messages are static, whereas an item should be able to evolve over time. (MUC)

Other applications that use this exact concept of an item are, well, other task managers: Basecamp, Remember the Milk, Bugzilla, RT, Trac, etc. In many ways, these are competing products, but in the Chandler world, they are actually complementary products. (MUD)

This is the hidden beauty of Chandler. Chandler recognizes that people will be using a lot of different tools, from email to RSS to other task managers. It doesn’t try to be The One Tool. Instead, it is designed to be interoperable. You can write plugins that synchronize items in other applications with items in Chandler, so that you can use Chandler to do what it does best, and other applications to do what they do best, and all the data stays in sync. (MUE)

Chandler essentially becomes a dashboard for knowledge work, a place where Knowledge Workers can live and get things done. Right now, email fulfills that role for most people. A tool like Chandler has a very good chance of supplanting email in this department, because it offers an interface that is more in line with what Knowledge Workers want to do. More importantly, it works with email rather than trying to replace it. (MUF)

Chandler works right now. I use it every day, and I’m productive in it. However, its great potential is still largely unfulfilled. The interface is still rough, and there are very few plugins that take advantage of the synchronization capabilities. Every once in a while, I find myself longing for todo.txt (although it should be relatively straightforward to write a command-line based interface to Chandler that emulates it). (MUG)

However, I believe that this roughness still works in Chandler’s favor. Why? Because as I noted earlier, Chandler is perhaps the only Open Source project in existence that aggressively integrates Open Source development principles with user-centric design. What we’re seeing right now is a spike, a product of Release Early And Often. But if you follow the design discussions — and you can, because it’s Open Source — you can see the ethos of User-Centered Design come through. The interface for the upcoming 1.0 release is going to be significantly better than the current design (0.7.4.1), and that will merely be scratching the surface of what is to come. (MUH)

Chandler has the potential to be a really great tool relatively soon. It’s not there yet. But if you’re excited about the idea that an Open Source development process can actually result in better software for real people, you should take a look now. More importantly, you should participate in the community, which is fantastic, thanks largely to the expert guidance of Ted Leung and the development team’s active participation. Chandler is definitely a project to watch. (MUI)

Medicine and Continuous Learning

Published May 9, 2007 by Eugene Eric Kim

Last month, after Creating Space in Baltimore, I decided to go up to Philadelphia to visit my friend, Ed. Ed’s a radiology resident at the University of Pennsylvania Hospital. He was on call for one of the days of my trip, and he let me join him and observe. (M8J)

(M8K)

Radiologists study medical images — X-rays, CT scans, etc. — and make diagnoses based on what they see. As you might imagine, the practice of radiology changes dramatically as technology progresses. (M8L)

When they’re on call, radiologists camp out in a tiny, dark room surrounded by super high resolution computer monitors, tracking an ongoing stream of images from patients coming to the emergency room. They study the images and make diagnoses using voice recognition software. Occasionally, other doctors will come by and consult with the radiologists, but for the most part, it’s a lonely endeavour. (M8M)

When I joined my friend, he was examining the scans of a young man who had been shot in the torso. It was a serious case, and Ed was examining different scans from all angles, speaking into his microphone in a language that was completely foreign to me. The kid was extremely lucky; no vitals were hit, and he was going to be okay, so Ed walked me through what he had done, deciphering the scans, explaining the workflow, and showing off his tools. (M8N)

It was a fascinating and sobering experience. Doctors epitomize high-performance knowledge workers. The field is incredibly complex and is constantly changing. Moreover, the stakes are extremely high: people’s lives and livelihood. It requires years of training and practice, and the learning doesn’t stop when you graduate from school or complete your residencies. (M8O)

As you can imagine, the language is extremely specialized. I had to stifle a laugh the first time I heard Ed speak in the microphone. It literally sounded like he was speaking in a different language, even though I was pretty sure he was speaking English. (M8P)

Radiologists in particular use cutting-edge technology, and the technology is constantly changing. I was particularly impressed by the user interface for examining scans and by the workflow. There were some deficiencies in the software, and the voice recognition software in particular seemed disappointing. I thought that Ed could have typed his diagnoses in the time it took to review and correct the transcripts. One thing that helped a lot were reporting templates. Ed told me that some doctors literally had hundreds of templates for all sorts of situations, and that they saved a lot of time when used judiciously. (M8Q)

I was particularly impressed by the amount of continous learning required to stay on top of the field. Not only is medical knowledge constantly progressing, but the tools are constantly changing. As a result, doctors are constantly studying. They may graduate from school, but the learning doesn’t seem to slow down much. (M8R)

Medicine is a great model for what’s in store for other types of Knowledge Workers in this rapidly changing world. I know very few Knowledge Workers who spend as much time learning and honing their skills as doctors do. Can you imagine what we could accomplish in this world if we did? (M8S)

Group Information Hygiene

Published January 3, 2007 by Eugene Eric Kim

Last August, I wrote: (LPS)

When we founded BlueOxenAssociates, we were supposed to be a place for those on the cutting edge of collaboration. I quickly discovered that most people who want or claim to be on the cutting edge are held back by poor PersonalInformationHygiene. People need to start with themselves before they worry about the group if they want to improve their ability to collaborate. (This is a general theme that extends beyond KnowledgeManagement.) T (LPT)

Poor Personal Information Hygiene can often interfere with group trust, and trust is a prerequisite for good collaboration. (LPU)

In an ideal world, everyone on your team would be masters of Personal Information Hygiene, but in reality, that’s rarely the case. Frankly, I’m not sure if it’s always desirable. People have different kinds of intelligences, and it may be that certain kinds of intelligences are critical to a high-performance team, but are also orthogonal to good Personal Information Hygiene. (LPV)

Is it possible to have good Group Information Hygiene if people on a team have poor Personal Information Hygiene? Moreover, is it possible for the whole to be greater than the sum? (LPW)

You all know what my answers are. (LPX)

Part of the MGTaylor facilitation philosophy is to offload all potential distractions so that the participants may focus entirely on the task at hand. When you attend an MGTaylor Design Shop, there are several Knowledge Workers present, who are responsible for managing the distractions (among other things). They set up and reset the environment. They scribe your conversations. They manage the clock. (LPY)

The philosophy is not exclusive to MGTaylor. The Aspen Institute follows a similar process. So do high-level politicians and actors in big-budget films, where their schedules are minutely managed so that they can focus entirely on acting… er, and policy-making. So do fancy restaurants. The food at Gary Danko in San Francisco is fantastic, but the service is unbelievable. There are literally six servers hiding in the shadows, anticipating your needs and making sure your table space is always pristine. Your glass is always full. Your napkin is always folded. If you’re about to go to the bathroom, a server will pull out your chair and point you in the right direction. Remarkably, they pull this off without being overbearing and creepy. (LPZ)

We can debate whether or not this is always a good thing. (I think the answer is no.) We can certainly agree that this level of service is not always practical. What’s indisputable is that in a collaborative situation, these things need to be done by somebody. The question is by whom? (LQ0)

The Sacrificial Lamb (stolen from Jim Coplien and Neil Harrison‘s SacrificeOnePerson pattern) is both a pattern and an antipattern. Most of us are familiar with it as an antipattern, where someone “takes one for the team” and essentially does someone else’s job because that other person isn’t doing it. (We discussed this in great detail at last year’s St. Louis Collaboratory workshop.) (LQ1)

When it’s a result of broken trust, Sacrificial Lamb is short-term positive, because the job gets done, but it’s long-term negative because it hurts your working chemistry and often overloads your most productive team members. When it’s intentional and explicit, it’s net positive, because it’s not breaking any trust relationships. The essence of Jim and Neil’s pattern is that instead of dividing the necessary but dreary tasks among multiple peers, you designate one person as the Sacrificial Lamb and that person handles all of those tasks, at least for one cycle. You increase the likelihood of the tasks getting done and getting done well, and you increase the productivity of your other team members. If done right, the whole will be greater than the sum. The Knowledge Workers in the MGTaylor process are essentially Sacrificial Lambs. (LQ2)

The role of the Sacrificial Lamb is most often to maintain good Group Information Hygiene. Project managers will find this role familiar. For example, when scheduling meetings, you send frequent reminders, both to compensate for others who are not good at maintaining their own calendars and to correct potential miscommunications. These tasks are laborious, but they’re necessary for High-Performance Collaboration. (LQ3)

Collaboration can be a difficult thing to measure, but measuring Group Information Hygiene is relatively easy. I used metrics associated with Group Information Hygiene extensively with a client last year as one indication of the state of collaboration within the community and the potential for improvement in the future. Poor Group Information Hygiene is a natural obstacle to scale. (LQ4)