Dave’s Whiteboard

Series: Managing the White Space

In my leisurely amble through Rummler and Brache’s Improving Performance, John Cleese keeps intruding.  Cleese made training films, including the classic Meetings, Bloody Meetings, with the immortal line, “You don’t do work in meetings — you just meet.”

(The movie title links to a preview; fast forward to about 2:40 to skip the intro.)

Rummler and Brache, looking at the process level of the organization, say that processes (like meetings or the Energizer bunny) just keep going.  “In our experience, most processes do not have goals,” they say, which makes it hard to align goals with those at the organizational level.

If the organization chart is a vertical view, a process chart is a horizontal one.  And while a few processes exist entirely within one functional area, most extend across those areas: they span the white space on the org chart.

Rummler and Brache apparently developed the swimlane version of a process chart, with horizontal rows for the functions, like lanes in a swimming pool.  Here’s a simple example from this article (pdf) by Ken Orr of the Cutter Consortium.  (Click to enlarge the chart.)

Even this “straightforward order fulfillment process” involves a credit manager, a sales manager, the shop, accounting, and customer service — and, of course, the customer.

We fall easily into the habit of confusing a process with a group that has the same name.  If it’s the marketing process, then it must be Marketing’s responsibility.  And obviously if it’s the sales process, then Sales is in charge.

Rummler and Brache recommend “as is” charts as a tool for breaking through functional walls. They’re talking about process maps that show what groups take part in a process.

“All too often, a team finds that there isn’t an established process;
the work just somehow gets done.”

(Which takes some of the shine off “organization,” doesn’t it?)

Like behavior, process is a verb: it’s what’s happening.  Output is a noun: it’s the result of the process.  It’s vital, Rummler and Brache content, to make sure the process has goals, and that the goals align with those of the organization.

Process effectiveness and efficiency should drive a multitude of business decisions.  For example, a reorganization serves no purpose if it doesn’t improve process performance.  Jobs should be designed so that people can best contribute to process outputs.  Automation is a waste of money if it calcifies an illogical process.

The authors contend that the process level is the least understood (and therefore the least managed) level of performance.  “Viewing business issues from a process perspective often reveals a need to make radical changes in goals, in the design of business systems, and in management practices.”

If nothing else, a look at the business section of the paper might nudge you toward re-examining the organization you work with.

Email this post

Someone (on Twitter, probably) pointed to Tim O’Reilly explaining Why I Love Twitter. Well worth reading for his viewpoints, including:

• Twitter works like people do: you don’t have to ask permission, you don’t have to become friends.
• Twitter is about quick hits, not extended discussion.
• Twitter transcends the web — it moves easily to different interfaces, even to different devices.

Browsing the comments, I found further thoughts from O’Reilly — not about Twitter but rather the larger sphere of open source. You can find them at the post I link to above, but I’m reproducing one chunk of his thinking here.

He underscores something worth holding on to: rather than looking back (like “replacing X”), work on looking forward (”accomplishing Y”).

If you’ve followed my career as an open source advocate, you should have noted that I’ve always had mixed feelings about free and open source projects whose goal was primarily to create an open version of something else. I feel this way about the GNU vision, projects like the Gimp, and every other free software that’s “against” something instead of “for” something, or that tell people they “ought” to use one piece of software rather than another.

It’s always seemed to me that the most interesting open source projects have their own wellspring, their own itch to scratch.

That’s why I’ve always been a bigger fan of the BSD/Apache free software tradition, which doesn’t look on commercial or even proprietary software as an enemy, but as a choice that reasonable developers can make.

I do agree that open standards and interoperability are good, but I also believe that “open enough” is often “good enough.” Twitter is a network citizen in a way that, say, Facebook or Apple, is not.

I also don’t buy the idea that control by a commercial entity automatically means software is bad. Most open source projects are controlled by a single entity! Just try forking emacs or gcc or the Linux kernel! Sometimes a fork happens to free software projects, but it’s usually because a project has stagnated, not because someone just wants to pull in a different direction. And when it does happen…it’s often destructive, not constructive.

