We'll see | Matt Zimmerman

Like you, dear Internet readers, I have no shortage of reading material. I have ready access to more engaging, high quality, informative and relevant information than I can possibly digest. Every day, I have to choose what to read, and what to pass by. This seems like an important thing to do well, and I wonder if I do a good enough job of it. This is just one example of a larger breadth/depth problem, but I’m finding the general problem difficult to stomach, so I’m focusing on reading for the moment.

These are my primary sources of reading material on a day-to-day basis:

• Email – I read everything which is addressed to me personally. I don’t reply to all of it, and my reply time can vary greatly, but I am able to keep up with reading it, and I consider it important to do so. I am still subscribed to a selection of mailing lists, but I find them increasingly awkward to manage. There are a few which I scan on a daily basis, but most of them I process in batches when I’m offline and traveling. I’m subscribed to far fewer mailing lists than I was five years ago, though I feel they are still the most effective online discussion facility available. I find myself doing more and more discussing in real-time on IRC and by phone rather than by email.
• Blogs – I subscribe to a few big aggregators and a random sampling of individual blogs. Most of them I scan rather than read. I do most of this offline, while in transit, and so I don’t tend to follow links unless they’re promising enough to save for later. I’ve recently stopped trying to “keep up” (scan every post) on most of them, and instead just “sample” whatever is current at the time. It feels like turning on a television, flipping through all of the channels, and turning it off again. Even when I do find something which I feel is worth reading, it’s hard for me to focus my attention after a long session of scanning. I do find a lot of good stuff this way, but I’m pretty dissatisfied with the overall experience. I never feel like I’m looking in the right places.
• Shared links – I share my own links publicly, and follow those shared by friends and acquaintances. I do this with multiple groups of people who don’t connect directly, and pass items back and forth between those groups. I place an increasingly high priority on reading items which are shared by people I know, more than on trying to follow the original sources, because the signal-to-noise ratio is so good: my personal network acts as a pretty good filter for what will interest me. I have the nagging feeling that I need to maintain a balance here, though. If I read mostly what other people are sending me, I feel like I’m living in a bubble of like-minded people and fear that I’ll lose perspective.
• News – I read hardly any “proper” news. I don’t subscribe to any newspapers, and generally don’t read the online versions either. I do read articles which are shared by people in my network. Traditional media never seems to have the right scope for me. There may be particular journalists, or particular topics I’d like to follow, but news outlets simply don’t group their content in a way which fits my mind.
• Books – Remember these? My diet of books has shrunk drastically since I started reading more online media. Devoting my full attention to a book just doesn’t feel as energizing as it used to. I hesitate at the prospect of sinking so many hours into a book, only to decide that it wasn’t worthwhile, or worse, to forget what I learned as I’m bombarded by bite-sized, digestible tidbits from the Internet. I feel sad about losing the joy of reading I once had, and want to find a way to reintegrate books into my regular diet.

How do you decide what to read, and what not to read? How does your experience differ between your primary information sources? How have you tried to improve?

This is a repost from the ubuntu-devel mailing list, where there is probably some discussion happening by now.

After each UDS, the organizers evaluate the event and consider how it could be further improved in the future. As a result of this process, the format of UDS has evolved considerably, as it has grown from a smallish informal gathering to a highly structured matrix of hundreds of 45-to-60-minute sessions with sophisticated audiovisual facilities.

If you participated in UDS 10.10 (locally or online), you have hopefully already completed the online survey, which is an important part of this evaluation process.

A survey can’t tell the whole story, though, so I would also like to start a more free-form discussion here among Ubuntu developers as well. I have some thoughts I’d like to share, and I’m interested in your perspectives as well.

Purpose

The core purpose of UDS has always been to help Ubuntu developers to explore, refine and share their plans for the subsequent release. It has expanded over the years to include all kinds of contributors, not only developers, but the principle remains the same.

We arrive at UDS with goals, desires and ideas, and leave with a plan of action which guides our work for the rest of the cycle.

