Saturday, December 22, 2012

Topsight > Using Topsight to teach a class

I developed Topsight for several audiences: consultants, people who want to change their organizations, people who need a gentle introduction to field research in organizations, graduate students. But in particular, I was thinking of my own undergraduate students in the course I often teach, Designing Text Ecologies.

The link goes to the spring 2013 version of the course. And I'm excited that I'll be using Topsight for that course. You can follow the link for the particulars, including the projects and the pacing. But if you're thinking about using Topsight for your own graduate or undergraduate course, here's a template for a 13-week course that might be helpful:

Week 1: Field studies and topsight (Preface, Ch.1)
Week 2: Developing a study design; building in protections (Ch.2-3)
Week 3: Gaining permission; preparing to study (Ch.4-5)
Week 4: Introducing yourself to participants (Ch.6)
Week 5: Observing; interviewing (Ch.7-8)
Week 6: Collecting artifacts and other sorts of data (Ch.9-10)
Week 7: Navigating data: triangulating and coding (Ch.11-12)
Week 8: Reporting progress: The interim report (Ch.13)
Week 9: Introduction to the analytical models; resource maps; handoff chains (Ch.14-16)
Week 10:Triangulation tables; breakdown tables (Ch.17-18)
Week 10: Activity systems and activity networks (Ch.19-20)
Week 11: Topsight tables; describing systemic issues (Ch.21-22)
Week 12: Turning findings into recommendations; writing the recommendation report (Ch.23-24)
Week 13: Turning recommendations into new solutions (Ch.25)

Topsight > I just looked at the proofs for the book...

... and I got excited all over again. I'm really thrilled that this book is coming together. Part of what I'll be doing over Christmas break is to go through the proofs and identify the final tweaks so that this book will be professional-grade.

Some of you have also contacted me in various ways—on Twitter, Facebook, Google Plus, email, and even face-to-face—to express interest. Thank you.

Although I hoped to get Topsight uploaded to Amazon CreateSpace by the end of 2012, it looks like it'll happen in early 2013 instead, due to some tweaks that still need to happen. It's this last mile—making sure the footers are right, watching out for widows and orphans, adjusting page breaks—that slows things down, but that also gives the book that finished, professional look.

In the meantime, I'll keep blogging and uploading content to the Topsight page. If you're interested in Topsight, please do keep watching this space—and if you know others who are interested, point them this way.

Topsight > Resource maps

One analytical construct that I discuss quite a lot in Topsight is something I call "resource maps." The name might be unfamiliar, but I've been discussing resource maps since 1997 under another name: "genre ecologies."

Why the name switch? "Genre ecologies" gets at the theoretical aspects that are important to academics. But they take a lot of explanation for non-academics. The concept of genre itself takes a lot of unpacking. But I've found that when I talk about mapping information resources, people can more easily grasp what's going on—and are sometimes more open to seeing unconventional or idiosyncratic resources as part of a system.

Let's take the classic example I use in my first book. Various people, in various locations, working in various organizations, all struggle when trying to use a text-based information system in conjunction with a street map. That's a classic usability problem, right? But a subset of people find ways to route around those problems. One copies down information onto a sticky note and keeps it in a folder. Another photocopies parts of his map. And so on. For these people, the information system doesn't have a usability problem, because they've successfully added an information resource that shores up the weaknesses of the current set of resources.

In some cases, these systems tend to standardize. For instance, in my second book, I describe how collections workers for a telecommunications company take a printout of people who are late on their payments, annotating it to turn it into both a checklist (who do I call next?) and a record (when I called this person, did I talk to them, leave voice mail, or what?). Even though these people all told me that they didn't learn this annotation system from anyone else, they were able to read and understand each others' checklists when necessary.

At the same time, these systems tend to have components that can be borrowed from anywhere—previous jobs, personal lives, other organizations, other domains—piled, sometimes haphazardly, in a heap of information resources. Since they come from different places, these information resources sometimes assume very different things and follow very different logics. And those mismatched resources sometimes develop disruptions.

Tracking these resources—again, not abstractly, but in the minute-by-minute, meso-level ways that they're used by actual people—can help you gain a detailed understanding of how complex the work is, how information flows around the organization, and where things go wrong. And it's a lot easier to track them if you map them out like this:
Here, each box represents an information resource that was actually observed during a field visit. The lines indicate points at which two or more information resources were observed being connected. For instance, if you see someone looking at his notebook when filling out a dialog box, you can connect them with a line. But if you never see him using the dialog box in conjunction with a folder, you don't.

Observation is crucial here. People connect information resources in a lot of different ways, including:

  • juxtaposition (two information resources attached to or overlapping each other)
  • placing (two information resources placed side by side, in a stack, or in regular places)
  • annotation (writing or altering an information resource)
  • transfer (using one information resource as source for filling in another)
  • modeling (using one information resource as a model for another)
  • reference (using one information resource to interpret or operate another)

