Millions of Tiny Transactions

Work  Breakdown

A key principle of lean manufacturing is creating smaller batches, ideally, batches of one unit. It reduces inventory and enables a greater degree of customization.

The same thing has been happening to a lot of information work. Think about it. You get an email for which you need to provide a quick response. You have somewhere between five and a dozen (or more) active projects going simultaneously for which you are working on one or more deliverables. Emails and to-do’s are piled together in your inbox, each of which is one separate transaction, often small but still requiring time, focus, and a response.

Many companies use workflow management tools to track cases or open issues and to route information through the right people to make decisions. In fact, Microsoft Outlook tasks can be used for a lightweight version of this approach. They are all tiny transactions often piled together that will, hopefully, be recombined when finished into a useful larger deliverable.

What is the result? The intended result is getting more work through the pipeline by breaking it up. (That’s the lean piece of the puzzle.) Quite often, though, the result can end up being a lack of context to the performer. Each task is just a thing to do, disconnected from the larger picture of the project. To build that larger picture requires that you to stop and think about the overall intent of the project and where this task fits, what is important about it, what you need to actually do, etc. That “spin-up” thinking is the inefficiency that exists with multi-tasking…it is that all-too-familiar question “so, what are we trying to do here?”

Several years ago (more than twenty) I was talking to an engineer at a telecommunications company who made the comment comparing a previous job as a circuit design engineer to working in a closet where someone feeds a spec in on one side, they design the circuit, and then hand-off the design information to someone outside the closet. The engineer had no idea what the circuit was for, what the product was, what was important from a design standpoint…he was just expected to do the task as specified. It contained the work but left no room for interpretation or innovation. (Which was the intention but maybe not the overall best thing.)

What I’m wondering is, are we all moving in this direction in the name of productivity but actually making things worse? We often have so many things going on that we keep breaking things down to smaller chunks so we can move a task forward (and out of our inbox). At some point people get so overloaded that all they want to do is get rid of the task. How can you tell when this is going on? Some indicators might include

• You send an email to a co-worker containing two questions and the recipient answers part of the first one. They apparently didn’t realize there was more (since they didn’t mention it or follow-up later with the rest of the answer).
• You get on a web (or join an in-person) meeting and nobody has prepared. They feel like the best they can do is get there on time (or close to it). You try to begin the meeting and people want to re-discuss issues that had already been resolved in prior meeting because they didn’t remember.
• You forget to do something because it wasn’t on your list and you don’t even try to remember things anymore…
• …Or, you spend lot’s of time scrolling through your list (or email in-box) looking at the mass of items but not zeroing in on any specific items to complete because each item looks too hard or that it will take too long or it will just open a can of worms or…<insert your favorite demotivator here>.
• A project you are working on gets delayed and you don’t really ask why…you are just relieved.
• Your primary criteria for the right way to perform a task is whether it is the fastest, or maybe most expedient, one. You resist meeting to review things because it might mean that you end up with changes…that you aren’t all the way finished with something that you were thinking (hoping) you were already finished with.

Building Instructional Objects

With lean manufacturing, the small batch method works because the process is constant. With many jobs and projects though, the process varies. The context varies. The output varies.

When we are in a process or training design/development project, we use an object-based design model and it works great for us. It shows us all the pieces we need to build. It enables us to find things that can be created quickly and early. It helps us identify the “chunks” that will require extra work and time (so we can resource them accordingly). Sometimes there are availability challenges with SMEs or content source material or just decisions that mean we can start part of the work but have to wait for some other parts. In those cases, we would push the objects that can be built now to early in the process and defer the others.

But, there are often challenges for other people on the project who aren’t as familiar with the object approach. Reviewers aren’t always comfortable just reviewing a slice of a module…they have difficulty just reviewing the object for accuracy because they want to understand the big picture (that is, what comes before the object, what comes after). They may want to talk about objects that are on someone else’s list because they feel like it is important prerequisite information to their piece. (Which it is…just not their problem.)

And remember the “spin-up” problem? Other project participants have to “spin up” to address a single object as, to them, it risks being one of those context-less to do’s in their large pile of to do’s spanning multiple projects. When they grab it to complete it, they have to go through the “what are we doing again?” process before they can complete it.