The status quo

UDS looks like this:

This screenshot is only 1600×1200, so there are another 5 columns off the right edge of the screen for a total of 18 rooms. With 7 time slots per day over 5 days, there are over 500 blocks in the schedule grid. 9 tracks are scattered over the grid. We produce hundreds of blueprints representing projects we would like to work on.

It is an impressive achievement to pull this event together every six months, and the organizers work very hard at it. We accomplish a great deal at every UDS, and should feel good about that. We must also constantly evaluate how well it is working, and make adjustments to accommodate growth and change in the project.

How did we get here?

(this is all from memory, but it should be sufficiently accurate to have this discussion)

In the beginning, before it was even called UDS, we worked from a rough agenda, adding items as they came up, and ticking them off as we finished talking about them. Ad hoc methods worked pretty well at this scale.

As the event grew, and we held more and more discussions in parallel, it was hard to keep track of who was where, and we started to run into contention. Ubuntu and Launchpad were planning their upcoming work together at the same time. One group would be discussing topic A, and find that they needed the participation of person X, who was already involved in another discussion on topic B. The A group would either block, or go ahead without the benefit of person X, neither of which was seen to be very effective. By the end of the week, everyone was mentally and physically exhausted, and many were ill.

As a result, we decided to adopt a schedule grid, and ensure that nobody was expected to be in two places at once. Our productivity depended on getting precisely the right people face to face to tackle the technical challenges we faced. This meant deciding in advance who should be present in each session, and laying out the schedule to satisfy these constraints. New sessions were being added all the time, so the UDS organizers would stay up late at night during the event, creating the schedule grid for the next day. In the morning, over breakfast, everyone would tell them about errors, and request revisions to the schedule. Revisions to the schedule were painful, because we had to re-check all of the constraints by hand.

So, in the geek spirit, we developed a program which would read in the constraints and generate an error-free schedule. The UDS organizers ran this at the end of each day during the event, checked it over, and posted it. In the morning, over breakfast, everyone would tell them about constraints they hadn’t been aware of, and request revisions to the schedule. Revisions to the schedule were painful, because a single changed constraint would completely rearrange the schedule. People found themselves running all over the place to different rooms throughout the day, as they were scheduled into many different meetings back-to-back.

At around this point, UDS had become too big, and had too many constraints, to plan on the fly (unconference style). We resolved to plan more in advance, and agree on the scheduling constraints ahead of time. We divided the event into tracks, and placed each track in its own room. Most participants could stay in one place throughout the day, taking part in a series of related meetings except where they were specifically needed in an adjacent track. We created the schedule through a combination of manual and automatic methods, so that scheduling constraints could be checked quickly, but a human could decide how to resolve conflicts. There was time to review the schedule before the start of the event, to identify and fix problems. Revisions to the schedule during the event were fewer and less painful. We added keynote presentations, to provide opportunities to communicate important information to everyone, and ease back into meetings after lunch. Everyone was still exhausted and/or ill, and tiredness took its toll on the quality of discussion, particularly toward the end of the week.

Concerns were raised that people weren’t participating enough, and might stay on in the same room passively when they might be better able to contribute to a different session happening elsewhere. As a result, the schedule was randomly rearranged so that related sessions would not be held in the same room, and everyone would get up and move at the end of each hour.

This brings us roughly to where things stand today.

Problems with the status quo