The question is whether the entity in question is a good citizen or not, or whether they abuse their power.

So, for example, I support Apache over IIS and Firefox over IE, because it is clear that Microsoft was trying to control the browser as a way of controlling the web.

I don’t think we have that worry with twitter.

I was especially struck by the non-dogmatic tone of “I also believe that ‘open enough’ is often ‘good enough.’” And O’Reilly reminds me to pay attention to the itches that I should be scratching.

Email this post

Series: Managing the White Space

Geary Rummler and Alan Brache, in Improving Performance, maintain that you can’t do any improving until you’re clear on what level of the organization the performance involves.  They see three main levels:

• The organization level deals with the organization as a whole — its strategy, its overall goals and measures.  Think of this as the framework of the organization — its skeleton.  At this level, you can easily picture the traditional organization chart, like this one for a fictional computer services company:

• The process level is where the the main work of the organization takes place.  If the organization level is the skeleton, the process level is the muscles.  As muscles connect different bones, so processes involve more than one functional area of the organization.  Looking at the chart above, it’s easy to assume that “marketing stuff” happens within the marketing function while “sales stuff” happens in the sales department.  The reality is different:

• Finally, the job/performer level is where individuals perform.  An individual’s job is like a cell of the organization.  The individual works in relation to other individuals, and often finds himself part of more than one process.

Going back to the process level, the second chart shows simplified versions of three processes at Electron Info Services.  The sales process, for example, involves marketing (which collects information about marketplace interests and sales prospects), sales (which performs most of the prospecting, qualifying, and selling of Electron’s services), engineering (the division that will install, configure, and troubleshoot the software sold), and finance (which handles the paperwork related to the sale).

The billing process is connected to but not part of the sales process.  Billing involves some of the same groups within functional areas, and brings in new groups as well.  For example, Sales may have a team to grapple with billing problems so as to free up salespeople to concentrate on new business — but the original sales rep wants to know immediately about any problem.

The third process in the chart, product development, shows how inadequate a function-only chart can be.  Information, processes, and decisions don’t flow in a neat, left-to-right manner.

Rummler and Brache hold that each of the organizational levels has its own needs: its goals, its structure, and its management tasks.  As a result, when you’ve got a performance problem it might result from one or more of nine possible areas — the three organizational levels, and the three needs.

At Electron, if a client’s having problems with the EDI service (electronic data interchange, for exchanging invoices, purchase orders, and other business essentials electronically), analysis might involve:

• The job/performer level: were the electronic maps written or installed incorrectly?  Are the client’s employees operating the system correctly?
• The process level: was the service badly designed for the client’s needs?  Is the telecommunications infrastructure inadequate for the client’s needs?
• The organizational level: has Electron failed to keep up with the marketplace?  Is its strategy inadequate?  Are its products uncompetitive?

A while back, Electron’s goal was to increase revenue from selling services.  Then a salesperson engineered a deal in which Electron sold the computer hardware as well.  The salesperson got a huge bonus for closing the deal — and Electron in effect was telling its sales force, “Sell more hardware.”  In the long run, the effort to sell both hardware and software was counterproductive.  Electron could never successfully compete with computer manufacturers, and the effort to structure similar deals took focus away from the services that are the core of Electron’s business.

What does this have to do with training and learning?  Ask Rummler and Brache:

Most training attempts to improve organization and process performance by addressing only one level (the Job Level) and only one dimension of the Job Level (skills and knowledge).  As a result, the training has no significant long-term impact, training dollars are wasted, and trainees are frustrated and confused.

Similarly, they say, automation often tries to improve performance at the process level, but often automates an inefficient process.  The effort’s not well linked to either the organization level or the job/performer level.

Email this post

Series: Managing the White Space

Following the recent death of co-author Geary Rummler, I’m reading Improving Performance: How to Manage the White Space on the Organization Chart.  This post is the first in a series based on that book and on the implications of that white space.

