Emerging Norms: Feature Constellations Based on
Activity Patterns and Incentive Differences
“Like most phenomena—atoms, ants, and stars—characteristics of organizations appear to fall into
natural clusters, or configurations.” — Henry Mintzberg, A Typology of Organizational Structure
ABSTRACT
Software can now better support individual and task-based
differences, but it may have less need to. Greater
interaction among users coalesces usage into shared
constellations of features. Applications that are widely used
in organizations have different patterns of use resulting
from at least three significant activity and incentive
structures: one for individual contributors, one for
managers, and one for executives. When designing,
acquiring, or supporting such an application, the best
approach could be to treat it as three distinct applications.
Failure to do so results in problems and lost opportunities.
Applications discussed include email, shared calendars,
browsers, document databases, application-sharing, desktop
videoconferencing, and team workspaces.
Keywords
requirements analysis, design, support, training, individual
differences, personas, roles, scenarios, task analysis
INTRODUCTION
In group settings, personal preferences can conflict with
social norms or conventions. The more we interact, the
more likely we are to adopt prevailing cultural or group
norms. Life is easier and exchanges are more efficient
when behavior is predictable. As we interact more through
software, individual differences in using software give way
to widespread conventions.
Consider an automobile driver in 1902, before there were
traffic laws. Personal preferences had free rein in design
and use. One could drive at any speed, on either side of a
road, signal turns in any manner, equipped with any or no
lights or brakes. But over time, with more cars on the road,
drivers had to interact. Considerations of safety and
efficiency led to conventions that constrain behavior,
codified in steadily increasing motor vehicle statutes.
Some conventions are arbitrary – it does not matter which
side of the road we drive on as long as everyone drives on
the same side. Other conventions, such as speed limits and
turn signals, are directly tied to safety and efficiency
concerns. Over time, controls for lights, wipers, brakes, and
horn have become more standardized. Personal preferences
operate in a narrower range: I can drive a stick shift (but
cannot rent one in the U.S.), paint my vehicle any color,
and choose a speed within the prescribed limits.
Traffic is picking up on intranet and Internet “information
highways.” Initially individual browsing, communication
and collaboration features are now built into most
applications. As digitally mediated interaction increases,
efficiency and security considerations give rise to
behavioral conventions.
But not a single set of conventions. On the highway,
automobiles, trucks, and motorcycles have different sets of
conventions. The studies of technology use in large
organizations described in this paper indicate that different
sets of conventions govern the use of widespread software
applications. Because there are several sets, they can go
unnoticed.
These studies focus on practices in large organizations that
use and in some cases produce advanced technology. Each
organization employs IT (information technology)
professionals. Yet in requirements gathering, design,
deployment, and support, impacts of new technologies
were not anticipated. No one appreciated that different
constellations of features would be used by different
people. Nevertheless, patterns of use are surprisingly
systematic, few in number, and could be anticipated.
The next section is a review of efforts to accommodate
individual differences through design, customization, and
task and role analysis. To supplement these, it is useful to
step back and consider the overall structure of an
individual’s activities and incentives. Mintzberg’s theory of
organizational forms is summarized as a way to assess data
presented from a case study. Additional studies describe
consequences to software designers and acquirers who did
not recognize that they were serving important
constituencies with different and often contradictory needs.
The best approach in designing, developing, acquiring,
deploying, or supporting a widely-used organizational tool
is to assume that one is designing, developing, acquiring,
deploying, or supporting not one but three or four tools.
people in their various roles, emphasizing the importance
of organizational context.
INDIVIDUAL DIFFERENCES
These analyses generally focus on a limited set of tasks or
roles. More ambitious efforts to identify and formally
represent organization-wide tasks and roles originated in
“office automation” efforts of the 1980s and are central to
workflow management systems. These efforts have had
limited success. Creating and maintaining representations
of tasks and roles is difficult, people shift roles from time to
time and task to task, and experience, level of trust, and
idiosyncratic managerial preferences are important factors
that formal systems cannot or do not represent.
Individual differences exist at all levels: motor skill,
perception, cognition, social interaction, and cultural
norms; experience, knowledge, and aesthetic preference.
Within organizations, people have different tasks, roles and
ways of working, different incentive or reward systems,
different corporate cultures and professional domains.
Individual differences are an important consideration now
that software design can accommodate them. Differences
that cannot be worked around, such as color blindness,
must be addressed directly. Domain differences are
addressed by tailoring systems to vertical markets. Beyond
that, designers (and users) generally feel that individual
differences are not handled well.
Attention is often limited to the experiential dimension:
“beginner/expert” or “user / IT professional.” Efforts to do
more, to include every feature conceivably useful to
anyone, result in complexity and bloat. ‘Options,’
‘preferences,’ ‘customize,’ ‘settings,’ and ‘controls’ menus
are architecturally difficult to design and mostly ignored.
Mackay [14] found that people rarely customized software
and usually did so to recreate previous interfaces, not
exploit new possibilities. When people had experience and
could benefit from customizing, inertia had set in: They had
found satisfactory ways to use the software. Customization
is easier today, but rates remain low [14].
Adaptive interfaces, which take the initiative to change
themselves, emerged in AI efforts of the early 1980s [6],
but progress has been slow. Early efforts tended to annoy
users; recent work emphasizes the importance of
“considerate” or mixed-initiative interfaces [9].
Interfaces based on task and role analysis
Task analysis, identifying the steps involved in a work
process, may focus on a cognitive task such as copying text
or an organizational task such as processing a form. This
useful step in designing support technology has been
extended in sociotechnical design approaches to include
analysis of the work domain [e.g., 22], where a given
individual carries out many tasks. Stakeholder analysis [12]
is often even more fine-grained, because its purpose is
typically to design a system for one organization, rather
than to develop a widely-used product.
More general is the concept of role. As part of contextual
design, Beyer and Holtzblatt [3] define role as “collections
of responsibilities that accomplish a coherent part of the
work.” A person typically has many roles within and
outside a workplace. The sophisticated analyses of
contextual design focus on identifying and supporting
Design centered on personas [5] and scenarios [4] also
focus on roles and tasks. It does not lead to formal
representations of roles or processes in software, but when
informed by descriptions of real people and activity, can
effectively guide design and development teams.
Interfaces based on activity and incentive patterns
This paper steps back from specific tasks and roles to
examine broader activity patterns and incentive structures:
How many meetings a person has, how often they work for
long stretches on one task, how much they delegate, how
sensitive their activities are.
This is a different slice, considering the constitution of a
person’s day across all of their related and unrelated tasks
and roles. Many workers are “trying to keep a lot of balls in
the air,” with each ball representing one task, project, or
role. To understand juggling requires less attention to each
object in the air and more attention to the number of objects
and other constraints affecting performance, the overall
pattern of activity.
In organizational settings there are many job titles but
fewer basic activity patterns. Three or four basic patterns
may cover most workers. In particular, the days of
individual contributors, managers, and executives differ in
ways that are often consistent and predictable.
In contrast, the number of possible roles and scenarios is
unlimited. It could be a great benefit to narrow our focus to
a few groups and a serious error to overlook a major group.
The data and theory that follow suggest these benefits are
available, and these errors commonly occur, with
applications that are widely used in organizations.
Emergent norms based on convention and efficiency lead to
conformity in behavior among individual contributors,
among managers, and among executives.
CASE STUDY OF CALENDAR USE
For six months in 1997 and 19981 I studied on-line calendar
use through observation and interviews at Castle (not real
name), a design and manufacturing company employing
tens of thousands at sites around the world. Castle
managers and their office administrators (‘admins’) had
used and shared online calendars for years, but only
1
PDAs may change calendar behavior. This will not effect the
point of this paper; PDA use will also reflect activity patterns.
recently, after the company embraced a vision of a digital
future that required universal access, had most individual
contributors follow suit.
At the time of the study Castle had 7 non-interoperable
software calendars with 1000 or more registered users.
IBM Profs was used most widely; others included All-in-1,
Lotus Organizer, Schedule+, and Calendar Manager. Castle
planned to standardize on Exchange and Schedule+ and had
begun a trial rollout. There was interest in understanding
current practices with a view to smoothing the transition.
Twenty interviews averaging over an hour were conducted
at different sites. Those interviewed included engineers and
other individual contributors, managers and admins, a
director and executive secretary, and staff involved with
technical and training aspects of this and past rollouts. The
interviews covered personal history of online calendar use.
Several informants had recently shifted to Schedule+ and
reported their initial reactions. Many had used different online calendars over the years and could compare features.
Some identified issues arising with the rollout in progress.
Unexpected, strong patterns emerged from the interviews.
In particular, experiences reported by engineers and other
individual contributors differed substantially from those of
managers and admins. Additional differences marked
executive and executive secretary use, obtained directly
from two interviews and indirectly from reports of those
handling the Schedule+ rollout, for whom upper
management was an important set of customers.
At this time, Leysia Palen completed a quantitative and
qualitative study of calendar use at Sun Microsystems and
Microsoft [19, 20]. This involved approximately 100
interviews and a survey filled out by 2500 employees. The
discussion that follows also draws on these data.
Feature use by individual contributors
Individual contributors are defined here as employees to
whom no one reports. Of course, managers and executives
sometimes work as individuals, but in considering their
days and weeks as a whole, managerial duties set the pace,
regardless of the activity at a given moment.
Most individuals keeping calendars are knowledge workers
in diverse occupations: engineering, accounting, marketing,
and so forth. They spend blocks of time working alone,
have relatively few meetings (nevertheless complaining of
the number), and do not delegate. Much of their work is
visible: Many must account for time closely. A principle
activity when not engaged in individual production is
communication with team members and others.
Meeting reminders. Reminder features that beep or pop up
a window only appeared widely in online calendars in the
1990s. Many individual contributors identified them as a
favorite feature, the feature that attracted them to online
calendars [19 20]. Individuals who worked at their desks
and attended few meetings preferred the portability and
versatility of paper if they kept calendars at all [7].
However, it was easy to lose track of time and miss a
meeting, so reminders solved a problem for them.
Meeting invitations. Integration with email also draws
individuals to online calendars. Emailed invitations that can
be easily inserted into an online calendar remind those
using paper calendars that life could be easier.
Printing. Individuals rarely print their calendars. Often they
have few meetings, most of which are regularly scheduled.
Calendar visibility. Most online calendars allow users to
control how much calendar information they share, globally
or on a meeting-by-meeting or person-by-person basis.
Individual contributors with no online calendar experience
often express concern about ‘micro-management’ should
all of their calendar information be visible to others. They
are generally comfortable showing ‘free-busy’ time, times
they are and are not available, but not the specifics: who
they are meeting with, where, the topic, relevant
attachments, and so forth.
Feature use by managers and their admins
“Study after study has shown that managers work at an
unrelenting pace, that their activities are characterized by
brevity, variety, and discontinuity… Managers strongly
favor the oral medium—namely, telephone calls and
meetings.” [17] A principle concern of managers is
information sharing, relaying information down, up, and
across the organization. Much of their activity and network
of associations is relatively visible and dictated by the
organization’s structure and process.
As noted above, Castle managers (and their admins) had
used online calendars such as PROFS for years.
Understanding the use of a manager’s online calendar
requires considering the admin and manager together. If an
admin keeps a personal calendar it is as an individual
contributor, but when handling a manager’s calendar, an
admin responds to the pressures on the manager, acting as a
surrogate for the manager.2
Meeting reminders. One admin had recently begun using
Schedule+. Early in the interview she asked if I could get a
request back to its developers. I did not work for Microsoft
at the time but asked “What message would you like to get
to them?” She said that there was a useless, frustrating
feature that should be removed: meeting reminders. She
and the two managers she worked with knew their
calendars inside out, were clock-conscious, and had no
need to be reminded. But the Schedule+ rollout default was
to issue a reminder for regularly scheduled meetings, and
she did not know how to turn them off.
This introduces two recurrent phenomena: 1) People with
different roles in an organization value features differently;
2) Teams deploying the application are unaware of this.
The deployment team, mostly individual contributors, set
defaults based on their view of the application. In the
2
In Castle, first-level managers had admin support; in some
organizations this activity pattern appears at the next level.
survey data reported in [20], 93% of individual contributors
rated meeting reminders as important, whereas only 60% of
admins and 70% of managers did.
Meeting invitations. Admins who spend a lot of time
maintaining calendars find it much easier to click on or
drag-and-drop an invitation than to retype meeting
information from an email or phone message. Some
strongly advocated meeting invitation use and expressed
annoyance that not everyone used them.
Printing. Many managers print their calendars as often as
two or three times in a day (in contrast to individuals, who
rarely print calendars). Schedule+ had several print format
options. Understanding them was important to admins.
Asked about training she received on the applications
during the rollout, one said that she learned some things,
but hadn’t felt the training was really designed for her. It
wasn’t. It covered meeting reminders, of no interest to her,
and did not fully cover printing.
Calendar visibility. Coming from a university environment
where no one shared calendar information, I was surprised
by the embrace of open sharing of calendar information at
Castle. Managers and admins found it extremely useful to
share calendar details with one another. They used the
information in myriad ways: to learn where someone would
be after a meeting ended, when they might be interrupted,
where a meeting was being held, who needed to be
involved, and ingenious approaches to solving problems
efficiently and learning about the organization.
Open sharing of calendar information was so useful to
managers that there was little risk of micromanagement.
Punitive use of calendar information could discourage
accurate calendar maintenance and open sharing,
eliminating substantial benefits. Individuals came to
recognize this, and about 90% of Castle employees had
fully open calendars, marking as confidential an occasional
private meeting. This is a nice example of efficiency gains
that result from trust or “social capital.”
Feature use by executives and executive secretaries
At higher levels of management, the pace picks up. There is
much more delegation, to highly trained admins, to staff
specialists, and to subordinates. There is more focus on
coordinating work across the organization. Decisions have
large impacts on lives and careers; the political and
corporate sensitivity of actions is much more pronounced.
Executive schedules are packed, heavily booked for months
and years in advance, with staff playing a major role in
calendar maintenance. Early in the rollout, the transition
team decided that conversion software would be too
expensive, for example to move information from PROFS
to Schedule+ calendars. People would have to retype
calendar content. They had not realized that although this
would only take them a few minutes, it might take an
executive secretary a week. The rollout team had to
reconsider the decision not to get conversion software.
Meeting reminders. Executives had even less use for them
than managers, with staff, paper, and memory to aid them.
Meeting invitations. An executive secretary confided that
she was on a personal campaign to stamp out the use of a
dangerous feature: meeting invitations! A feature that was
loved by a lower-level admin that she worked with. Why?
In the past, the executive asked her to schedule meetings
that were proposed in email. She could point out risks in
agreeing to meet with that person at that time and place.
Now the executive, receiving an invitation in email, would
accept it with a button-click, reducing her involvement in
the decision and possibly requiring her to cancel it, which
is trickier than declining in the first place. Thus, admins
and this executive secretary were at loggerheads, but
neither understood why.
Printing. Executives relied very heavily on printed
calendars, and organized and viewed information on them
in particular ways. They were extremely attached to
specific print formats. Schedule+ only supported seven
print formats. At one point the leader of the rollout team
told me that the single most unforeseen problem was the
fussiness of upper management about print formats. (He
himself never printed his calendar.) It was a major problem,
eventually solved by paying Microsoft to develop dozens of
custom-designed print formats for use within Castle.
Calendar visibility. The only people interviewed at Castle
who managed calendars that were not open to public
viewing were the executive secretary and a director. Nor
were other executive’s calendars. At this level, who is
meeting with whom and about what is sensitive. Executives
don’t even share free-busy information. This reticence was
also found at Sun, where non-executive employees also
default to open sharing of calendar information [19].
1. Individual contributors
— Live at desks, reminders popular
— Meeting invitations an incentive to use
— Printing unimportant
— Privacy can be a concern, often unwarranted
2. Managers and ‘office administrators’
— “Live from calendars,” reminders unnecessary
— Meeting invitations very useful
— Printing important
— Benefits of very open sharing far outweigh privacy
3. Executives
— Live on the road, schedule far in advance
— Meeting invitations dangerous
— Printing very important
— Privacy very important
Figure 1. Calendar use: constellations of features.
Constellations of features
Figure 1 summarizes the patterns derived from interviews
and observations at Castle and Sun. People in these roles
have different activity structures, demands on time,
sensitivities concerning meetings, incentives. Different sets
of features support them. Some of these points are
highlighted by an executive who recently became an
individual contributor and reflected on the experience:
“My calendar was jammed full, and I had an executive secretary.
Therefore my entire life revolved around my calendar. I didn't
need reminders -- I looked at the calendar -- oh, several times an
hour. Moreover, my secretary was always changing it, so I had to
look to see what was happening. And I could rely on her to make
sure I didn't miss important events. She could tell if I was getting
ready in time. Reminders, therefore were a pain. An extra dialog
box that distracted and had to be dismissed…
I am no longer an executive. I no longer am so bound to my
calendar. I no longer have a secretary. The past week, I have
missed two meetings. In one, I knew about the meeting. It was on
my calendar. I was seated at my phone, at my computer. Lost
track of time and missed the meeting. Here is where I should have
used reminders.” (Don Norman, personal communication)
However, such patterns are not recognized in software
design, acquisition, roll out, or training. ‘one size fits all’ is
often the rule for installation defaults, training,
documentation, FAQ lists, and so on. The software may
support customization of features, but people rarely
customize. The software does not reflect the fact that
certain sets of features naturally go together.
A partial exception to this pattern was observed at
Microsoft [20]. Open sharing of calendar information was
not widespread, even among managers. Some employees
who do share calendar information find it as useful as their
peers at Castle or Sun, but most follow a Schedule+ default
of revealing only free-busy time. Why the difference?
Calendar use at Castle began with PROFS, which defaulted
to open sharing. At Microsoft, individual contributors
dominated design and development, but at Sun, an admin
was a central Calendar Manager design team member.
Small wonder that the Calendar Manager default provides
benefits to admins and managers, whereas the Schedule+
default is less efficient for non-executives.
In the requirements analysis process at Castle, a range of
employees might be consulted, but their preferences are
merged. Features that appeal to all survive (e.g., flexible
ways to specify recurring meetings). A feature essential to
one group but not useful to others may not make the cut. “It
may turn out that the resulting set of features isn’t usable
by anyone,” one employee observed. Typically, a single
documentation set and training program is created.
The next sections summarize organizational theory that
helps support and extend these observations, and provide
examples covering several applications and organizations.
A TYPOLOGY OF ORGANIZATIONAL FORMS
Mintzberg [16] presents a typology of organizations. It
does not focus on technology but can aid in analyzing
technology adoption and use. This section briefly
summarizes a detailed, logically compelling framework.
Mintzberg describes 5 “natural clusters or configurations”
into which organizational characteristics fall. He identifies
5 basic parts of most organizations, illustrated in Figure 2.
The operating core consists of the individuals who produce
the organization’s products and services, the strategic apex
comprises top management, and the middle line consists of
the managers in between. Rounding this out are the
technostructure—those who define the work processes of
the organization—and the support staff who sit outside the
operational workflow, such as mailroom, cafeteria, library,
public relations, and legal staff, but not admins or aides.
Strategic Apex
Technostructure
Support
Staff
Middle
Line
Operating Core
Figure 2. Parts of an organization. (After Mintzberg [16].)
Mintzberg contends that these five parts often vie for
influence. Based on the nature of the business, the
competitive environment, and other factors, one part
usually has particularly strong influence. He identifies five
basic types of organization, each manifesting the
ascendancy of one part. In a start-up company, the founders
or executives—the strategic apex—have most influence. In
a university, the professors and lecturers—the operating
core—have unusual influence, and so on.
There are five basic ways to coordinate work, each
corresponding to one type of organization: Direct
supervision, standardization of work processes (e.g., an
assembly line), standardization of outputs (as in
piecework), standardization of skills (through diplomas or
accreditation), and mutual adjustment.
The preferred means of coordinating work depends on the
part of the organization that dominates, the type of
organization. For example, the middle line tends to favor
standardization of output, which allows each division or
department the freedom to formulate its internal work
processes. If the technostructure dominates, standardization
of work processes is the focus, and so on.
This is a very partial sketch of Mintzberg’s detailed
description. Whether or not it captures everything, whether
or not hybrids or exceptions occur, the typology provides
ways to think about organizations.
A different perspective for widely-used software
It is useful to consider Mintzberg’s argument that these five
parts of an organization have different outlooks, biases,
ways of working, priorities, and incentives. Because this is
not how organizations are typically decomposed when
software is the focus. More often we consider the
organization chart and think in terms of parts such as
Marketing, Sales, Engineering, and so forth. In developing
tools specific to these divisions, task, role, and stakeholder
analyses are appropriately used. In this paper we consider
tools that are widely used across these divisions, and the
critical differences are those that Mintzberg identifies.
Individuals, managers, and executives in one division have
similar activity and incentive patterns as those in other
divisions. We need to slice the organization differently.
From this perspective, it is no surprise that people in
Mintzberg’s groups react to a technology differently. It will
make sense to consult each group independently when
gathering requirements, designing a system, planning a
rollout, or setting up support. As the case above and the
examples below indicate, this is usually not done in any of
these activities. The result is confusion, backtracking,
resistance, miscommunication, and lost opportunities.
Technology adoption can upset or shift a balance of power
in an organization [8, 15]. When implementing a large
system, IT professionals may methodically identify
stakeholders [12], but where does one start for an
application that will be used by almost everyone?
Mintzberg provides an answer: Consider the effects of the
application on each of his major parts of an organization.
HOW MANY GROUPS TO CONSIDER?
The Castle description covered three of Mintzberg’s five
categories. How many patterns of application use should
we look for? Of course, it may vary according to
organization and application.
Two factors are relevant: does a group have different needs,
and is the group influential? If the strategic apex or
executive staff use an application, their use should be
considered because of their influence. The managerial level
is important in sizable organizations, but perhaps not in a
startup, for example. The operating core is critical if many
individuals use an application; for example, assembly line
workers might not, but knowledge workers might.
Use by the technostructure and support staff were not
highlighted in the calendar study. The technostructure—
employees responsible for work practices—is relatively
important in manufacturing plants or insurance companies,
less numerous or influential in many organizations. It may
merit closer consideration in some circumstances.
Similarly, technology use by support staff may not
generally be critical enough to design for, with the
exception of technical support.
lT staff: A special case
Technical support staff may not be numerous, but they
often determine how others see a technology, so
understanding how they fit is important In a Lotus Notes
case described below, support staff in some ways resemble
individual contributors, but their incentive and reward
systems differ, with consequences for technology use.
IT staff are special in other ways. They are likely to have
and to use software tools. In an organization with a large IT
group, perhaps headed by a chief information or technology
officer, IT may itself have executive, managerial, and
individual users of its tools. And finally, a hardware or
software company, with its own internal IT staff, also
encounters external IT professionals as important
customers whose views have to be considered in design.
Other complications remain to be explored. For example,
an individual in a Sales division could have meeting-filled
activity patterns similar to managers, but different
incentives, with consequences for software use.
In conclusion, consideration of at least three sets of
requirements would be optimal, but today those designing,
acquiring, and supporting applications typically think in
terms of one or two patterns of use (often just their own).
The examples below reinforce the view that three would be
a big improvement. The paper concludes by arguing that
this might not require more work than a single design.
EXAMPLES OF WIDELY USED APPLICATIONS
Email
A 1989 ethnographic report on early use of email in
organizations, Perin [21] described differences between
individual contributors and managers. The asynchronous,
nature of email appealed to individual contributors but not
to interrupt-driven managers with full calendars. Some
managers printed email messages and filed them to be
reviewed shortly before their next meeting with the sender.
The informality of email enabled individuals to bypass
hierarchy. Because a recipient can choose if and when to
read or respond, an exchange is more like an elevator
conversation than a formally scheduled meeting. This can
be uncomfortable for a manager being bypassed.
Rumor-propagation, often enjoyed by individuals, can be a
problem for managers. A corresponding top-down problem
arose: A manager can place a motivational spin on a
directive received by voice from above, but doing so on
one received by email risks having the spin revealed if the
original email is forwarded verbatim by other managers.
Many managers felt threatened by email, and in general
email use spread slowly, from the bottom up. Managerial
acceptance grew as features useful to them were added,
such as document attachments and calendar integration.
Studies at Lotus [2, 23] and Microsoft (Gena Venolia and
JJ Cadiz, unpublished study) examined email use by
individuals and managers. Data that suggest different
features for managers and individuals include quantity:
Managers receive more email on average. Bälter [1]
modeled email filing and retrieval and suggests that
different strategies are optimal for different email volumes.
Another individual-manager difference led to a design
change in a prototype email organizer [2]: Email received
as a “bcc:” is usually useless spam for individuals but is
often important email for managers.
Email threading is important for individuals and managers.
Anoop Gupta (personal communication) interviewed an
executive who noted that he instructed people not to
include him in email threads: When a thread concluded, he
wanted a report. A single case, but it is consistent with the
high demands on time and the disposition to delegate at that
level, and could inspire innovations that serve executives.
Real-time communication and application sharing
NetMeeting, a free software application supporting
application-sharing, chat, shared whiteboard, and point-topoint audio and video, was released in the mid-1990s.
Designed for use by individual contributors, it overlooked
thirty years of research on meeting support software that
would have pointed to features useful to managers.
In 1998 I participated in a study of NetMeeting deployment
in a large organization, where it was used by individuals,
managers, and executives. Examples of features great for
individuals interacting with a colleague were point-to-point
audio and open floor control (anyone can use their mouse
or keyboard to drive the application).
In this organization, the principal use of NetMeeting is by
managers and project leaders to conduct distributed
meetings. Most meetings involved several sites, so pointto-point audio was useless; speakerphone conference calls
were used. And after one group’s initial use of NetMeeting,
the furious manager who led the meeting strongly attacked
the open floor control model, insisting that is was built only
because a developer had thought of a way to do it. In the
meeting, people intentionally or accidentally wrested
control from her and one another. More generally, chaos
often reigned in large meetings, with people accidentally
sharing out email or other material, or blocking the view of
the object being discussed.
Conversely, NetMeeting did not provide tools that would
be very useful to managers: agenda tools, action item tools,
brainstorming tools. In one meeting, a group kludged a
brainstorming tool: Everyone typed their ideas into the chat
window, which one person then copied into a notepad and
from there into Word, where he deleted the names one line
at a time to get the desired list of ideas.3
By coincidence, a team of NetMeeting 2.0 developers
visited the site. They had not previously seen the product
used by more than three people at once. NetMeeting 3.0
supported multiple floor control models, but not the other
tools. When told of user confusion, a NetMeeting team
member wrote “I’d like to see your training materials…
Most of the materials we developed for Netmeeting 3.X
were for the clients calling just one other person.”
Lotus Notes
Orlikowski [18] describes the early use of Lotus Notes in
Alpha Corp, a consulting company. The “strategic apex,”
the Partners, saw potential benefits in sharing experiences:
less duplication and greater efficiency and profit. However,
individual consultants had little incentive to learn or use the
system. In an “up or out” competitive environment, some
consultants are promoted and some let go. Their value is in
their experience and knowledge; sharing it with colleaguecompetitors was not a priority.
Addressing this unanticipated executive-individual
difference was expensive. Had it been anticipated,
incentives to learn the system and share knowledge might
have been introduced early. This approach was
subsequently stressed by one of Alpha Corp’s rivals.
Alpha Corp deployed thousands of copies of Notes around
the world. A support team handled installation and training.
Support team members were not in the competitive “up-orout” battle to become partners. They used Notes to share
best practices in the fashion envisioned for the consultants.
The incentive structures and activity patterns that led to this
success suggest that features found in Notes could be useful
for people in Mintzberg’s support category in general.
Web browsing
In a recent study of Web use, two-third of the participants
were individual contributors and most others were thirdlevel managers [11]. All made heavy use of the Web, but
did so in different ways. All individuals reported that at
times they spent 30 minutes on the web, whereas the
managers reported that they did not. Managers are more
likely to search the group’s web site for internal
information and are likely to task an admin or subordinate
to keep the site current. They received URLs in email, but
relied on email summaries; if those were not available they
forwarded the email to subordinates requesting a summary.
They frequently forwarded URLs “FYI” to peers,
subordinates, and superiors.
The authors do not make separate recommendations for
supporting individuals and managers, but the differing
usage patterns suggest different tools for each group.
Desktop videoconferencing at Castle
Video is often particularly appealing to executives. At
some expense, Polycom ViaVideo systems were recently
put on all high executive desktops at Castle. They often
spoke on the phone and wanted to see each other.
The system was never used because of how calls are set up.
One executive doesn’t simply phone another. Rather, the
task of finding a mutually free moment is delegated to
executive secretaries who do so on the phone, bringing in
the execs at the last second. There is no time to establish a
parallel connection through the computer system.
Team workspaces
3
A NetMeeting developer later noted that if the ad hoc process
used a spreadsheet in the third step, all names could be deleted
at once. But still not a sophisticated meeting tool!
Several products now on the market allow the creation of
team or project workspaces, where documents and other
objects can be collected and team members notified of
changes. In one case, a decision to adopt such a product
was overruled because there was not a separate interface
for the manager. If the manager was not entered as a group
member, the documents would be inaccessible to him. If he
was included, he would receive more information than he
wanted. He would get the information useful to individual
contributors. A management interface was an overlooked,
and in this case essential, design opportunity. (Steve
Poltrock, personal communication.)
Revisiting calendars: Patterns are still not recognized
In the late 1990s, a team of highly experienced developers
and interface designers created a set of office applications
to run on a ‘network computer.’ The goal was streamlined,
useful, usable, core-functionality email, calendaring, and
other productivity tools. Eventually the team prepared to
deploy the applications widely in their own organization,
first to individual contributors, then to managers and
executives. (Sources: personal communications with Leysia
Palen and design team members.)
When managers began using the calendar, the team a showstopping problem emerged. The reduced-functionality
calendar had no printing capability. Individuals, including
the designers, rarely print calendars, but managers do. A
new release of the calendar was necessary.
Another problem cropped up when executives began using
the calendar. In this company, as in Castle, open sharing of
calendar details is the default, with private meetings
blocked off one at a time. As at Castle, executives are an
exception. The reduced-functionality calendar allowed one
to make individual appointments private but not the entire
calendar in one step. This was unacceptable to executives,
forcing another redesign of the product.4
DISCUSSION—EMERGING NORMS FOR SOFTWARE USE
The fact that conventions or norms emerge as we interact
with technologies is important because it argues that
considerations of efficiency will over time lead to similar
or identical patterns of use within a group.
Why might norms be emerging now? Several factors
suggest that the phenomenon was less pronounced several
years ago, and will be more pronounced in the future.
i) Many managers and executives have only recently begun
using software. Surveys reported that in 1989 21% of CEOs
used a computer, today 76% do [10]. Applications with
organization-wide appeal have appeared slowly.
ii) Usage conventions and norms take time to emerge, and
do so more rapidly when people interact. Software use is
steadily becoming more collaborative through applications
that directly support communication, information sharing,
and coordination, and through collaboration features added
4
In fairness to the team, the designers’ intent was to support
hypothetical ‘transaction processors.’ When no one fitting this
description was found and with management wishing to
establish the product’s utility, a broad deployment was begun.
to individual productivity tools (as illustrated by meeting
invitations added to calendars in the early 1990s).
Interactive use of software leads to greater conformity in
behavior in various ways. Many group support technologies
must be used by all group members to be most effective.
This leads to significant (if sometimes subtle) peer pressure
to adopt [19]. Also, once an application is used by a group,
people learn about useful features from others. Finally, as
in the automobile analogy, people establish shared social
conventions and patterns of use in order to work efficiently.
Use of a feature that fits well with an activity pattern—that
tends to help individuals, or managers, or executives work
more effectively—will propagate, overriding minor
individual differences based on prior experience, working
style, or aesthetic preference. A person’s preference that is
strong enough may of course prevail, but over time,
conformity within a community of use is likely.
The same forces operated on individual productivity tools,
albeit more slowly. Early word processors were used as
improved typewriters, to produce documents that were then
printed and distributed. Individual authors could use
whatever software, fonts, styles, and features they wished.
But after networked computers and email attachments
enabled document sharing, we no longer computed in
private. Pressures to conform grew—co-authoring and
document sharing required or promoted use of the same
word processor, templates, styles, fonts, and so forth. Best
practices were easily and naturally communicated in the
process of interacting or collaborating.
Conflicts on the boundaries between levels
Given the pressures that force convergence of behavior,
how can we end up with three different and in some cases
conflicting patterns of use in an organization? In part, it is
because individual contributors interact primarily with
other individual contributors, managers with other
managers, and executives with other executives.
Striking conflicts were encountered at Castle on the borders
between these three groups. The executive secretary who
disliked meeting invitations supervised an admin who
loved them, and this appeared to be an emotional issue for
both. The admin who was most hostile to meeting
reminders worked for first-level managers, who do interact
with individual contributors. Because the person who
creates an appointment sets reminders for the people
invited on this software, first level managers are most likely
to receive unwelcome reminders. Most poignantly, the
Director I interviewed was torn over the issue of sharing his
calendar details. He saw the efficiencies in doing so (the
manager pattern) and had shared, but then he was
embarrassed by exposure in one incident and reluctantly
decided to block access (the executive pattern).
The fact that interaction leads to convergence in behavior
may have the interesting consequence of limiting the
number of feature constellations. Three of four may indeed
suffice within an organization. It could also perpetuate or
solidify distinct workgroup boundaries if each comes to
speak its own technical “language.”
IMPLICATIONS FOR DESIGN AND USE
In retrospect it seems obvious that people acting under
different demands and constraints will find different
features useful and different ways to use the same software.
The examples overwhelmingly suggest that a widely-used
application will find three or four distinct patterns of use,
constellations of features, and sets of preferred practices.
Requirements gathering, design, usability testing, training
and support are well advised to consider the important
constituencies of individuals, managers, and executives,
and probably IT professionals.
This does not address consumer use or small organizations
and groups with atypical activity patterns. Other exceptions
will be found. But the pattern described in this paper is
strong enough to merit being the initial assumption.
the literature, examine use of deployed software, identify
relevant organizational roles. Where I have looked, the
oversights have been glaring, so progress should be rapid.5
ACKNOWLEDGMENTS
REFERENCES
1. Bälter, O. (2000). Keystroke level analysis of email
message organization. Proc. CHI 2000, 105-112.
2. Bälter, O. & Sidner, C. (2001). Bifrost Inbox Organizer:
Giving users control over the inbox. NADA TR TRITANA-P0101, KTH, Stockholm.
A workflow or distributed project management application
may have different interfaces for managers and individual
contributors, but most applications are not designed around
job categories. One might think calendars mainly just
record meetings and appointments, whoever you are. It’s an
easy mistake to make.
3. Beyer, H. & Holtzblatt, K. (1998). Contextual design.
Morgan Kaufmann.
If may seem straightforward but people have not paid
attention to it. The examples are drawn from international
organizations employing highly qualified people in
requirements analysis, design, product deployment, and
customer support. Repeatedly, the major problems that they
encountered resulted from overlooking this.
6. Fischer, G., Lemke, A. & Schwab, T. (1984). Active
help systems. In T. Green et al. (Eds.), Proc. Eur. Conf.
on Cognitive Ergonomics, 116-131. Springer-Verlag.
Specialized vertical applications used within an
organizational division is likely also to see, emerging
norms at different levels. Tools used throughout a large IT
organization was given an example, but tools used by
execs, managers, and individuals in a Marketing,
Engineering, or other division are also strong candidates.
Insight is still to be derived from considering the activity
patterns, priorities, and constraints. Listening is necessary,
but a few voices may emerge to replace a cacophony.
Doing it right may be easier
This does not call for tripling the effort. It may require less
effort to do things right. For example, design might require
fewer task analysis and employ fewer but more focused
scenarios or personas. In requirements analysis, people
from different parts of an organization may already be
consulted, but their input is pooled. Analyzing the same
data separately could reduce the noise, yielding a few
relatively clear patterns in place of one fuzzy picture.
Usability tests may not require more participants, just
drawing from and analyzing each group independently,
reducing the noise. ‘Listening to users’ is easier when you
know they will speak in a few distinct voices.
Another implication of this analysis is that professionals
engaged in requirements analysis, design, deployment,
support, and training should increase their understanding
and build intuitions about organizational behaviors: Read
4. Carroll, J. (Ed.) (1995). Scenario-based design. Wiley.
5. Cooper, A. (1999). The inmates are running the asylum.
Macmillan.
7. Grudin, J. (1988). Why CSCW applications fail:
Problems in the design and evaluation of organizational
interfaces. Proc. CSCW'88, 85-93. New York: ACM.
5
Mintzberg’s framework provides a detailed case for bypassing
organizational divisions such as Marketing and Engineering that
are usually the focus of attention in favor of elements that seem
more relevant for these kinds of applications. The best test of
Mintzberg’s hypothesis might be to create a large organization,
give it a vague charter, and see what happens. In the early 1980s
this unusual experiment was carried out with the creation in
Austin, Texas of MCC, the first technology consortium. As he
might have predicted, each of his five parts attempt to push the
organization toward one of his organizational forms. Executives
attempted to maintain direct supervision, the middle line
attempted to divisionalize the organization into autonomous
units, researchers worked to create a university-like professional
bureaucracy. Members of the technostructure generated a
thicket of process hurdles with a mind to antitrust and
shareholder conflicts of interest, and the support staff included
skilled people from the shareholder companies who pressed for
a greater role feeling, that they knew what research directions
would be of greatest value to the shareholders.
Over time, the strategic apex and technostructure lost influence
and the support staff did not acquire it. Divisions retained a fair
degree of autonomy, but the professionals ultimately benefited
most from the experience.
Several years after MCC’s founding a reading group discussed
classic papers on organizational behavior. Mintzberg’s chapter
[16] had the best reception.
8. Henderson, D.A. Jr. (1986). The Trillium user interface
design environment. Proc. CHI’86, 221-227.
9. Horvitz, E. (1999). Principles of mixed-initiative user
interfaces. Proc. CHI’99, 159-166.
10. Jackson, M. (Feb. 3, 2002). Last days of the corporate
technophobe. New York Times.
11. Jones, W. P., Bruce, H. & Dumais, S. T. (2001).
Keeping found things found on the web. Proc. CIKM
2001, 119-126.
12. Kling, R. (1992). Behind the terminal: The critical role
of computing infrastructure in effective information
systems’ development and use. In W. Cotterman and J.
Senn (Eds.) Challenges and strategies for research in
systems development, 153-201. Wiley.
13. McClintock, M. (2001). Personal communication
describing studies of Microsoft Office customization.
14. Mackay, W. (1990). Users and customizable software:
A co-adaptive phenomenon. Ph.D. Thesis, Sloan School
of Management, MIT.
15. Markus, M. L. (1983). Power, politics, and MIS
implementation. Communications of the ACM, 26, 6,
430-444. Reprinted in R.M. Baecker and W.A.S.
Buxton (Eds.) Readings in Human Computer
Interaction. Morgan Kaufmann, 1987.
16. Mintzberg, H. (1984). A typology of organizational
structure. In D. Miller and P. H. Friesen (Eds.),
Organizations: A quantum view (pp. 68-86). PrenticeHall. Reprinted in R. Baecker (Ed.), Readings in
groupware and computer-supported cooperative work.
Morgan Kaufmann, 1993.
17. Mintzberg, H. (1989). Mintzberg on management. Free
Press.
18. Orlikowski, W. (1992). Learning from Notes:
Organizational issues in groupware implementation.
Proc. CSCW’92, 362-369. ACM.
19. Palen, L. (1998). Calendars on the New Frontier:
Challenges of Groupware Technology. Dissertation,
Information & Computer Science, University of
California, Irvine.
20. Palen, L. & Grudin, J. (2002). Discretionary adoption
of group support software: Lessons from calendar
applications. To appear in B.E. Munkvold (Ed.),
Organizational implementation of collaboration
technology. Springer Verlag.
21. Perin, C. (1991). Electronic social fields in bureaucracies. Communication of the ACM, 34, 12, 74-82.
22. Vicente, K. (1999). Cognitive work analysis. Erlbaum.
23. Whittaker, S. & Sidner, C. (1996). Email overload:
Exploring personal information management of email.
Proc. CHI 96, 276-283.