1. UDS is big and complex. Creating and maintaining the schedule is a lot of work in itself, and this large format requires a large venue, which in turn requires more planning and logistical work (not to mention cost). This is only worthwhile if we get proportionally more benefit out of the event itself.
2. UDS produces many more blueprints than we need for a cycle. While some of these represent an explicit decision not to pursue a project, most of them are set aside simply because we can’t fit them in. We have the capacity to implement over 100 blueprints per cycle, but we have *thousands* of blueprints registered today. We finished less than half of the blueprints we registered for 10.04. This means that we’re spending a lot of time at UDS talking about things which can’t get done that cycle (and may never get done).
3. UDS is (still) exhausting. While we should work hard, and a level of intensity helps to energize us, I think it’s a bit too much. Sessions later in the week are substantially more sluggish than early on, and don’t get the full benefit of the minds we’ve brought together. I believe that such an intense format does not suit the type of work being done at the event, which should be more creative and energetic.
4. The format of UDS is optimized for short discussions (as many as we can fit into the grid). This is good for many technical decisions, but does not lend itself as well to generating new ideas, deeply exploring a topic, building broad consensus or tackling “big picture” issues facing the project. These deeper problems sometimes require more time. They also benefit tremendously from face-to-face interaction, so UDS is our best opportunity to work on them, and we should take advantage of it.
5. UDS sessions aim for the minimum level of participation necessary, so that we can carry on many sessions in parallel: we ask, “who do we need in order to discuss this topic?” This is appropriate for many meetings. However, some would benefit greatly from broader participation, especially from multiple teams. We don’t always know in advance where a transformative idea will come from, and having more points of view represented would be valuable for many UDS topics.
6. UDS only happens once per cycle, but design and planning need to continue throughout the cycle. We can’t design everything up front, and there is a lot of information we don’t have at the beginning. We should aim to use our time at UDS to greatest effect, but also make time to continue this work during the development cycle. “design a little, build a little, test a little, fly a little”

Proposals

1. Concentrate on the projects we can complete in the upcoming cycle. If we aren’t going to have time to implement something until the next cycle, the blueprint can usually be deferred to the next cycle as well. By producing only moderately more blueprints than we need, we can reduce the complexity of the event, avoid waste, prepare better, and put most of our energy into the blueprints we intend to use in the near future.
2. Group related sessions into clusters, and work on them together, with a similar group of people. By switching context less often, we can more easily stay engaged, get less fatigued, and make meaningful connections between related topics.
3. Organize for cross-team participation, rather than dividing teams into tracks. A given session may relate to a Desktop Edition feature, but depends on contributions from more than just the Desktop Team. There is a lot of design going on at UDS outside of the “Design” track. By working together to achieve common goals, we can more easily anticipate problems, benefit from diverse points of view, and help each other more throughout the cycle.
4. Build in opportunities to work on deeper problems, during longer blocks of time. As a platform, Ubuntu exists within a complex ecosystem, and we need to spend time together understanding where we are and where we are going. As a project, we have grown rapidly, and need to regularly evaluate how we are working and how we can improve. This means considering more than just blueprints, and sometimes taking more than an hour to cover a topic.

I make a lot of lists: lists of things to do, things to talk to someone about, things to write, and mistakes never to repeat. I use them to keep track of various aspects of my life, and to help me to “shift gears” to a new task or project by filling my mind with the work at hand.

List-keeping is generally regarded as boring administrative work, something only important to compulsive organizers. When a writer wants to portray a character as meticulous and dull, they need only brand them as a list-maker, with eyes bespectacled from years of squinting over their lists.

The reality of list-keeping is much more exciting: reminder lists are a mechanism for cognitive time travel. They allow us to transport information from the time when it occurs to us, to a time in the future when it will actually be useful. Like a wormhole, they connect distant points in spacetime (though unfortunately only in one direction, as in the Stargate universe).

Throughout my day, I will remember things I need to do, though not right away: an article which looks interesting, or someone I need to remember to call. Putting these items on a list frees my mind to keep going with whatever I’m doing, knowing that the idea is not lost. A common scenario for me is that I’m riding the tube, reading RSS feeds offline on my Android phone using NewsRob, and come across something I want to explore further. There is as yet no wireless service on the tube, so I can’t do anything but read, but I can send myself an email using K-9 which will be delivered later. At the other end of the wormhole, when I’m back online, I receive the email (usually at my computer) and pick up where I left off.

Traveling through time in your head may not be as exciting as flitting about in a TARDIS, but it is much more accessible, and genuinely rewarding.