I’ve read a lot of what Rummler wrote; I took the Performance Analysis Workshop he and Tom Gilbert designed; I was lucky enough to be invited to a Rummler-led session for PAW grads (where I saw among other things a professional-development system for officers on an ocean freighter).  I often work within a single department of a client organization and often with people on the front line, where the organization meets its external customers.  Going through this book, as they say in Congress, “revises and extends” my viewpoint.

Geary Rummler and Alan Brache argue that true performance improvement demands a systematic view of the entire organization.

The traditional view of an organization is the organization chart.  Take a look at one for an organization you know well.  You see the CEO or other chief honcho; the main levels of the chain of command; the prime departments.

What’s missing?  Customers.  Products and services.  The processes that produce the products and services.

In small or new organizations, this vertical view [the traditional organization chart] is not a major problem because everybody in the organization knows each other and needs to understand other functions.  However, as time passes and the organization becomes more complex, as the environment changes, and as technology becomes more complicated, this view of the organization becomes a liability.

Traditional organizations lead to silos built around departments.  Silos make it nearly impossible to resolve interdepartmental issues at low or middle levels.  Functions get better at meeting their own goals (”manufacturing hit its numbers”) but that doesn’t necessarily help the organization as a whole.

As the authors emphasize many times, the greatest opportunities for performance improvement often lie in the functional interfaces — those points at which the baton (for example, production specs) is being passed from one department to another.

An organization chart shows who and with whom, but not the what, why, and how of the business.  In real life, bosses are often managing the organization chart, not the business. Rummler and Brache see a different ideal:

A primary contribution of a manager at the second level or above is to manage interfaces.  The boxes already have managers; the Senior manager adds value by managing the white space between the boxes.

Organizations are adaptive systems.  Chapter 2 lists 10 features of the organization as system.  For example, it converts various inputs into products and services, guided by internal criteria and feedback as well as by feedback from the market.

Any organization that survives, they argue, has adapted — but the health of the organization depends on how well it’s adapted.  “18 months after Peters and Waterman published their list of excellent companies, one third of them had dropped off the list.”

What messages do I draw from this?

• If an organization’s an adaptive system, so are its components.
• What matters is first what gets accomplished, and then how that happens.
• In an organization, learning (in the broad sense) and training (in the focused sense) need to connect both to individual and organizational needs.

More than anything, the value is emphasized in an interview ASTD had with Rummler last year:

(ASTD) What are some of the things that currently frustrate you about the learning and development profession?

The same thing that frustrated me 45 years ago—the fact that it’s a solution in search of a problem. People have developed all this wonderful stuff around learning and development, and it’s become a thing in and of itself rather than something that exists to help people be more effective in their jobs.

Bad management makes it worse because managers read the magazines, see the fads, and call the training people to say, “I want us to try this.� There’s no corrective force in that relationship. In fact, training has become in many ways the enabler for bad management because now the default solution is to fix the people. You’ve got vendors inventing things, business publications promoting them, managers reading them and thinking they should be doing this, and the training department going along with it all too eagerly. It is a whole business.

“Fix the people” isn’t all that far removed from “teach them what they need to know.”

Email this post

I have paper archives.  I keep the dead-tree version of things — especially things older than, say, Netscape — because I want to read them again and am afraid they won’t be around in a digital format.

That’s no longer true for The Science of Winning, an article by Thomas F. Gilbert and Marilyn B. Gilbert that appeared in Training magazine in August of 1988.  The Vancouver chapter of ISPI has a PDF version.

Tom Gilbert was teaching at the University of Alabama during the heyday of legendary football coach Bear Bryant.  The Gilberts recount what Bryant said he did in coaching, and what he actually did.

As usual, there’s a gap — and that gap’s filled with treasure if you are thinking about accomplishment, rather than about behavior.

For me, sports metaphors are like Cool Whip — bland, predictable, and of almost no real use.  The Gilberts get past the Great Coach mythology, and they do it entertainingly — as with the story of how a young Joe Harless, on the Alabama football team, got called into the Bear’s presence.

As for motivation?

“But, coach, ” we protested, “what about all that talk of leadership and inspiration being your keys to success?”

“Aw, people like to hear that shit,” Bryant replied.
“Winning inspires my boys.”

Email this post