Dave’s Whiteboard

Series: Managing the White Space

When Rummler and Brache look at the organizational level of performance, they have a bias.  An organization is a system, with inputs that it processes to produce outputs.  And an organization is made up of systems — at every level, you can (or should) identify the inputs, processes, and outputs that occur.

The organizational must develop goals, design functions, and manage performance in order to succeed.

We know that organizations don’t collapse immediately — some, like General Motors, keep lumbering along almost on sheer inertia.  Without those strategic goals at the organizational level, the functional areas will come up with goals of their own — goals that work for them, but perhaps not for the organization as a whole.

When I went to work for GE Information Services, the company’s main business was “remote computer timesharing” — providing mainframe-based computing power to a range of customers.  I learned that we had two main groups — the Mark III service, running on a proprietary operating system on Honeywell computers, and the Mark 3000 service, running on IBM mainframes.

There was endless rivalry between the two groups.  Mark 3000 began as an effort to serve customers insisting on IBM compatibility.  GEIS had been in business for a long time, though, and had powerful capabilities on the Mark III service.  Tech folks were certain they could deliver high-quality service without any need for IBM mainframes.

Sometimes this led not to creative competition but to the groups working at cross-purposes.  An overemphasis on the mainframe (or on two different mainframe worlds) led the company for a time to overlook a transformation in the marketplace — the personal computer.

I remember Talmudic debates about “3270 simulation” versus “3270 emulation” — ways to make a PC act like a mainframe terminal.  I also remember people scoffing at early efforts to create user-friend, PC-based front ends to mainframe systems.  The attitude seemed to be, “They oughta wanna learn the commands.”

I see the Mark III and Mark 3000 fuctions as a digital version of manufacturing lines, like “desktop” and “laptop,” or “sedan” and “pickup truck.”  Their decisions didn’t seem to incorporate much information from marketing or sales (sales tended to see itself as an order-taker, renewing contracts that had been renewed many times before), nor from customers, nor from technological areas outside the company.

Rummler and Brache:

When the focus is placed on the internal and external customer-supplier relationships, the standard organization chart becomes less important.  However, the reporting hierarchy can facilitate or impede the flow of work.

To take another example: early in my career, I was an Amtrak ticket agent in Detroit.  After a rocky start, Amtrak began putting new passenger cars into service, replacing a “legacy fleet” that looked as though it had been purchases at the railroad version of a flea market.

Area management arranged for some first-class service on the Detroit-Chicago line.  As with the airlines, first class was more comfortable, less crowded, with more attentive service.  Unfortunately, it was more than double the coach price.

Marketing insisted that the ticket agents ask each coach passenger “coach or first class?”  The goal was to promote the service (and, I suppose, enhance revenue).  The reality is that the only people willing to pay more than double the rail fare were rail buffs — and very few of them were taking the five-and-a-half-hour trip to Chicago.

The net effect of this was to slow down ticketing, as agents went though explanations for people who ended up saying, “For twice as much money?  No way!”

The point isn’t that first class was a dumb idea — it was, and is, very popular in high-volume areas like the New York - Washington route.  But on a six-hour trip where the speed never went over 60, and often fell below 40, the value proposition seemed much more proposition than value.

And training — as in, “selling skills for ticket agents,” say, or “providing superior first-class service” for onboard employees — was not going to change that basic fact.

“Input, then and now” photo by Ian-S.
Train ticket photo by karenkuo / Karen Kuo.

In Five Seasons: A Baseball Companion, Roger Angell muses on hitting versus pitching.

There are a few dugout flannelmouths… who can talk convincingly about the art of hitting, but, like most arts, it does not in the end seem communicable.  Pitching is different.  it is a craft… and is thus within reach.

Art and craft… I recently started a project with oceans of content (technical categories for property locations, government standards, arcane private-sector terminology).  After conversations with experienced trainers, I’m mulling over possible measures of competence. And what level of competence matters in a given situation?

Somehow this overlaps with frustrations I’ve felt working with Google Documents.

I write a lot.  I’ve been typing since I was eleven (learning how was easier than improving my penmanship), and I’ve used word processors since WordStar*.  With Microsoft Word, I often use relatively obscure features — multiple document templates, macros, customized sequence codes, and especially the outline mode.

So I might be a power user, though I’m sure there are many people with far more power.

I don’t think most people want to be power users.  In fact, that’s almost always a goal you choose for yourself: something about a particular tool entices you, and you become better and better with it.

In formal training sessions and in on-the-job coaching, I see a much more desire to be a powered user.  People want something more than mere competence in the sense of “doesn’t make dumb mistakes.” People at work like to get things done efficiently and effectively, but they don’t want to get all wrapped up in technique or technology.

I’m talking about a range of behavior, but in an all-things-being-equal sense, the power user:

• Gets satisfaction from technique
• Has a long time horizon
• Values depth of knowledge

Obviously, the power user can produce exemplary results.  I think there’s a tendency, though, for a power user to look inward: the how of the process, rather than the what of the output.

In a similar oversimplified view, the powered user:

• Finds satisfaction in completing a task well
• Has a short- to mid-term time horizon
• Values range of knowledge