Morning Session: Project Patterns

I chose to attend a session entitled: Is this the Way We Really Want to do Things? Seeing Project Patterns and Changing What You Don’t Like (Johanna Rothman). My goal was to explore the causes of the troublesome patterns I see in projects at work. In particular, I see:

• Too many projects starting up at once
• Projects being instantiated without enough consideration for the probability of success (“is this a good idea?” rather than “can we realistically achieve this?”)
• Key people finding out too late about projects which affect them

All of these patterns lead to increased project risk, communication bottlenecks, low motivation, and high stress.

In the session, we conducted a simulation of a team, with engineers, a project manager, a senior manager and a customer. I took on the role of the senior manager.

In the course of the simulation, we received requirements from the customer, implemented them, and delivered products. While the team was working on implementation, I talked with the customer about what was coming next: what would happen when we delivered, what the next project would be, and so on. Part of the simulation was that I had to be separated from the group while they were working.

When we delivered the first batch of products, and the customer was happy with them, it was time to decide what to do next. We gave the customer a choice of two projects we had discussed, one of which was similar to the previous one (but larger scale and more involved), while the other was different. Despite repeated attempts, we could not persuade the customer to prioritize one over the other.

So, I decided that we should change gears and start work on the “different” project. It seemed to be of greater economic value to the customer, and simpler to execute. One of the engineers disagreed with this decision, but didn’t explain why. The project manager seemed to agree, and I left the team to work. They produced a prototype, which the customer liked, and with a few small changes it was accepted as a finished product.

To my surprise, though, I found out later that the team was in fact working on both projects at once, delivering two different types of products. The decision hadn’t actually been made. These unexpected products were delivered to the customer, but didn’t meet the expanded requirements, and that work was wasted.

The debrief which followed was unfortunately too short, and I didn’t feel that we were able to fully explore what the simulation had revealed. The project manager indicated that he hadn’t understood the decision to have been made, pointing to a communication failure.

This reminded me that while we often think of a decision as an event which happens at a point in time, it is more commonly a process of change, which takes time and must be revisited in order to check progress and evaluate. A decision is really just an idea for a change, and there is more work to be done in order to implement that idea. This can be true even when there is a very explicit “decision point”: it still takes time for that message to be received, interpreted and accepted.

One of the tangents we followed during the debrief had to do with how humans think about numbers. Jerry asked each member of the group to write down a random number, and then we wrote them all on a flipchart. They were: 8, 75, 47, 72, 45, 44, 32, 6, 13 and 47. This reminded me of the analyses of election results which indicate fraud.

Afternoon Session: Saying No

After lunch, I decided to attend Jerry Weinberg’s session, Saying No That Really Means No. This was much larger than the morning session, with over 40 people sitting in a large circle.

The subject of discussion was the variety of difficulties that people face in saying “no” to things which don’t seem right for them. For example, saying “yes” to a project which is doomed to failure. This seemed like a good follow-on to the morning’s exercise.

Jerry began by asking the audience to name some of their difficulties, and tell stories of times when they had trouble saying “no”. One of these stories was role-played and analyzed as an example. Most of the time, though, was filled with storytelling and discussion.

This is a deeply complex topic, because this problem is rooted in self-image, social norms, egocentrism, misperception, and other cognitive phenomena. There was no key insight for me, just a reinforcement of the necessity of self-awareness. The only way to avoid patterns like this is to notice when they are happening, and that can be challenging, especially in a stressful situation.

Once you realize what’s happening, there are all sorts of tools which can be applied to the problem: negotiation, requests for help, problem-solving, even simple inaction.

The AYE conference is an annual conference “designed to increase your effectiveness—in leadership, coaching, managing, influencing, and working in teams, whether you work in systems development, testing, product development, quality assurance, customer service, or consulting.” It starts tomorrow, and I’ve arrived today eager to meet the other attendees and see what the conference is like.