And they don't always tell you about these connections. Some are too habitual, others seem too obvious (to them), and still others can seem petty or even embarrassing to them (few people will say that a sticky note is the linchpin of their work). But you need to be able to map them if you're going to gain topsight.

Resource maps and handoff chains are two important ways to analyze the minute-by-minute, meso-level interactions you'll observe in organizations, and I discuss them extensively in Topsight. They're two ways of looking at the same information resources. But they need to be connected. Soon, I'll discuss how to connect them.

Wednesday, December 19, 2012

Topsight > Handoff chains

As I wait for the production to finish on my new book Topsight, I've been discussing some of the analytical constructs that we can use to better understand aspects of work. Until now, I've been looking at macro-level constructs: activity systems and activity networks. These give us a "big picture" view of an organization and how it does what it does.

But a "big picture" view isn't topsight.

That point might seem counterintuitive. Isn't topsight an overall understanding of how the system works? Well, yes. But topsight is like insight: it takes a while to develop, and it develops inductively, over time, as you understand how the details interrelate. You have to actually get into the details—to understand how specific routines happen, over and over, and where they go wrong. You have to see these not just at the macro level of activity, but also at the meso level of action—the minute-by-minute interactions, the ways that people use tools and communicate information as they go about their daily work.

Topsight discusses three different analytical constructs to explore meso-level aspects of an organization. Today, we'll talk about handoff chains.

Think about handoff chains in this way. When we circulate information around an organization, we don't do it via telepathy. We have to hand it off. Sometimes that's a literal handoff: I physically hand you a memo, report, sticky note, or hard drive. Sometimes it's more metaphorical: I speak to you, post a message to the internal message board, or tweet about something. But in any case, we can usually identify a specific genre, cast in a specific material medium, that allows us to hand information from one person to another.

These handoffs happen so often, and sometimes seem so trivial, that we don't pay much attention to them. But watch them closely as they happen, examine the specific handoffs, and ask people about them afterwards, and you'll see patterns emerging. Patterns that might look like this:
Each arrow represents a handoff: a point at which one person materially provides information to another. Some of these handoffs seem trivial, others seem major. But each represents—or should represent—an actual, identifiable incident. That is, this isn't an idealized process; it's an actual set of instances that we can reconstruct directly from an actual observation.

That's really important. If you ask someone what their process is, they will generalize it, forgetting what they think are trivial steps, minimizing others, maximizing still others. They don't necessarily know what to pick out for you. If you see it, and especially if you see it over and over, you can build up a more concrete picture of the chain of handoffs that are necessary to make something happen. Maybe, for instance, that instant messaging is a critical part of the process but no one realizes it.

And maybe there's a pattern of disruptions. Maybe, as you look at handoff chain after handoff chain, you realize that certain parts of the chain are repeated over and over because they have to be reset. Structural miscommunications, lossy media, failure to get buy-in from all stakeholders, and who knows what else might be disrupting this communicative chain. When you put together a chain like this based on specific instances, not on generalizations and recollections, you start to see patterns that no one else might have spotted. And those patterns are also part of topsight.

If you've been reading my academic work or those of my collaborators, you may recognize that handoff chains are based on William Hart-Davidson's work with communicative event models. I've been very fortunate to work with Bill and with Mark Zachry to develop and extend the concept, and I'm excited that it's now in the conceptual toolkit of Topsight.

Now, I mentioned that handoff chains are one way to get at a meso-level understanding of an organization. There are two more, which I'll plan to discuss soon.

Tuesday, December 18, 2012

Topsight > How to cite Topsight

I'm behind on my blogging due to a big project I'm trying to wrap up this week (unrelated to Topsight). But I thought I'd address a question: How do you cite a self-published book?

It turns out that others have also wrestled with this question. It's complicated, because the book is self-published, but printed by CreateSpace. According to one thread from the Amazon CreateSpace message board, one cannot put down CreateSpace in the publisher spot, like this:
Hocking, Amanda. Fate: My Blood Approves. Charleston: CreateSpace, 2010.
At least, you can't in the book itself.

The citation above turns out to be the proper MLA format for citing a self-published book, more or less, so someone who wants to cite this book could actually use this format in their Works Cited page. In this version, the printer goes where the publisher would normally go. Chicago handles things similarly. (A quick Google search turns up no analogue for APA.)

But if you use it in the book itself, CreateSpace will insist that you turn it into one of these possible forms:

Hocking, Amanda. Fate: My Blood Approves. Charleston: Amanda Hocking, 2010.
Hocking, Amanda. Fate: My Blood Approves. n.p. Amanda Hocking, 2010.
Hocking, Amanda. Fate: My Blood Approves. n.p: n.p, 2010.
Hocking, Amanda. Fate: My Blood Approves. n.p: n.p., printed by CreateSpace,  2010.
So: How will you cite Topsight when it comes out? You might consider something like this:
Spinuzzi, C. (2012). Topsight: A guide to studying, diagnosing, and fixing information flow in organizations. Austin: CreateSpace.
Check your style guide for details.