As I work with others on my new project, I’m trying to lean more toward powered than power.  When it comes to creating documents, I can contribute a lot because of my experience with Word — but I have to keep in mind that the goal is to collaborate effectively on documents.  That means a  pet shortcut in Word just isn’t worth trying to sell to others… not unless they’d feel more powered.

* If you’ve never seen WordStar, here’s a blog post (written in Catalan, I think) with a great, click-to-enlarge screen shot.

My colleague John Howe makes a useful distinction between subject-matter expert and exemplary performer.

Subject-matter experts are often supervisors or specialists who don’t currently do the job for which they’re considered experts.  Exemplary performers (exemplars), by contrast, do do that job, and are recognized as exemplary by peers and by management.

In real life, management sometimes calls an exemplar a subject-matter expert.  I don’t argue, but I tend to be on my guard.  The very term “subject-matter expert” hints at a subject — a body of knowledge that’s out there, somewhere, one that someone’s going to assimilate.  Or get assimilated by.

If you’re developing training when there are few straightforward answers — the kind of work that concept workers engage in — exemplars are an invaluable resource.

The key is to work with them to focus on challenging, real-life problems that are important or occur frequently.

In other words:

• Have them identify (and justify) those high-value situations; don’t ask them “what subjects should we include?”
• Focus on how to apply skill, not on the subject matter.
• Ask the exemplars to apply existing procedures and rules to realistic problems; don’t assume that the stated approaches are either correct or complete.

At a government agency, John and I worked with exemplars to develop training for a newcomer who’d just taken over a project.  They described criteria that should apply to certain kinds of decisions.  Then, we asked them to work through similar decisions they’d actually made.

This process almost always reveals “criteria” that no one uses.  It also tends to reveal different but acceptable approaches: a lot of surprises and quite a bit of “yes, that makes sense, and that would work.”  Those discussions also produced finer-grained criteria or considerations.

One caution: as John points out, problems that exemplars find interesting are often peripheral.  They don’t happen often, and so stand out.  Thus the need for grounding: “Is this the kind of problem that the (newcomer, in this case) is likely to face?  Is it one that’s important in the first 6 - 12 months?”

We built several case-based workshops on some aspect of taking up a new project: how to avoid micromanaging, how to deal with requests for information (a potential time sink), how to evaluate budget proposals.

Starting from basic principles and background material, each participant created his own response to a case, then compared that with those of teammates.  Teams developed and reported a group response.  Finally, a pair of exemplars (who worked the same cases during the workshop) shared their responses.  Most cases involved more than one round of individual and group work.

When there’s no single right answer, you need to work with principles and rules of thumb.  You need to compare your judgment with that of others and to reflect on the differences.  And you need to do these things more than once.

So the workshops gave new project managers limited but concentrated practice in solving high-value challenges that appear randomly during the first year on the job.  The “school solutions” were created by exemplars, not by instructional designers.

There’s no easy way to do this, but the results can be… exemplary.

“Borg baby” photo (it’s just a hearing test) by hikingviking.
Hotel Borg photo by bods / Andrew Bowden.

Tony Karrer wrote about concept workers the other day. He finds the term “knowledge worker” an adequate — people in a call center and engineers in R&D are all called knowledge workers.

So he’s using a term from Daniel Pink: concept worker. Says Tony, “It’s all about how easy it is to obtain the answers. The harder it is, the more conceptual.”

As I commented on his post, sometimes answers are hard to find because the organization has lost them in a “knowledge warehouse” from which Indiana Jones couldn’t retrieve them. Or, because the organization’s processes actively work against retrieving knowledge.

In other words, “hard to find” answers aren’t necessarily the conceptual ones. A member of my team at Amtrak spent close to a month veifying that, ten years into its existence, the company used the term “exchanging a ticket” but had no procedure for doing so. People in different locations either followed what the previous passenger railroad had done, or made up stuff, or told passengers it couldn’t be done. That’s not knowledge work; it’s Evening at the Improv.

To me, the core issue is whether you can find a specific solution to a problem. Sometimes, there is a right way to do things. Safety, legislation, regulation, process validation may constrain how far you can vary. When a pharmaceutical company calibrates a scale used to weigh dosages, they don’t want you casually coming up with new ways to calibrate. Neither do the people taking the drugs.

More often, especially in more complex settings, there isn’t one right way to address a problem, so you have to create one. The more your job calls for creating such solutions, the more it involves “concept work.”

I see another angle as well — a kind of informal validation. Would exemplary performers agree that the solution you came up with is a good way to resolve the problem — even if it’s not one those exemplars would have come up with?

Thanks to my colleague John Howe, I’m a big believer in the value of involving exemplary performers when you’re designing training (or facilitating learning) for higher-level, non-procedural jobs. I’ve written about exemplars before. Later this week, an example of working to uncover solutions about which exemplars say (approvingly), “Yeah, that works.”

Warehouse photo by *spo0ky*.

I’m not foolish enough to try and improve on Cathy Moore, whose Too Basic? Chop It! needed only 273 words.  (And “duh” accounts for 5 of them.)

I cracked up reading one part, which reminded me of a certain type of “subject-matter expert” fretting about leaving out important information:

But what about the two people who don’t know what “email” is?