My work involves all of those things, but the main reason I decided to attend was that I learned a lot at the Problem Solving Leadership workshop, which I attended in January and wrote about on this blog. When I heard about this event, organized in part by the same people, and realized I would be in the US that week anyway, I seized the opportunity to attend.

The 2009 program is overflowing with sessions on topics I’m interested in, some of which I have written about here previously.

The speakers are all people whose insight I’ve appreciated through their writing, speaking and teaching, so I expect I’ll have a tough time deciding where to spend my time these next few days. The sessions are said to be experiential ones rather than lectures, so I don’t think that I’ll be able to hop between them, but I’ll see tomorrow when the main program starts.

At any given moment, I have a set of open problems in my life. On my good days, I’m working on the most important one, aiming to solve it as quickly as possible. Otherwise, my most important problem is that I’m not working on my most important problem!

From time to time, I manage to solve a problem, and can remove it from the list. As a side effect, my #2 problem “gets a promotion” and becomes #1 (thanks to Jerry Weinberg for this analogy).

The problem at the top of the list, by virtue of being a focal point, can easily seem bigger than it is. As humans, we normalize our point of view based on what is happening to us. If we apply conventional productivity wisdom and focus exclusively on our most important task, that task consumes all of our attention. Being constantly in this state can be very productive, but also create a problem orientation. I experience this as a feeling that I am constantly surrounded by problems and never “catch up”.

At times like this (if I’m aware and realize that it’s happening), these are some of the things that help me recenter myself:

• Devote some attention to reviewing what I’ve accomplished recently, to remind myself of progress
• Ask myself if my #1 problem is actually urgent, or if I’m just on a roll. If it’s not urgent, consider taking a break from problem-solving and work on something else important for a while
• Give away some problems that I’m holding onto but don’t need to own
• Remind myself that this feeling as a side effect of where I focus my attention, and I can therefore influence it
• Laugh

Like many people who work from home, I use the same computer for both “work” and “personal” activity. This has many benefits, including lower cost, more efficient use of space, and reduced configuration maintenance.

The main drawback of this arrangement is that it’s easy to get drawn into the wrong context.  This is especially true in a company like Canonical, where there are people working at all hours around the world, communicating with each other on common IRC channels.  If I see work-related conversations on IRC after hours, it’s easy to slip into “work mode” and start thinking about what’s being discussed, or even responding.

Similarly, if I look at my work inbox, my brain goes on autopilot and I start processing email even if I was doing something else before.  This habit serves me well during the work day, when I can process a lot of email in the time between appointments, but in the evenings and at weekends, it’s a distraction.

Recently, I made a small change to my mail reader configuration to try to address this problem.  If I launch mutt “off hours”, it uses a different default inbox than during “working hours”.  These are of course approximate, but since both my personal and work inboxes are in the search path, it’s not a big deal if it guesses wrong. It generally only needs to be correct at the start of a session. Sometimes, it’s just the nudge I need to remind me to switch contexts.

set spoolfile = `case $(date +%u-%H) in \
    [1-5]-0?|[1-5]-1[0-7]) echo +incoming.canonical.INBOX ;; \
    *) echo +incoming.INBOX ;; \
    esac`

When talking about email, I hear anecdotes from people using the “delete” key to progress through reading their inbox.  Presumably, this instructs their mail reader to delete the messages.  Permanently.  It makes me shiver each time I hear it.

Why on earth would someone do this?

An email that you have processed (read or replied to) isn’t trash.  It is reference material.  It is history.  It is information which has been (in part) absorbed by your brain, and at least seemed important enough that you looked at it in the first place.  Unlike many other forms of person-to-person communication we receive and process on a daily basis, it is digital.  This means that it can be copied and stored forever without losing any information.

I’ve been saving virtually every (legitimate) email that I receive for some years now.  When I’ve finished with a message, mutt automatically saves it to an archival folder without me having to do anything.  It’s actually less work than deleting it (which requires a keypress).  I only delete spam and other content which is truly useless to me.  This adds up to under a gigabyte of storage per year.  A few dollars worth of hard drive space is sufficient to hold all of it.

