|
Now may seem a strange time to defend slack. But that
is what I intend to do, even though we're suffering an
economic downturn, even though we're uncertain we've
reached the bottom, and even though we're still
hearing about rounds of layoffs. Ordinarily, during a
downturn, we expect to hear about "belt tightening,"
taking up slack. Slack is bad. Slack is wasteful.
Slack is something no responsible manager should
tolerate. Slack, according to the conventional wisdom,
has no redeeming qualities.
If slack has a bad reputation generally, it is even
more suspect among the technologically adept. Those
who push technology forward are famed for their
dedication, their punishing schedules during product
development, and their commensurate neglect of such
frivolities as personal hygiene, wholesome diet, and
normal social interaction. Such excesses are, if
anything, celebrated. They are the antithesis of
slack.
Technologists don't just minimize slack in their
own working lives, they unleash upon the world
products and services that may be used to identify and
eliminate slack from the working lives of others. But
technological solutions, including communications
solutions, that are deployed against the problem of
slack may succeed all too well. Slack may not always
be the problem it seems, even though it is usually a
tempting target, especially during an economic
downturn.
EFFICIENCY VERSUS FLEXIBILITY
An alternative view of slack is to see it as part of a
tradeoff between efficiency and flexibility. This view
is elaborated in a recent book entitled Slack:
Getting Past Burnout, Busywork, and the Myth of Total
Efficiency. The book's author, Tom DeMarco, argues
that any company that hopes to become "fast," that is,
responsive and agile, may want to de-emphasize
efficiency in favor of slack. And slack, according to
DeMarco, is the degree of freedom in a company that
allows it to change.
At this point, an analogy might be useful. Let's
start with a company that minimizes slack and
maximizes efficiency. Now, let's liken that company to
an automobile optimized for speed, not
maneuverability. We might imagine such a car as a
rocket on wheels. Very fast. But what happens when the
automobile approaches a turn in the road?
Let's return to slack-free (or nearly slack-free
companies). They may not always be the ones with which
we'd like to communicate. We've all had the experience
of dealing with a frustratingly limited auto-attendant
system or interactive voice response system. At such
times, we might yearn to hear a human being pick up
the phone. But even a human being could disappoint,
especially if they were under strict orders not to
depart from a rigid script, or if they were under
severe pressure to handle a certain number of calls in
a certain amount of time.
CONTACT CENTER IN THE RED
Thus far, the examples we've considered suggest a
contact center focus. The contact center, it is true,
is where companies usually impose mechanistic,
factory-style work flows. More than anyplace else in
an enterprise devoted to knowledge work, the contact
center is where work and workers are subject to the
precepts of Taylorism.
Taylorism, an efficiency approach pioneered by
Frederick Winslow Taylor, parses workflows for
manufacturing such that manufacturers needn't rely on
the skill or intuition or judgment of individual
workers. Instead, complex tasks are chopped up into
smaller, simpler subtasks, which may be accomplished
by less skilled (and more interchangeable) workers.
Taylorism works best when the most important thing
is production volume. But what if flexibility were to
become more important? For example, say the market
were to shift, and you really needed to start
producing not more of the same, but something
different. Well, then, you might have a problem.
Misguided Taylorism is fairly easy to expose within
a manufacturing context. Using an example from
Soviet-style manufacturing, DeMarco describes how a
factory was rewarded based on a single metric: tons of
product. In this case, the product was railroad
spikes. The factory produced tons and tons of railroad
spikes, never minding that there was no particular
demand for these spikes, unconcerned that there was
desperate demand for other products the factory could
have been producing instead.
Smirk, if you will, at the failings of a
heavy-handed, state-controlled economy. A similar
failing could easily happen inside the average contact
center. Consider a contact center in which calls per
hour were the all-important metric. Could such a
contact center easily recognize whether its most
valuable leads were derived from e-mail inquiries? And
even if the contact center agents suspected that their
e-mail inquiries really were valuable, would the
hard-pressed agents have the time and energy to pursue
the leads? And, if not, would the agents have
sufficient status to argue for revised metrics that
would account for the value of e-mail activity?
Now, you might say that while such problems are
unfortunate, they're limited to contact centers. After
all, the contact center is supposed to be about
volume, and when you're dealing with volume, you can't
be too refined, especially when you're contact center
is typically populated by low-skill, high-turnover
agents.
But might such problems extend beyond the contact
center? The question comes to my mind because I often
hear tell of a greater contact center. Such a contact
center embraces the entire enterprise, allowing all
employees, not just contact center agents, to become "customer-facing
assets." The greater contact center is the dream of
many technology providers who are nothing if not eager
to blur the boundary between contact center agent and
general-purpose knowledge worker. (Years ago, the idea
was called the "informal" call center. At least this
was the term preferred by Mitel. We don't hear that
term much these days, but the idea is being echoed by
many vendors, including Cisco.)
The question I have is whether such a blending
would elevate the contact center agent or regiment the
knowledge worker. I don't suppose one extreme or the
other is inevitable. Rather, I suspect whatever
technology is ultimately deployed could reinforce
either predilection: on one hand, you might prefer
intelligent (or would-be intelligent) processes, to be
tended by the least skilled people possible; on the
other hand, you might decide that people are more
flexible than processes, provided they aren't unduly
constrained in terms of the skills they may exercise.
Again, we arrive at the tradeoff between efficiency
and flexibility.
REVENGE ON THE NERDS
You might expect the creators of the technology
solutions would perform work resistant to parsing or "dumbing
down." In fact, the technologically adept are
vulnerable themselves, much like the programmer in
Kurt Vonnegut's Player Piano. In this novel,
the programmer implemented schemes of pure Taylorism,
relying on data from time-and-motion studies to
de-skill and eventually obviate factory workers and
low-level service workers. But, in need of a
challenge, the programmer subjected his own job to his
usual practices, and he soon put himself out of work.
Granted, this is an extreme and even fantastic
example. But programmers don't have to automate
themselves out of existence to limit their
imaginations, if unconsciously, by coming to rely on
increasingly standardized development tools. The
process whereby programmers come to select
functionality as opposed to creating it is perhaps
best described by Ellen Ullman, in her Salon
article, "The Dumbing Down of Programming."
Ullman, a professional programmer herself, pulls
out the manuals for her own development tools, and
discovers remarkably similar passages from each. Again
and again, she finds the manuals take pains to justify
the development tools they describe, relying on the
same general argument. Basically, the argument is an
appeal to expediency: Don't waste time reinventing the
wheel. Instead, generate lines and lines of code at
the press of a button. Reserve your energies for the
subtle customization work, which (perhaps not so
incidentally) will ultimately enhance the value of the
development platform itself. Eventually, Ullman
wonders aloud if programmers might soften, fulfilling
a development destiny preordained by their platforms,
instead of creating from scratch, inspired by their
intimacy with the machine, knowing it down to the
metal.
ATROPHY AND PROGRESS
So, while they may fulfill different functions,
contact center agents, knowledge workers, and
developers all face the same challenge. They all adapt
to a workplace that would absorb their functions into
automated processes. The simplest functions are
usually the first to be absorbed. Accordingly, the
work that remains may be more difficult, possibly
demanding more highly developed skills, or different
skills. If so, and if the need for such skills were to
go unrecognized, or were to be squelched by a clumsy
application of technology, the most interesting and
even most valuable work would simply remain undone,
its value discounted because it eluded easy
quantification. Some work may be accomplished by means
too subtle, too organic, too intricately social for
technology to absorb, or reduce to logical, automated
processes, or replicate by design.
One thinks of all the sterile, deserted urban
plazas that blight many of our cities, and how these
artificial environments, so deliberately architected,
compare so poorly with lively neighborhoods that
somehow evolved all on their own. Could a similar
comparison be made between an enterprise subjected to
a heavy-handed technology solution, and an enterprise
that allows some play, some slack, to sustain the
interactions and relationships that allow "higher-order"
tasks to be fulfilled despite overly reductive
technology?
THE NETWORK EFFECT FOR PEOPLE
Readers of this publication are probably familiar with
Metcalfe's "network effect." Basically, the network
effect holds that the value of any network increases
with the richness of the interconnections that
constitute the network. When it is invoked, the
network effect is usually used in reference to the
proliferation of fax machines, Web terminals, or other
information appliances. But people, too, form networks
of their own. These may exist alongside the networks
devised by IT personnel, but these human networks are
more interesting if they are enriched by corporate
networks. Even if, unlike phones or wireless PDAs, the
people in a network remain more or less constant in
number, people may increase the value of a network by
enhancing the quality of their interactions.
One way to enhance the quality of human
interactions is through the judicious application of
communications solutions. Such solutions may simplify
human-to-human or human-to-machine relationships by
allowing people to communicate naturally, flexibly,
perhaps via voice-mediated interactions, or
exceptionally sensitive call or message routing, or
message translations across media types, or judicious
presence and notification schemes, or conferencing, or
some other communications solution.
The richness of connections can make an enormous
difference, as Bell Laboratories discovered. Bell
Laboratories, in a story repeated by DeMarco in Slack,
decided to identify what it was that set star
performers apart from their nonstar counterparts.
While the stars did pretty much the same work as
anybody else, they enjoyed quicker and more
enthusiastic responses to their information requests.
The star performers had cultivated better
relationships. They had richer connections, in
quantity and quality, than their peers. They had
demonstrated how responsive they could be themselves,
and so their phone calls were answered more quickly
(within 20 minutes on average, instead of four hours).
Now, if individual efforts toward community can
accomplish such dramatic results, what might a
systematic attempt to enrich community relations, via
communications solutions, might achieve?
[ Return
To The October 2001 Table Of Contents ]
|