We have been trying to address this issue in a few ways but certainly don’t have all the answers. One way is to remember that people always need context to perform a task well — so, when we ask for info, we include a brief summary of what it is needed for, what has preceded it, what will follow it. We do this in meetings too, for the same reasons. People need to get oriented before they can focus.

We have also been trying to keep emails to a single question or issue. That way things are less likely to get lost in the paragraph that follows because the person didn’t scroll down (or was doing a quick “read and reply” from a mobile device). Also, if you are one of those people that uses their email inbox as a to do list (which we definitely do NOT recommend) this can help you remove items when they are done and you don’t have the problem of what to do with one that is partially completed.

In the “old days” (the late 80’s and 90’s) we would hold longer meetings to focus on and make process and design decisions. These workshops may be harder to schedule at first but, if you can pull it off, a surprising amount can get done in a concentrated one- or two-day workshop. You do have to be careful that people really commit. Otherwise, people are ducking out for conference calls or other meetings and you can seriously lose momentum. Still, this approach has now become unusual enough that some clients find it appealing.

In fact, there are some cases where we’ve used a “war room” approach which is an expanded workshop that puts everyone in the room for maybe three to five days to actually hammer through, not only decisions, but building content and exercises. It can work if you prepare and get the needed people and commitment. The continuity benefits are huge and it compresses the calendar significantly. But, there is always the risk that somebody will want to “pop-in” via web-meeting at some specific time and expect everyone else to stop what they are doing, bring them up to speed, and then focus on their issues. Usually meetings like this rely on paper so it can be really difficult to make it even comprehend-able via a web interface. Even if all they want to do is listen in, chances are they will not be able to hear or follow the discussions and conclusions. We recommended that it is a better use of their time to review the output but when we’ve had to accommodate these challenges, we posted pictures or PDFs of the meeting flipcharts. This can help but, if you can avoid the whole problem, it is better to avoid it.

Beyond Tiny Transactions

There are several new tools now that try to use collaboration to get everyone’s input on a shared deliverable. This may be a reaction to the challenges of “tiny transactions” but it might also be just an extension of web technology. (Or, it could be both.) Rather than making one person coordinate all the disparate inputs from team members, you post some starter version of the deliverable (document, program, video, or whatever) on a shared workspace like Google Docs, Microsoft Office 365, Hightail, or the most recent offering from Dropbox (Paper). Then everyone pops in and adds their comments, contributions, questions, and ideas. And, the primary author can comment on their additions or even request input from specific people if needed.

These sound good in theory but I would like to see some real examples. When we’ve tried it, we find that most of our team members prefer to just use email and attachments. Maybe it is because it is a new way of working and people aren’t used to operating this way. But, that is not likely the real flaw in the approach. Any approach that depends on people being proactive in getting their input into a deliverable is likely to end up going without the input of several people (or, best case, getting that input late and only after a fair amount of prodding).  Comments can also often be useless. We’ve all seen reviewers who write comments like “unclear” or “needs to ‘pop’ more” or “more on this.”  You end up doing your best to figure it out but, when it comes to review inputs, it is infinitely better to get specific changes than general reactions. In this scenario, there will probably need to be a phone call or meeting anyway to clarify and negotiate specifics.

Does Productivity Always Mean More/Faster?

Productivity generally assumes you want to increase the output relative to the cost/effort. Usually, it entails doing the task in question more quickly (which is often referred to as “throughput”). But maybe that should change. Maybe the real key is not to focus on productivity, or else to change our view of productivity to incorporate other measures. Just as manufacturing went from volume to focus on quality measures (because, what good is it to produce 1,000 units of something if a lot of it ends up as scrap?), we could look at information work to determine which deliverables really generate value for the end user. It might even mean that going slower will produce better results. We already have plenty of outputs but there is rarely an oversupply of good ones.

And, even if we want to do more faster, the benefit of breaking things into increasingly smaller increments must eventually reach a point of diminishing returns…some would say we, as a culture, have already passed it. Have we reached the point where we should try to just do less but better?