Every day, I refer back to messages I’ve read.  I refer to more recent messages more frequently, but go back three months or more on a regular basis, to refresh my memory, to pick up on an old topic, or to provide context to someone who is joining a discussion.  It is bewildering to me that this information is thrown away by so many people.

I also don’t ever have to decide whether something is worth saving or not, and this helps me process email faster.  I can relax, knowing that I can always find it again if I need it.

So, why do you delete your email?  Is this a by-product of using your inbox for archival, where anything which might be useful stays there forever?  Is it just the simplest way to put the information aside when it no longer seems important at the moment?  Do any modern mail readers lack the capability to archive messages for you?  Do they not make it easy enough?  Is it a habit which transferred from paper mail, where storing it is impractical for most people?

I know that I have too much on my mind when:

1. I have a brilliant idea
2. I realize that I can’t do anything with it right now
3. I realize that if I don’t record it, I will lose it, because I have a lot to think about
4. I consider creating a list of ideas to come back to later
5. I notice that I have already done this (and forgotten about it)
6. I open the list, and notice that the idea I just had is already on it
7. It has been there for a year
8. This is not the first time this has happened

I’ve been thinking lately that I need to put some energy into organizing my life better, and this is a good example of why.  I am flooded with information, creative ideas, desires, and responsibilities through my work, study, home life and reflection.  I have no illusions about being able to fully honor all of these: that is clearly impossible.  However, I instinctively feel that I could do a much better job of sorting and prioritizing them to maximize my personal effectiveness and satisfaction.

I am a great fan of keeping lists: to-do lists, agendas, my inbox, journals, and other tools all serve to help me capture my thoughts and consider them in a larger context.  Rather than reacting to them one by one, I can look at all of them together and make a conscious choice about what to do right now.  List-keeping is one of the most basic strategies of personal organization, and practicing it has made a dramatic difference in my life.

However, I can see that it is no longer sufficient, and that in order to continue to improve, I will need something more powerful.  I’m not looking for a new list management tool: Remember the Milk, Futz, Tomboy, Jott, and many others provide highly optimized list-keeping facilities.  I don’t use any of them myself (being a text file junkie), but they look great, and offer the right tradeoffs for different people.  My method list-keeping is good enough for me, for now.  Rather, list-keeping is not enough.

Similarly, scheduling has been a successful strategy for me, helping me to decide how I spend my time.  I am not as proficient in scheduling as I am in list-keeping, but I understand the basics and apply them.

What I need is a new paradigm, a new way of thinking about this problem which incorporates and transcends list-keeping and scheduling, and addresses their shortcomings.  I’ve only just begun to research this area, and so far, the most relevant material I’ve found has come from Stephen Covey’s classic text The 7 Habits of Highly Effective People.  “Habit 3″ describes a historical progression of time management tools and approaches which resonates with my personal experience, and prescribes next steps to improve upon it.  I’m not sure yet whether it’s the right direction for me, but here is what I think so far.

Things I like about it:

• Explicit recognition of the various roles I occupy in my life
• Helping to balance priorities across different roles
• Promoting preventative and growth activities, in balance with day-to-day progress

Things which I feel are missing:

• Simplicity: It seems like a lot of bookkeeping, compared to how I’m used to doing things.  I want a system which is as lightweight as possible, because organizational tools which create friction are self-defeating.
• Feedback: I want a mechanism which helps me to regularly evaluate what I’ve done and improve upon it.  This should be as easy and automatic as possible, without requiring too much time tracking and data entry
• Technology: As a technologist, I’m always looking for ways to bring the latest technology to bear on my problems, to make me more efficient.  Covey’s approach was designed without the benefit of the past 20 years of Internet revolution, and the software which is based on it seems a bit dry and monolithic.

Dear readers, do you find yourselves in a similar position?  What are you using to manage your life?  What else did you try?  What was good or bad about it?