The Third Skillset

The Mechanics of Effective Teamwork

A How-to For High Performance Teamwork With Examples Using Altova MetaTeam
Altova GmbH!! ! ! ! ! ! ! ! ! ! David Kershaw, PMP
3 AUDIOBOOK COLLECTIONS

6 BOOK COLLECTIONS
Contents
Introduction
1. The Third Skillset
2. Team Definition
3. GRPI Needs
4. SMART Requirements
5. RACI Levels
6. Tasks & Responsibilities
7. Structured Decision Making
8. Risk Management
9. Organizational Networks
Introduction
A brief introduction to this
book explaining what it is,
who it is for and why we
wrote it.
Section 1

The Problem of The Problem of Teamwork

Teams are complicated by their nature. Most of us have partici-

Teamwork pated in some kind of team, formal or informal. In doing that

you very likely noticed that people have to work hard to work to-
gether effectively. This is because there are natural differences
between team members. These differences include:

• Levels of motivation, energy and ability

In This Section
• Expectations about how activities will be done

1. The Problem of Teamwork • Ways of thinking about work

2. Teamwork Is Not a Science • Understandings of goals and roles

3. Why Are Teams Important? • Aspirations and interests

4. What Is Team Structure?

5. What Is a Self-organizing Team?

Teamwork Is Not a Science
6. Is Self-organization Sufficient? Teamwork is fuzzy, not black and white like mathematics. In
some ways organizing a team is like building a machine without
instructions or navigating a maze.

You can read books like this one to get started, but fundamen-
tally you learn teamwork by trial and error. Moreover, there will
always be new ideas about teams, competing approaches and
situations that refuse to fit with best practices.

3
This book does not attempt to cover every aspect of teams. No
book about teamwork can realistically do that.
What Is Team Structure?
Teams are organized by information and processes. The struc-
Why Are Teams Important? ture of a team is the way it is defined for its management and
members in terms of:
In many situations, teams of people have more potential for
problem solving and doing work than individuals. When a per- • Membership
son or group of people want to do something that requires com-
bining their efforts they need to work at a larger scale. Working • Goals
at a larger scale requires organization. Organization allows mul- • Roles
tiple people to achieve more than a single person, without the
group becoming an ineffective mob. • Responsibilities

For organizations, using teams is one solution to scaling collec- • Processes, starting with decision-making, communications
tive efforts. There are other approaches with similar goals. and information management
Some of these are:

• Hierarchical organization
What Is a Self-organizing Team?
• Group processes, like formal project management
A self-organizing team is simply a team that organizes its mem-
• Affinity networks bers’ efforts. All teams do this.
• Franchising, subsidiaries and affiliates Examples of self-organization include:
This book only addresses teamwork. More specifically it ad-
• Delegating roles and tasks
dresses the structures and self-organization of teams.

4
• Having expected ways to do common activities
• Using the same words for the same things
• Coordinating working hours.
Self-organization is a practical requirement for every team to
some degree. Without self-organization a team would be little
different than a group of industrial robots. It would require all
the painstaking and expensive programming of robots. But it
would have none of benefits of tireless work and super-human
strength and precision.
For example, it would be very uncommon for a team within a
business to not have a well defined position within the overall
hierarchical structure of the company.
Likewise, a less formal team might exist outside a hierarchical
organization, but it would typically still have a context. Such a
team might form within a wider affinity network of some kind,
such as a common interest, activity or communications plat-
form.

Self-organizing teams are found in every type of organization.

This includes even the most hierarchical or command and con-
trol organizations. Self-organization is as much a part of human
nature as it is a part of how groups reach the scale required to
meet complex goals. There is nothing revolutionary, subversive
or even adventurous about self-organization.

Is Self-organization Sufficient?
In most cases multiple approaches to group organization need
to be mixed together to create an effective approach for a spe-
cific situation.

5
Section 2
About This Book
In This Section
1. What This Book Is About
2. What This Book Is
3. What This Book Is Not
4. Who This Book Is For
5. What To Expect
6. An Overview Of the Contents
What This Book Is About
This book is about the organizational structures that define and
enable productive teams. For more context-setting read the
brief first chapter titled The Third Skill Set.
What This Book Is
This book is a simple summary of some of the ideas and sug-
gestions we have communicated in blog posts, presentations
and in other ways over the past year or so.
What this Book Is Not
This book is not a textbook. It does not cover the topic of team-
work exhaustively. Rather, it is a high-level combination of
some core concepts in an easy format.
This book is also not a manual for project management, depart-
ment management or running a committee. There are stan-
dards and methodologies for those activities that will combine
well with this book’s suggestions.
6
 This book does not provide many citations or suggestions for
Who This Book Is For
future reading. But to be sure, the vast majority of the content is
Our goal in collecting these ideas in one place is to help teams
derived from well-regarded sources in the literature on team-
think through ways of self-organizing.
work−we can’t claim to have invented most of this material.
It may also be a useful read for people who have an oversight
Instead of a blizzard of citations, we keep it simple. We do pro-
role by virtue of being a part of a PMO (Project Management Of-
vide a few links to articles on the MetaTeam blog. Many of
fice), acting as a functional manager or in another way influenc-
these posts contain links to more background information.
ing multiple teams.
Teamwork is a subject that has been well covered by a great
This book is written to help all teams, from agile to formal. How-
number of fine writers and textbooks. If what we offer here inter-
ever, larger teams and teams in larger companies have greater
ests you, you will easily find much more information on the topic
need for the structural support that is the subject of this book
starting from a simple web search.
due to their more complex environment.

What To Expect An Overview Of the Contents

Each chapter of this book is broken into brief sections. The sec- We will look at how teams operate in a progression that basi-
tions address one set of related thoughts. Sections are inten- cally tracks the stages of setting up a team. The order we
tionally short. Each chapter should take just a few minutes. chose is:

We offer suggestions or questions for you to think about. In • Membership

each case we explain the reasoning. We do not attempt to pin
down the details because there are many differences between • Goal setting
organizations. Instead we provide you with a jumping off point
• Roles, responsibilities and tasks
that will help you consider new approaches or confirm your own
thinking. • Decision-making

7
• Communications and cooperation

This ordering roughly follows the concept of the hierarchy of

team needs, often referred to as GRPI, that we will look at in
chapter three.

8
Section 3

Introducing About Altova

Altova GmbH is a software products company based in Vienna

MetaTeam Austria and Beverly Massachusetts, in the United States.

The company was founded in the early 1990s and is best

known for its market leading XMLSpy development environ-
ment. More recently Altova has become well-known for data
management and business intelligence. Altova entered the pro-
In This Section ject and team management area with the release of its
MetaTeam online service.
1. About Altova

2. Why We Offer This Book

Why We Offer This Book
3. What Is MetaTeam?
Altova is a software products company. We created this book to
4. Is MetaTeam Required?
compliment one of our products, MetaTeam.
5. Where Can I Learn More?
Altova is not in the business of consulting to companies on
teamwork. But we do have a strong interest in helping compa-
nies organize teams well and run successful projects.

This book highlights the structural foundations of good team-

work. MetaTeam implements these concepts in an accessible,
consistent and practical way. We want to encourage you to take
a look.

9

What Is MetaTeam?
MetaTeam is an online service offered by Altova. It is a tool for
self-organizing teams that want to be more effective.
MetaTeam integrates elements of
• Collaborative Decision-making
• Team Performance Management
• Project Management
These structural elements of teamwork are well-known and in-
clude practices that are widely advocated. However, they have
not been integrated in a single software product before now.
Part of our job here is to help teams understand how MetaTeam
implements some of the best ideas from these three areas, and
how MetaTeam can help them be more successful.
Is MetaTeam Required?
In short, no.
This book is not a guide to using MetaTeam. Every idea and
suggestion in this book may be easily applied with MetaTeam.
But you can also implement these ideas in other ways.
In a very few places we mention MetaTeam by way of illustra-
tion. In these cases we endeavor to make the illustration clear
to people who have not used MetaTeam.
We believe MetaTeam is the best way for teams to organize
themselves. However, we recognize that creative people may
find their own approaches.
Where Can I Learn More?
You can learn about MetaTeam on the Altova website. In addi-
tion, you can find examples of using MetaTeam in the
MetaTeam Blog.
To try out MetaTeam sign up for a MetaTeam account here.
Then login to experiment, learn and apply MetaTeam at your
own pace.
10
 Introduction
The Third Skillset
GRPI
Risk Management
Decision-
making Tasks &
The MetaTeam login page at http://metateam.net.
Responsibilities
SMART

Team Definition
RACI
Organizational Networks

11
The Third Skillset

1
Identifies a type of
straightforward and well-
known best practices
which fill the space
between soft skills and
hard skills
Section 1
The Third Skillset
In This Section
1. Management Vs. Leadership
2. Soft Skills, Hard Skills
3. What Is The 3rd Skill Set?
Management Vs. Leadership
In a now familiar quote, Peter Drucker said “Management is do-
ing things right; leadership is doing the right things”.
Before the right things can turn out right you have to know how
to do things right. It is a natural learning progression.
Doing the right things wrong won’t get you anywhere. Period.
Whereas, sometimes in doing the “wrong” things right you have
at least the chance to compete effectively with your peers in
other companies.
That may not sound inspiring. But consider, the vast majority of
companies essentially compete on execution, not grand vision.
In this book we talk about doing the simplest team organization
things right. We leave visionary leadership to specialists in that
complex topic.
Soft Skills, Hard Skills
Project Managers and other team leaders often ask the ques-
tion: what is more important soft skills or hard skills. In the
usual case a lively discussion follows.
13
For the present purposes let’s say that soft skills are interper-
sonal relationship oriented abilities. Examples may include:
• Emotional Intelligence
• Negotiation and persuasion
• Difficult conversations
• Empathy
• And similar “intangibles”
In contrast, let’s stipulate that hard skills, in the context of team
efforts, include the capabilities most often associated with pro-
ject and department managers. These include:
• Estimation techniques such as PERT and function point analy-
sis
• Work tracking techniques like Earned Value
• Scheduling methods including Critical Path and Critical Chain
• Risk management tools like Monte Carlo simulation
• And similar “algorithmic” approaches to quantifiable problems
What Is The Third Skillset?
What is often left out, marginalized or mixed in with dissimilar
skills is what can be called the Third Skill Set.
These are the organizational skills that structure a team for suc-
cess. They may be applied with the softest touch or in a me-
chanical way more in keeping with a hard skill. These skills in-
clude:
• Team definition and operations
• Organization of goals, roles and processes
• Management by responsibility
• Communications and information management
• And similar well-known best practices
These are practices that can be followed as you would follow a
recipe. Like a recipe you can decide to follow them by the book
or with some improvisation, knowing that if you stay close to the
instructions you are likely to achieve a good outcome.
This book is about the third skillset that structures and improves
team operations. In the context of teamwork, these are what
we feel are the “right things” Drucker refers to.
14
15
Section 2

A Map of the Road How Does It All Fit Together?

The contents of this book are a toolkit for teamwork. You should

AheadToolkit be able to reach in and grab the tool you need when you need
it.

There is also a pattern to the use of these tools. The chapter

on GRPI is the best reference. (GRPI stands for Goals, Roles,
Processes and Interpersonal).
In This Section
But for the visual thinkers, here is a view of the toolkit to help
you see how the sections of this book group together.
1. How Does It All Fit Together?
You may notice that there are not specific chapters for each box
in the processes area. The contents of this book offers lots of
guidance in these topics. However, it does not attempt to be
comprehensive. There will always be much more to explore and
learn.

16
 Introduction
The Third Skillset
GRPI
Risk Management
Decision-
making Tasks &
Responsibilities
SMART

Team Definition
RACI
Organizational Networks

17
Team Definition

2
Explores the creation of
teams as distinct
structures within a larger
organization.
Section 1
Forming Teams
In This Section
1. How Do We Recognize a Team?
2. Is Recognition Important To Members?
3. Is Clear Membership Enough?
How Do We Recognize a Team?
Teams are created in many different ways in different situations.
Once a team is created, how to people recognize it from out-
side?
There are informal ways to spot a team. A few of them are ob-
serving:
• Shared work
• Increased communication between the members
• Grouping in physical or online spaces
However, those observations do not always clearly identify a
team. Generally there needs to be a more formal identification
of a team that is brought to the attention of non-members.
Is Recognition Important To Members?
Team members also need to be able to identify their team-
mates.
In the eyes of some team members it may be obvious who is
part of the team. However, very often different team members
have different understandings about who is a part of their team.
19
People who study teams have found that as few as 10% agree. identifying themselves. Without an identity the team will have
This lack of clarity negatively affects members’ access to infor- trouble gaining the support, time allotment, and resources to be
mation, time, attention and materials. successful.

Moreover, many people belong to multiple teams at the same
time. A person on multiple teams can only dedicate some effort
to each team. In this case teammates are likely to have differ-
ent ideas about how much a person is a part of the team. Some
may question if a person who only puts in a few hours a week is
really a member.
A name is the simplest form of team identity. Later in this chap-
ter we will look at the value of drawing a line between what is
inside and what is outside a team. But without a sense of iden-
tity, starting with a name and list of members, there is no inside
or outside to define.

Over time, part-time members are often increasingly marginal-

ized, with the team losing the benefits of the person’s efforts.

These considerations suggest that team membership needs to

be clearly defined as much for members as for non-members.

Is Clear Membership Enough?

This chapter looks at forming a team by focusing on member-
ship and boundaries. Is that enough?

The answer is no, it is not.

It is easy to see that teams need to understand their reason for

being and other organizational details. It is less obvious, but not
hard to see that teams need to have a name and other ways of

20
Section 2
The Boundary
Lines
In This Section
1. What Are the Boundary Lines?
2. Do Clear Boundaries Cause Silos?
3. Boundaries Within Teams
4. When Do Boundaries Change?
What Are the Boundary Lines?
Team boundaries are both:
• A statement of membership
• An invisible barrier around the team that moderates outside
influence and focuses outbound communication
The word “barrier” does not mean a hard line, like a checkpoint
on an international boundary. It means an understanding by
the team members and other stakeholders of who is part of the
effort and who does not have that standing.
People who are not team members should not have the same
access to information and channels of communication as mem-
bers. This is important to the smooth functioning of the team be-
cause it helps channel influence through the member or mem-
bers responsible for managing expectations and setting direc-
tion.
From the outside, the channeling of influence may frustrate
some non-team members. However, for the identified stakehold-
ers and the team’s management this is a good thing.
The reason is that when management influence the team
through a larger number of team members there is inefficiency.
21
Influencing a single point of team leadership is more practical
and allows management to be more effective in giving direction.
It also provides a single source of information into and out of
the team; one that is accountable for the correctness of out-
bound communications.
Do Clear Boundaries Cause Silos?
The answer is no.
A well defined team may exist within a silo, or reporting vertical,
but such a team is not the cause of the silo.
Teams are typically not responsible for their context, they are a
product of it. If a team is limited to individuals within a silo, or if
team outbound communications are received only by manage-
ment within a silo, that is a consequence of how the larger or-
ganization functions, not of how the team is run.
And when team leaders run their teams to counter such an envi-
ronment it is a distraction to team members performing their
work.
Boundaries Within Teams
The primary boundary is team membership. However, there
may be several important boundaries within a team that help it
work effectively.
Inner boundaries define the members’ relationships further and
have many of the same practical benefits. These inner bounda-
ries may include:
• Which members have which roles
• Which members, or roles, are participating in what work
• Which members are employees of which contributing organi-
zation
These boundaries are important to building task and process
based trust between the members. Leaders who provide poor
definition of groups within the team may cause as much trouble
as if they are unclear about the team’s membership.
We will return to this aspect of team definition in the chapter on
the GRPI model, which outlines a hierarchy of team needs.
When Do Boundaries Change?
Is team membership, or a team’s internal boundaries, written in
stone?
22
The answer is no.

It is important for membership to change as little as possible.

Too much change will encourage team members to disregard
the stated membership and reduce their commitment to the
other members and to the team.

Likewise, if roles change too frequently members will lose faith

in their position within the team and the likelihood of being rec-
ognized for their skills and contributions.

However, that does not mean change cannot happen. If change

is predictable, reasonable and is not too frequent it is typically
accepted as part of the rhythm of teamwork. Change that is ac-
cepted as normal costs less in terms of productivity.

For example, project teams usually recognize that new phases

of the project are appropriate points of evaluation and change.
In the same way, a significant organizational change, for in-
stance by acquisition or new executive leadership, is typically
accepted as a reason for a team to be changed from outside.

Obviously there will be exceptions to that guideline. But control-

ling and moderating change should be a goal of the team.

23
Section 3
The Benefits
In This Section
1. The Benefits
2. Cohesion and Commitment
3. Shared Responsibility For Outcomes
4. Finding Information and Resources
5. The Cost of Coordination
6. Change Management
7. Control Vs. Collaboration
The Benefits
The benefits of clearly demarcating a team go first and fore-
most to the team members. These benefits often include:
• More rapid progress
• More successful efforts
• Improved morale
This section outlines some of the most valuable results of a
clear definition of a team’s membership. It is these results that
drive the overall benefits.
Cohesion and Commitment
Clearly defined team membership is a signal of commitment by
management. Team members who know they belong to a con-
sidered group are better able to contribute, more likely to self-
identify as members, and typically have greater commitment to
their goals.
In a sense, team creators recruit the membership. Essentially
everyone who could dedicate energy a team could also put at
least some of that energy into something else. The team that
24
values a member’s input enough to request or require it is mak-
ing it clear to the member that they are in demand.
All else being equal, being in demand is a good thing. It is a
kind of recognition of merit. Being recognized encourages a per-
son to participate and commit, despite other claims on their
time.
Likewise, team members see the recognition of their team-
mates. By seeing their teammates respond to that recognition
they have a way to measure their own time and energy contribu-
tions against those of the other members.
In a sense, with a clear understanding of who is on the team
you know who you are working for and who is working for you.
Of course, different people will respond to that information in dif-
ferent ways. But making membership clear is a good first step.
There is no question that making a team’s membership clear is
not going to magically generate participation on its own. How-
ever, it does increase the likelihood that the members will see
the value in committing their time and energy.
Shared Responsibility For Outcomes
Success is widely claimed, lack of success is not. Where team
membership is clear the team members own the outcomes. It
is easy to see how the clear assignment of members to the
team raises the stakes for the team members in a way that is
likely to increase productivity.
Finding Information and Resources
Clear membership in the team, as well as clear internal bounda-
ries, lowers the cost of finding information and obtaining re-
sources.
One of the key operational efforts of running a team is making
sure the members have what they need to do their work. How-
ever, it is impractical for a team’s leadership to obtain and direct
all resources required by team members.
In order for team members to find needed information and re-
sources themselves they need to know who they can turn to.
Which is to say, they need to know who is most accountable for
helping them. Most broadly, those people are their teammates.
If team members are not clear who is a member of the team
they may waste productive time during their search for re-
sources. The types of waste include:
• Spending time identifying team members, or others, with the
skills or knowledge to help
25
• Confirming that they are allowed to take the persons time
• Asking the wrong person because they are unaware of a bet-
ter option
• Not seeking help because they assume there is none avail-
able
Moreover, all of these problems do not just waste time, they
also weaken commitment to the team by suggesting to the
member affected that they will be less successful in their team-
work.
The Cost of Coordination
The cost of communicating with team members is a big part of
the time spent by a team leader. Team members also need to
communicate within the team, again at some cost.
A well defined membership puts an upper limit on these internal
coordination costs. Clear membership also makes certain that
all members receive needed communications, lowering the cost
of missed or catch-up coordination.
The cost of team coordination is covered in more detail in the
chapter on organizational networks.
Change Management
Scope creep, and other change issues, is harder to manage
when the boundaries of a team are fuzzy.
The reason is that every person involved is a potential source
of changes. Each person brings not only their own perspectives
and interests, but also those of the people who influence them.
In a sense, the people who influence the members of a team be-
come unacknowledged stakeholders.
Who are these influencers? Some examples include:
• The manager a team member reports to
• The friends of the team member
• People the team member wants to impress
All of these people, and more, may otherwise have no impact
on the team’s work. Limiting the number of people on a team
helps limit these outside influencers, and makes monitoring dis-
tracting influences easier.
Control Vs. Collaboration
26
Being under control is a requirement for an effective team. Like- • Concern that information might be transmitted beyond team
wise, free collaboration is required for success. The appropri- members in a way that would not be approved
ate degrees of control and freedom will, of course, vary accord-
ing to circumstances and goals.

Clear definition of the membership of a team helps focus both

control and collaboration. It is easy to see how a team with
fuzzy boundaries will be less controllable. The reasons include:

• A greater degree of divided loyalty on the part of some mem-

bers

• Greater difficulty in identifying who’s efforts must be under

team control

• The increased influence of non-team members, as discussed

earlier

Collaboration also becomes more challenging with unclear

membership. Reasons team members collaborate less easily
under those circumstances include:

• Uncertainty in who is participating

• Risk that a collaborator will be pulled away to other work

• Possible collaborators having an unpredictable amount of in-

terest in the effort

27
Section 4

Implementation Some Suggestions

This chapter looked at how teams are defined in terms of mem-
bership and the boundary between inside and outside. We out-
lined benefits that can be grouped under three headings:

• Shared commitment

• Lower coordination costs

In This Section
• Collaboration and change control

1. Some Suggestions In this last section we offer a few quick suggestions.

2. Privilege of Membership

3. Shared Responsibility Privilege of Membership

4. Recognition As we have said, and will say again, membership should be a
5. Brand Your Team meaningful recognition of value. But it should also be an exclu-
sive opportunity. Team members should have access to tools,
6. Internal Vs. External Communication information, access to people and other privileges that are
clearly not available to non-members.
7. Alignment Generates Collaboration
Make your teams’ membership limited. Keep the number of
8. Using MetaTeam
concurrent teams a person can participate low. Find ways to
say, the success of your work is important so we want you to
have the tools you think you need to make that happen.

28
Privileges cost money. Failed teams typically cost more. High
performance teams usually save money.
Shared Responsibility
After you have defined the team membership the next step in
further defining the team structure is to outline roles.
Role boundaries have a similar function to team boundaries. It
is important that every team member have at least one role. It
is also important that all the members have some role in main-
taining the team operations and performance in order for every-
one to take some responsibility for making the team successful
as a team.
It may help for some of the roles to be less formal and, most
likely, assigned for internal consumption only. Management
doesn’t need to know who has the Lunch Coordinator role, but
that kind of role is a useful way to make the concept of roles
have practical day-to-day implications.
We will discuss roles more in a later chapter.
Recognition
Recognition comes in many forms and at various times.
In this chapter we are only looking at big picture team struc-
tures. In that context we want people to see membership as rec-
ognition by management of their ability to contribute. Then fol-
lowing that, for their membership to be recognized as meaning-
ful more widely in the organization.
If that happens the team member becomes highly aligned with
team success, with the usual effect being commitment to giving
a strong performance.
In short, make it easy to find people, see their teams, and the
roles they are assigned.
Brand Your Team
Continuing further with recognition, consider branding your
team in some way. Your team brand may just be a name, or it
may also include a mascot, newsletter, Twitter feed, or other
way of attracting interest and keeping people’s attention.
Why do this? Because for team members to get access to exter-
nal resources requires interest and attention on the part of non-
team members.
29
Many teams feel they have their organization’s attention be-
cause their work is critical. However, even then, spending a rela-
tively tiny amount of thought and effort on the team brand might
make a meaningful, if marginal, difference in levels of support
when it counts.
Internal Vs. External Communication
Promote an internal communications style and rhythm that is
distinct from the team’s external communications.
Communications is often the most available way of creating a
space and identity for the team. Even if you are lucky enough to
be able to create a physical space for the team extending that
to internal communications will help team members focus on
their teammates and lessen outside influences.
Alignment Generates Collaboration
Once you have defined the team membership and the member-
ship of the team roles you have created an opportunity to use
role alignment to increase collaboration. If you habitually align
multi-person roles with multi-role work you are laying out the col-
laboration landscape in a way that scaffolds further less formal
collaboration.
We will look at role alignment more in the chapter on RACI ma-
trixes.
Using MetaTeam
To use MetaTeam to define your teams membership and roles
do the following:
• Log in
• Create a team from your My Teams page. Your new team will
be selected as your current team.
• Click the Roles button in the top nav bar
• Enter roles using the Add link at the bottom of the page
For more suggestions, tips and screenshots look in the
MetaTeam blog. The Team Organization and Organizational De-
velopment labels are good places to start.
30
 Introduction
The Third Skillset
GRPI
Risk Management
Decision-
Teams shown in an organization’s directory within MetaTeam making Tasks &
Responsibilities
SMART

Team Definition
RACI
Organizational Networks

31
GRPI Needs

3
An introduction to the
hierarchy of team needs
and its impact on team
performance.
Section 1

A Hierarchy of What Is Organizational Information?

Organizing teamwork requires more information than just a list

Concerns of team members. The core information teams need is about

structural concerns. At a high level, these concerns are usually
described as goals, roles, processes, and interpersonal rela-
tions.

In This Section
1. What Is Organizational Information?
2. What Is GRPI?
3. Why Is GRPI Important?
What is GRPI?
GRPI is an acronym for goals, roles processes and interper-
sonal. It is a model describing team needs for organizational
information.
The model arranges the four elements into a hierarchy. Goals
are at the top of the hierarchy, followed by roles, and so on.
The position in the hierarchy indicates how foundational the
type of information is.

That means that goals are considered to be needed earlier, and

are more important to team organization and functioning, than
roles are. More than that, the hierarchy suggests that defining,
for example, processes without setting up clear goals and roles
first is not likely to work well.

33
 This insight tells us that we will not only have an easier time
Why is GRPI Important?
troubleshooting at higher levels in the hierarchy, but that we will
GRPI tells us where to focus our attention first when organizing also solve more of the problems when we do it.
and operating a team. It also shows how to tackle problems
Further it means that in most cases interpersonal friction is
with the least amount of effort.
more an effect than a cause. Solve the higher, simpler prob-
The people who came up with GRPI did so by observing how lems and most people will find a way to get along.
teams work in the business world. They noticed two useful
things:

• Troubleshooting problems is easier the higher up the hierar-

chy they can be addressed

• Problems are typically caused by lack of clarity in roughly a

descending Pareto series

The first point is straightforward: clarifying goals is far easier

than untangling interpersonal relationships.

The second point is a bit trickier to understand and is more im-

pactful. It refers to the 80/20 rule. The point is that about 80% of
teamwork problems stem from unclear goals. Of the remainder
of problems, about 80% of those stem from unclear roles. Again
take the remainder and about 80% of those are due to unclear
processes. Whatever small amount is left is due to interper-
sonal issues.

34
Section 2
Goals and Roles
In This Section
1. What is a Goal?
2. What is Alignment?
3. Goal, Objective, Task, Work Package
4. What Happens When Goals Change?
5. What is a Role?
6. Assigning Work To Roles
7. Roles or Teams, Which Comes First?
8. Organization Role Vs. Team Role
9. What Happens When Roles Change?
What Is a Goal?
Goals are first and foremost the main outcomes a team is cre-
ated to achieve.
Teams encounter other less fundamental goals. They include:
• Organization strategic goals
• Internal team goals
• Informal goals
• Goals assigned to a member or members
Most goals are tangible. Others may be relatively abstract. All
goals should be concrete enough to be achievable.
We will examine the components of good goal setting in the
later chapter on SMART goals.
What Is Alignment?
All of the goals of any type for the team and its members must
be aligned. That is to say, goals must not compete. A team can
not realistically have goals where achieving more success in
one requires less success in achieving another.
35
The term alignment is also used to indicate how goals, roles, re-
What Happens When Goals Change?
sponsibilities and tasks converge, diverge or compete.
What happens when goals change depends to some degree on
the type of goal, and if the goal is:

Goal, Objective, Task, Work Package • Independent of other goals

These words identify work and may be used as synonyms. • Interdependent with other goals.
Equally, they may be defined to have distinct meanings, espe-
Change to an independent goal is typically simpler to handle,
cially for specialists. If your team uses similar words to identify
but the approach to both types of change is the same. Regard-
work you should define them to meet your needs.
less of other considerations, change to goals should be handled
The list could be expanded. For instance, MetaTeam uses the in a way that is accessible to all members.
word “todo list” for what might also be called a goal or work
If the goal is independent of other goals it is usually assigned to
package. Likewise, project managers often use the word “activ-
one or a few individuals, rather than the team as a whole. In
ity” where others may say “task”.
that case, the assigner may want to handle it with assignees
It is only important to clarify these terms if they are used to- without fanfare.
gether. If they are not commonly used together by the team or
For other goals, formal and informal, generally teams fare best
its management the meanings are probably not a problem that
by making adjustments with the whole team at one time when
needs to be addressed.
the members can contribute as needed.
In a later chapter we will discuss the differences between the
Teams may not spend as much time and attention on changes
words ‘task’ and ‘responsibility’, another common pair. We do
to informal goals. However, informal goals can be some of the
this in part because MetaTeam uses both words. But mainly be-
most important performance drivers, so treating them lightly has
cause they are often used interchangeably even though there is
risks.
a distinct conceptual difference.

36
Teams making adjustments to goals may also make noticeable
changes to roles and processes. If a goal is relatively central to
the team’s reason for existing, team members may find it worth-
while to explicitly check their assumptions about all related
structures.
This is often valuable regardless of how much other parts of the
team’s organization ends up needing to change. The overall
alignment check helps team members rebalance their thinking.
Each member has some attachment to the former goal that
they must switch to the revised goal, or to another focus point.
Doing that takes some amount of effort and time.
What Is a Role?
A role is a specific function carried out by a person within an or-
ganization or team.
Roles may be:
• Formal or informal
• Closely match job descriptions or be quite different from job
descriptions
• Match organization roles or be distinct from organization roles
Typically more than one of these characteristics are used in cre-
ating a team’s roles.
Diversity in terms of these characteristics is useful. The advan-
tages of having diverse types of roles may include:
• Increasing the distinctiveness of the team to its members
• Covering activities in the team that are not covered by
broader organizational roles
• Creating or highlighting specific value delivered by individuals
• Aligning with organizational norms addressing organization-
wide manageability, compliance or communication issues
• Lessening the cognitive load on team members that might re-
sult from too much difference between team roles and their
roles outside the team
Team members often have multiple roles within a team. Assign-
ing multiple roles can be a good idea because they create more
opportunity for:
• Recognition
• Alignment
• Directed collaboration
37

Assigning Work To Roles
Teams may choose to rely on roles more than on individuals.
For instance, assignments may be made to a role, regardless of
if there is only one member who has that role.
There are several benefits to relying more on roles than individu-
als. They include:
• Often team membership naturally changes over time so as-
signments to individuals are more brittle then assignments to
roles
• Roles can be specified before team members are found to fill
them
• Roles can be a buffer between assignments, reviews, exter-
nal reporting and individuals
• Work sharing and delegation of assignments may be simpler
when roles are used
Roles or Teams, which Comes First?
Team are often planned in detail before members are assigned.
When that is the case, usually some general roles exist before
team-specific roles are defined. Teams are created to achieve
goals so these pre-existing roles are likely to be aligned to the
work required.
Organization Role Vs. Team Role
Some roles required for a well-known type of team may be auto-
matically taken from the organization’s roles. In that case the
highest level team goals are defined after those particular roles
were defined.
An example of this is a product team formed to create software
automatically having the Software Engineer role. In this case,
the type of team and the standard roles for that type of team
are boilerplate. This is a good thing because it gives a level of
standardization across teams.
An earlier section said that teams should be distinctive opportu-
nities. However, large organizations must apply templates wher-
ever practical. Templates make effective corporate governance
and management possible.
In the usual case, once a team is operating it will have team-
specific roles. It will also specialize pre-existing roles to some
degree. This is a necessary part of members negotiating their
part of the work to be done. It also addresses those things that
set the team apart from other teams. Moreover, customizing
38
roles is an opportunity for the team to build its identity and the
commitment of the members.

What Happens When Roles Change?

When team roles change meaningfully the most important thing
is that the change is clear, widely known and accepted. Without
that the role’s value becomes impaired.

A meaningful change to a role will take hold better if it happens

with a bit of ceremony. That is to say, it should happen in public,
preferably face to face, and with a light but formal touch.

39
Section 3

Team Processes What Processes?

A process is a repeatable set of activities intended to produce a
similar output from each iteration. Teams operate using many
processes.

You may see better performing teams having more recogniz-

able processes then their less well performing peers. This
makes sense because strong processes are important to group
In This Section efforts because they:

• Add predicability that builds trust

1. What Processes?
2. Identifying An Important Process
3. Formal Vs. Informal
4. What Is a Norm
5. Is an Informal Process Like a “Norm”?
6. How Should Processes Be Specified?
• Are part of organizing repeatable work
• Can be systematically improved
Decision-making is perhaps the most fundamental team proc-
ess. Most teams start out as a blank slate. The initators make
decisions to get the team organized and more decisions to get
their work started.
Essentially all decisions are inherently multiparty. Because of
this, even if a team’s decision-making is not completely system-
atic it still becomes a process very quickly.

A few other areas of activity that tend to become processes in-

clude:

40
• Communications, including reporting
• Requirements gathering
• Tasking and the handoff of work
• Quality management
• Customer support
All of these and more are processes that may cause confusion
or conflict among team members if not well specified and the
specification accepted. They are all included in the ‘P’ of GRPI.
Identifying An Important Process
There are two easy ways to identify a process that is important
to satisfying the team’s GRPI hierarchy of concerns:
• Identify the most frequently repeating activities that are per-
formed member by member
• Look for repeated disagreements over how team activities
are being done
An example of the first is the specification of deliverables’ de-
tails created by a business analyst and handed to subject mat-
ter experts for validation, implementation and quality assur-
ance.
Formal Vs. Informal
Should informal processes be tightly specified? Typically not.
However, an informal process can create problems as much as
a formal one. Team leaders should pay attention to informal
processes and help align behavior with those that are important
to smooth teamwork. Intervention, if required, is probably best
done quietly and equally informally.
What is a Norm?
Team norms are expected behaviors. They are sometimes ex-
plicit, sometimes not. A rule is a limitation on behavior. A norm
is expectation for behavior. Referring to something as a rule
has stricter implication than referring to it as a norm. Despite
this, norms may be more important to performance than rules
because they frequently drive or inhibit:
• Commitment
• Effort
41
• Carefulness There are too many types of processes for this book to answer
this question in detail. Later chapters explore structured
Norms are an important part of smooth team functioning; al-
decision-making and risk management. Beyond those two,
though, we do not discuss them in detail here.
there are some straightforward rules of thumb. They include:

• Tackle the specification of a process early and directly

Is an Informal Process Like a Norm?
A process is not a norm. But following processes typically is a
norm, even a rule. Explicitly setting and updating norms should
be a regular process.
• Specify as needed, but as little as possible to avoid process
fatigue and lost productivity
• If a specification turns out to not be valuable, drop it early and
explicitly

Norms may include: • Specify processes collaboratively, where practical, and in the
open, again where practical
• A dress code

• Working hours

• Frequency of communications

• Taking part in informal team activities

These are not processes, though they are obviously also impor-
tant to manage.

How Should Processes Be Specified?

42
Section 4
Implementation
In This Section
1. Some Suggestions
2. Address GRPI Explicitly
3. A Depth First Traversal
4. GRPI Can Change
5. Processes Have Their Own Goals
6. Using MetaTeam
Some Suggestions
This chapter explored the GRPI model that describes a hierar-
chy of organizational concerns. We defined goals and roles
and looked at how they work together. Then we looked at proc-
esses and gave some simple rules of thumb for identifying and
defining them.
In this last section we offer a few quick suggestions.
Address GRPI Explicitly
It may help your team get off on the right foot if you explicitly
identify GRPI as the roadmap. Doing so sets expectations
around having a rational process for working well together that
offers dispassionate troubleshooting if there are problems. Set-
ting the expectation of a well organized effort is a first step to be-
ing well organized
A Depth First Traversal
Depth first traversal is a fancy, technical way of saying finish the
details of the first thing before moving on to the next. Using a
43
depth-first approach may help when you are booting up a team
for the first time.
After introducing the overarching team goal, and concept of
GRPI, consider working once through the hierarchy down to the
process level before continuing on to fully explore all the other
goals.
You probably wouldn’t want to cover all roles and all processes.
Instead you would want to highlight only the most important
roles − ones that tie everyone into the team. And then you
would want to identify a default, good-enough way of making de-
cisions.
What you are doing is providing just enough information so
there is a framework to support the members. That way as the
members move on to the rest of the goals, everyone already
has a basic sense of how they fit in and how decisions are go-
ing to be made in the early stages.
GRPI Can Change
Defining goals, roles and processes is usually a source of satis-
faction, but some team members may not like the way things
are, explicitly defined or not. When you lay down the team’s
goals, roles and processes remember to include a process for
changing them.
Change management processes are typically tightly interwound
with decision-making and communications, but change manage-
ment is not just about making decisions so it is best to address
it directly.
Processes Have Their Own Goals
Processes should align with the team’s goals. However, to align
team members expectations for a given process, it is often valu-
able to highlight the goal of the process itself. The goal of a
process is probably not the processes purpose. Rather it is the
desired outcome or outcomes.
For example, in a given team:
• A major goal might be the delivery of a software tool by a
given date
• A process may be handing off code from developers to qual-
ity assurance to move from the unit tested state to the integra-
tion testing state
• A goal of the process may be to make it possible for people in
the QA role to quickly identify what code is ready for handoff
44
 without them having confusion about what is actually ready • Click the Roles button in the top navigation bar to begin creat-
for testing ing roles and responsibilities

This last bullet, the process goal, is likely to be a high priority
for the people in the QA role and less of a priority for people in
the development role. If the process is not clearly specified
there is likely to be some amount of confusion, likely followed
by conflict if not addressed.
• Click the Decisions button in the top navigation bar to enter
and organize decisions
• Begin documenting your processes and terminology by click-
ing the Knowledge button in the top navigation bar

When a process goal is expressed, and the benefits understood

and accepted by all involved, confusion and conflict typically For more suggestions, tips and screenshots look in the
ends. If that alignment is hard to achieve it must be negotiated MetaTeam blog.
in some way.

Using MetaTeam
To use MetaTeam to create goals, roles and processes start by MetaTeam’s top navigation buttons show the GRPI concerns in order.

doing the following:

• Log in

• Select your team from your My Teams page

• Click the Todos button in the top navigation bar to begin creat-
ing goals

45
 Introduction
The Third Skillset
GRPI
Risk Management
Decision-
making Tasks &
Responsibilities
SMART

Team Definition
RACI
Organizational Networks

46
SMART
Requirements

4
How to specify goals in a
way that encourages team
performance.
Section 1

SMART What Is SMART?

SMART is an acronym for the ideal goal attributes:

Requirements • Specific

• Measurable

• Attainable

In This Section • Relevant

1. What Is SMART?
2. Is SMART Only For Goals?
3. Is SMART Only For Assignees?
• Time-bound
The information about the goal that meets these attributes es-
sentially states the requirements for success. A goal that is not
SMART is a goal with poor requirements definition.

Is SMART Only For Goals?

In general, the acronym SMART is only used in the context of
goal setting.

But what about other aspects of teamwork?

Responsibilities, in particular, are also a good fit for SMART.

Likewise, a task is also a thing that should be SMART. And,
again, the SMART attributes are required for a good risk defini-

48
tion. When you look, you can find a need for SMART in many
areas of teamwork.

Is SMART Only For Assignees?

SMART is clearly beneficial to assignees. A SMART goal is, by
definition, attainable and therefore aids the assignee’s success.
So, you could say that SMART requirements are in some ways
a benefit to the assignee and a burden for the assigner.

However, an assignment that can not be described as SMART

is one that is much less likely to result in success. No goal giver
wants a poor result to reflect back on them. The extra effort to
make an assignment that is SMART is a small price to pay for
the successful competition of the assignment.

Moreover, success in one assignment may improve the likeli-

hood of success in others. This happens because:

• There are often linkages between assignments

• Assignees’ future performance often improves with success

Teams perform better as the expectation of further success im-

proves members’ commitment to the team and their level of ef-
fort on assignments. SMART is the first step in that direction.

49
Section 2

Identification What Is Common Here?

The SMART attributes can be split into two groups:

• Identification

• Integration

The identification attributes are:

In This Section • Specific

• Measurable
1. What Is Common Here?
• Attainable
2. Specific
These attributes make sure that the assignee is doing a single,
3. Measurable real thing with an expected outcome.
4. Attainable In many ways, the three overlap. Can you imagine a measur-
able thing that is not specific? Perhaps you can, but it takes ef-
fort. Nevertheless, it is worthwhile to assess each individually.

Specific
The important thing to remember about being specific is that
completeness counts.

50
In general, as assignees, we want more than just specific in-
structions. In many cases we want a specific context. Likewise,
it is often helpful to also have specific facts that help us evalu-
ate the instructions and the context.
For example, a specific goal might be to create a hammer and
deliver it on Friday. A more specific instruction might be to cre-
ate a 5 pound hammer and deliver it on Friday.
However, in certain cases “measurable” could also mean:
• Rank orderable
• Perceptible indirectly
• Comparable using partial information
• Approximated to some degree of accuracy

However, with specificity often comes questions. It is reason- • The presence or absence of a range of indicative indicators
able to ask why 5 pounds and not 7 pounds. Equally, it be-
Basically, when an assignee does something meaningful you
comes reasonable to seek more information about what the 5
should be able to see an effect, soon or later, with a degree of
pound hammer will be used for because that may influence the
accuracy that allows you to know how they did. If that is not pos-
choice of material.
sible the effort was not meaningful.
In short, specificity is not limited to the instructions, but should
also extend to related information. The limitation as to how
much information you should provide is mainly common sense
Attainable
and practicality.
The main thing to remember is that attainability is not a static or
abstract thing, it is contextual. For a result to be obtainable you
need to not only say what is being attained, but also expand on
Measurable
who, what, when, where, with what resources, and maybe even
Measurable results require you to give an up-front definition of why. Those things determine attainability for a given team or
an approach and a scale. This may require creativity. In some team member operating in the real world.
cases measurement may not seem doable, especially for quali-
tative results or results that can not be measured in isolation.

51
52
Section 3

Integration What Is Common Here?

The Integration attributes of SMART help keep goals firmly at-
tached to the work of the team. They are:

• Relevant

• Time-bound

Like the identification attributes, they are closely linked and

In This Section
overlap to some degree.

1. What Is Common Here?

2. Relevant Relevant
3. Time-bound In the usual case, goals that are relevant are closely associated
with one of two things:

• Another team goal

• The organizational context that shapes the team’s reason for

existing

Let’s unpack the second bullet.

Teams have goals that are their reason for being. And there is a
reason that those team goals are desired by the organization.
The reason is itself a goal; although, it may not apply to the
team directly. Such indirect goals may include:
53
• Strategic goals ness is perhaps the most critical because it is in a sense more
specific.
• The goals of another group that requires the team to exist in
a supporting role For example, a team member may feel that a goal is not suffi-
ciently relevant. But he or she will usually realize that there
Regardless of the source of relevancy, it is important to create
could be information that they don’t know that makes the goal
an explicit link to it. The clear link helps team members remain
more relevant than it first appears. In contrast, the lack of a time-
focused on why they are working together. This is especially im-
frame is unambiguous. If there is no due date then there is sim-
portant if the negotiations between team members on how they
ply no due date.
will succeed become messy.

Time-bound
Time-bound means definite start and complete deadlines.

It is relatively hard to imagine a goal that is both relevant and

that may stretch out over an indefinite time. Such a goal would
invite procrastination and low prioritization, regardless of the
merits.

Moreover, a goal that is not time-bound can lower the sense of

urgency within the team in general. When this happens it tends
to have a negative effect on other goals as well.

All of the SMART attributes carry this possibility of contagion.

Getting them wrong often impacts other goals. However, timeli-

54
Section 4
Implementation
In This Section
1. Some Suggestions
2. Address SMART Explicitly
3. Write It Down
4. Keep It Simple
5. Use SMART As a Filter
6. Using MetaTeam
Some Suggestions
This chapter looked at how to create quality goals through the
lens of the SMART attributes.
In this last section we offer a few quick suggestions.
Address SMART Explicitly
As with any structured approach to work, it helps to explicitly
identify SMART as the guideline the team is following. Doing so
sets expectations and helps ensure that there are more than
one set of eyes on the problem of defining goals well.
Write It Down
This probably goes without saying, but you need to write up
your goals in an accessible place. When you do, you should
specifically include how they fit with the SMART attributes.
Keep It Simple
55
We will return to this thought over and over in this book: keep it
simple, short and sweet. There is no C for complicated in
SMART. After you are done defining a SMART goal try going
back and see if you can earn another S for simpler. If you can’t,
consider breaking the goal down into smaller goals, if possible.
• Click the Todos button in the top nav bar to begin creating
goals. By default MetaTeam calls goals “todo lists”.
• After creating a goal click its name to open it. Notice the four
date fields and the assignment drop-down. Also have a look
at the Criteria tab and the tabs for linking goals together and
for updates.

For more suggestions, tips and screenshots look in the

Use SMART As a Filter
MetaTeam blog. The Goals and Task Management labels are
Earlier in this chapter we pointed out that responsibilities can be good places to start.
SMART. That’s not all. While nobody wants to get a reputation
for being the SMART guy, it may pay to use the SMART attrib-
utes as a filter for many things. Decisions, risks, requirements,
skills, etc. can all be SMART. You may want to use the acronym
judiciously, but the concept widely.

Using MetaTeam
To use MetaTeam to create SMART goals start by doing the fol-
lowing:

• Log in
A goal with four tasks in MetaTeam
• Select your team from your My Teams page

56
 Introduction
The Third Skillset
GRPI
Risk Management
Decision-
making Tasks &
Responsibilities
SMART

Team Definition
RACI
Organizational Networks

57
RACI Levels

5
Using accountability to
better define roles and their
responsibilities
Section 1
Responsibilities
and Roles
In This Section
1. What Are Team Roles?
2. Why Do We Assign Roles?
3. What Are Responsibilities?
4. How Many Roles Should There Be?
What Are Team Roles?
In the chapter on GRPI we defined roles as:
A specific function carried out by a person within an organiza-
tion or team.
A function is one of two things:
• A type of work
• A symbol
Most often roles are associated with work. But in some cases a
role may primarily be symbolic. That is to say, an expression of
intent, encouragement or aspiration.
In this book we are mainly concerned with roles doing tangible
work.
A role collects a set of:
• Responsibilities
• Qualifications
• Expected contributions
59
 est form of work assignment. Broad assignments are ones that
Why Do We Assign Roles?
require the assignee to contribute more information to the defini-
Roles are definitions for how people fit into their teams. Roles tion and work with less oversight.
say what a person does, with whom, with what resources, for
The chapter examining tasks and responsibilities goes into
how long, and so on. This is a substantial amount of informa-
more detail on this.
tion. Collecting all that information and giving it a simple name
creates a role.

In the GRPI chapter we said it is important to explicitly define

roles. In the most basic sense that means saying what a person
will do for the team. Practically, this information becomes too de-
tailed for consistent day to day use without a simple descriptive
name.
Teams may give members multiple distinct functions. In general
this is a good approach. Tying each function to a clear descrip-
tive name helps explain why the member is doing a particular
thing. When a team make it clear why a person doing an action,
or offering an opinion, it decreases resistance to change and ter-
ritorial instincts.
How Many Roles Should There Be?
Again referring back to the GRPI chapter, there are advantages
to:
• Assigning multiple roles to individuals
• Creating roles that do not exist outside the team
However, this suggests that there will be a relatively large num-
ber of roles.
A large number of roles could be distracting, or they could be
easily absorbed. Which will occur depends in part on:

• If the roles are formal or informal

What Are Responsibilities?
• How roles are used conversationally
Responsibilities are one kind of individual work assignment. Vir-
• How flexible roles are understood to be
tually all work done within a team should be assigned explicitly
or implicitly in a coordinated way. A responsibility is the broad- • How frequently and well the team communicates
60
Basically, fewer formal roles, fewer references to them in nor-
mal conversation, and reasonable flexibility tends to make roles
feel like a help rather than a hinderance.

In addition, teams under certain circumstances may find fewer,

more formal roles more manageable. Those circumstances in-
clude teams that are:

• Balanced significantly across cultures

• Balanced significantly across organizational boundaries

• Having trouble maintaining constant, clear communications

61
Section 2

Levels of What Kind Of Responsibility?

In the context of team structures, a responsibility is the broad-

Accountability est form of work assignment. That means that a responsibility

is less specific then other forms of assignments, for example
tasks. We will return to the comparison of responsibilities to
tasks in a later chapter.

Because responsibilities are relatively broad teams may find it

In This Section useful to spell out how they are to be performed. Responsibili-
ties may be:
1. What Kind Of Responsibility?
• Continuous
2. What Is Accountability?
• Periodic
3. Defining Accountabilities
• Performed once
4. Choosing a Configuration
• Occasional
5. Levels of Accountability
Being specific in this way simplifies things for the assignee and
6. R, A, C and I it may reduce opposition from other team members.

What Is Accountability?

62
Accountability is another way to be specific about a responsibil-
ity. When we talk about accountability this way we are indicat-
ing a person’s liability for an outcome.
For example, a person who is responsible for making a picnic
happen is generally not held accountable for the weather. How-
ever, if the same person is held accountable for the success of
the picnic, come what may, they are likely to consider having a
tent available. They do this because they are now liable for
weather-related problems.
The change in character of the assignment is typically accompa-
nied by the threat of some kind of personal loss. Within a team
such a loss would most often be at the level of losing a role,
loss of face, or failing to get a good review.
Defining Accountabilities
Within a team there are several ways to position a member’s ac-
countability. They include:
• By implication or explicit assignment
• By formal or informal specification
For example, an employee review that takes teamwork into ac-
count may be an implied accountability that is informally de-
fined.
But if the same person has been told they will be reviewed
based on their teamwork the accountability becomes explicit
but remains informal, assuming no benchmarks have been set,
and no reward or punishment set.
If the basis for the same team member’s review is changed to
specify that a daily call with a remote team member is a metric,
the accountability for that call now becomes explicit and formal.
Choosing a Configuration
In most cases an explicit statement of accountability is more
productive than an implied accountability. A more explicit assign-
ment is more likely to be accepted and fulfilled. An implied ac-
countability is more likely to be unfulfilled. And remember, it is
difficult to apply accountability after the fact.
In contrast, an informally defined accountability may sometimes
be more useful than a formal definition. This will be true in only
some cases but is worth considering.
Informal accountability may be at once:
63
• More motivating The levels of accountability that are most often used are:

• Less demotivating • Responsible

More motivating in part because it carries more of weight of • Accountable

what amounts to peer pressure. And in part because less speci-
ficity may encourage a cautious over-fulfillment in some people, • Consulted
and a competitive response in others. • Informed
Less demotivating because a formal definition of accountability We define these levels here. In the next section we look at how
usually carries a reward, punishment mix that may come to be these levels, collectively RACI, are often used in organizing
seen as: teams.

• Punitive

• An unfair chance for greater rewards

R, A, C and I
Moreover, there is evidence that explicit material rewards and
punishments have an inconsistent power to motivate perform- Responsible
ance.
The responsible level is most often used to indicate the person
who will perform the main part of the work assigned.

Levels of Accountability Accountable

The accountable level carries the greatest weight of liability. It is

You may want to consider multiple levels of accountability. A
sometimes used to indicate a person who is overseeing work
level is the expected degree of involvement and liability. Levels
that may be done only in part by themselves.
are especially useful when multiple people share a responsibil-
ity. Consulted

64
The consulted level is generally used to indicate how informa-
tion flows.

A person who has accountability at the level of consultation

should think of it as a requirement for them to provide good in-
formation and counsel. It is also a requirement that they receive
any needed information and that their input is solicited.

Informed

The informed level, like consulted, indicates how information

flows.

The typical implication is that the person who must receive infor-
mation is an accessory to the work that created that informa-
tion. They may not be required to contribute. Nevertheless, they
have a degree of accountability due to their knowledge of the
effort.

Likewise, were they to not be given the expected information an

accountability would have been breached by the person who
should have passed the information to them.

65
Section 3
Assignment
Matrixes
In This Section
1. Assignment Matrices
2. The Roles Matrix
3. Responsibilities Matrices
4. RACI Matrices and Variants
5. A Project Managers View
Assignment Matrices
There are a few ways to implement assignments. They include:
• Person to person instructions
• Lists
• Grids or matrices
This section is concerned with matrixes.
A matrix is a grid where the X and Y show team members and
assignments. Boxes on the grid are marked to show who is re-
sponsible for what.
The choice of how to communicate assignments has impact be-
cause it shows or hides information. By showing or hiding infor-
mation it has an effect on team structure and operational clarity,
which affects performance.
People who advise teams or write standards often suggest us-
ing an assignment matrix. Matrices represent relatively egalitar-
ian and transparent team operations. This fact is usually left un-
stated.
In short, a matrix structure implies to team members that all:
• Are considered equals at least in the context of being as-
signed responsibility
66
• Have a right to know how responsibility has been divided be-
tween them
The Roles Matrix
A roles matrix has the team roles on one axis, and the team
members on the other. The roles displayed may include infor-
mal roles, but typically do not. Each intersection of a team mem-
ber and role shows that the member has or has not been as-
signed that role.
Multiple people may be assigned the same role. A roles matrix
may include an indication of which person takes the lead within
a role, if the team makes that distinction. Alternatively, and
more commonly, that person has a different or additional leader-
ship role, or the information is communicated informally.
A roles matrix helps cement the organization of the team mem-
bers into roles. It should be the foundation of how a member
finds individuals that may be able to contribute to their work. A
roles matrix is key to realizing the benefits of roles-based organi-
zation that we outlined earlier in this and previous chapters.
Responsibilities Matrices
A responsibility matrix has one of two basic forms. It has team
responsibilities on one axis and on the other:
• Team roles
• Team members
A roles to responsibilities matrix has several benefits:
• It is higher level, so easier to create and understand
• It reinforces the roles-based organization of the team
• It is less brittle in that membership changes do not necessar-
ily call for a revision and re-communication
An individual to responsibilities matrix also has advantages.
They include:
• More explicit accountability is conveyed to the assignee
• All team members see clearly who is responsible when multi-
ple individuals have the same role
Depending on circumstances, a team may use both types of ma-
trix, or just one or the other.
RACI Matrixes and Variants
67
A RACI matrix is a responsibility matrix where the intersection quired. It also works well at higher levels where collections of
of the grid convey the level of accountability of the assignment. tasks are used.

Teams most commonly use the RACI levels; however, other lev-
els, additional levels or different definitions are not uncommon.
Using the typical RACI levels will generally help team communi-
cations because of their greater familiarity.
However, we would not suggest using the PMI matrix as a pri-
mary team organization tool. An individual to task matrix, at any
level of detail, has drawbacks for organization. They include:
• Brittleness due to the assignment of individuals rather than
roles

A Project Managers View • Not reinforcing members’ roles-based position within the
team, thereby tending to weaken cohesion
Project managers with formal training have a slightly different
• A less clear and explicit distinction between tasking and the
and more specific view of responsibilities matrices. Their view
assignment of areas of responsibility, thereby tending to
follows a standard definition.
weaken self-direction
The Project Management Institute (PMI), a US-based organiza-
• The challenges of laying out and understanding a larger grid
tion promoting the project management profession, maintains
or multiple grids due to the use of tasks and individuals,
the US national standard project management body of knowl-
rather than the higher level responsibilities and roles
edge.
We return to the question of how to assign work in the chapter
The PMI standard calls for projects to work from one or more
comparing tasks with responsibilities.
Responsibility Assignment Matrix (RAM). The RAM maps tasks
to individuals. PMI suggests using the RACI levels, but points
out that other indications of accountability are possible.

Unlike a the other matrix forms this section describes, the PMI
RAM generally maps individuals to tasks. This is an approach
that has clear value in situations where detailed tasking is re-
68
69
Section 4
Implementation
In This Section
1. Some Suggestions
2. Standardize Where You Can
3. Equality Across Roles
4. Be Explicit and Informal
5. Using MetaTeam
Some Suggestions
This chapter discussed team roles and responsibilities in the
context of accountability. It outlined the value of matrix struc-
tures and explained the RACI accountability levels.
In this last section we offer a few quick suggestions.
Standardize Where You Can
Roles and responsibilities are particularly likely to be misunder-
stood because the same names are frequently used differently
across teams and organizations.
For example, your teammates have probably all worked with a
Project Manager role before. But all project managers are not
created equal.
As PMI takes pains to make clear, a project manager in a
purely hierarchical organization has very different authority and
responsibilities from a project manager in matrix organization or
a projectized organization. The difference may extend to
whether a project manager can fire you or not. That’s a signifi-
cant difference!
70
You can’t remove these differences completely, but standardize
where you can. If your organization has 4 teams and 3 of them
have a Software Developer role, it might be a good idea to do
likewise, rather than creating a Software Engineer role that
would be in essence the same thing under a different name.
Equality Across Roles
Treating similar types of roles equally makes them more useful
and reenforces the value of every role. What this means is that
all informal roles should be treated approximately the same re-
gardless of if they are internal to the team or external. Like-
wise, it is better to treat all formal roles similarly regardless of if
they are defined at the team or organizational level.
Be Explicit and Informal
Assign responsibilities explicitly with as much specificity as pos-
sible, with one exception: treat the consequences of success
and failure as informally as practical. The reasons to do this in-
clude:
• Overcommitting to a quid pro quo outcome involves usually
unnecessary practical and emotional risks to both sides
• Motivation is not necessarily something that can be trans-
acted; studies have found a weak correlation with hard re-
wards
• It is likely that a formal reward or punishment will crowd out
peer-to-peer reward or punishment; by contrast, leadership
support of peer-to-peer feedback has a force-multiplier effect
Using MetaTeam
To use MetaTeam to create roles and responsibilities matrices
start by doing the following:
• Log in
• Select your team from your My Teams page
• Click the Roles button in the top nav bar to begin creating
team roles
• After creating a role click its name to open it. Notice that roles
include not only responsibilities, but also links to goals.
(MetaTeam calls goals “todo lists” by default). Also have a
look at the Skills tab and the tabs for FTP planning and col-
laboration.
71
For more suggestions, tips and screenshots look in the
MetaTeam blog. The RACI and Roles and Responsibilities la-
bels are good places to start.

Introduction
The Third Skillset
GRPI
Risk Management
Decision-
making Tasks &
Responsibilities
SMART

Team Definition
RACI
The responsibilities matrix view within MetaTeam. Organizational Networks

72
Tasks &
Responsibilities

6
Identifying the differences
between tasks and
responsibilities and how to
use them well
Section 1

Work Management What Is Work Management?

Work in teams comes in a variety of shapes and sizes includ-
ing:

• Routine, unscheduled work

• Work that is uncommon

• Work that is internal to the team

In This Section
1. What Is Work Management?
2. The Spectrum of Self-direction
• Work involving mainly people outside the team
• Individual work
All of the types of work need to be assigned in some way.
When an item of work is assigned the assignee needs to be
told what the work is and how it should be done. Determining
who is assigned to what work that will be performed in which
way is the essence of work management.

The Spectrum of Self-direction

All work is ultimately self-directed. The degree to which an item
of work can be said to be self-directed varies. The spectrum of
self-direction is wide. At one end is work that is self-defined,
and self-assigned. At the other end is work that is specified

74
very tightly and where the assignee is monitored or instructed
as the work is done.

Nevertheless, even the least self-directed work requires that the

assignee be actively involved in doing it. The assignee may de-
termine the rate, quality or other aspects of the work. Therefore
work performance is to some degree determined by self-
direction.

This chapter is about determining where on the spectrum items

of work fall and how to communicate that information to the as-
signees in a productive way.

75
Section 2

Some Definitions What Is a Task?

A task is a unit of work that is specific and well-specified.

The word task is often used interchangeably with other words.

This can be done without too much confusion, as long as the
meaning is clear or can be made clear. Some of those words
include:

In This Section • Work item

• Goal
1. What Is a Task?
• To-do
2. What Is a Responsibility?
• Objective
3. Management By Objective
• Activity
4. Management By Responsibility?
The words goal and objective are often defined to be higher
level concepts. When a team does that the implication is that
something called a goal is less specific and more important
than a task. In common usage a task is limited in scope and
quite specific. This book occasionally uses “goal” and “task” in
this way.

In some situations tasks may have subtasks. Teams define

other attributes common to tasks as needed.

76
What Is a Responsibility?
The word responsibility is frequently used interchangeably with Management By Objective
task. However, there is both a common and a dictionary differ-
Management by objective is a commonly advocated way of
ence between the two. Separating the concepts adds to the clar-
managing individuals and teams.
ity of team organization.
In brief, the concept is that workers participate with manage-
In common team usage, the word responsibility tends to indi-
ment in goal setting and solution identification, and are then
cate either:
measured against the jointly specified outcomes.
• Something less specific and more self-directed, or
The benefits of management by objectives may include:
• A greater level of accountability
• Greater clarity in goal setting due to more focus on that activ-
In fact, these are complementary meanings. Often the more ity
self-directed the work, the more stringent the accountability for
it. • Better performance due to greater engagement of the assign-
ees with the work assigned, and more commitment to the out-
In dictionary terms, as it applies to teamwork, the word responsi- comes
bility is defined as an
• Increased quality of solutions and related decision-making
• A duty, or due to wider participation and more deliberate process

• An area of authority to act with limited supervision

In all of these usages the important commonalities are:

Management By Responsibility?
• A substantial degree of self-direction

• Less initial specification, meaning an amount of self-definition

77
Management by responsibility is a less commonly heard con- Using management by responsibility as the primary work man-
cept that is simply a recognition of how teams frequently oper- agement approach is a choice based on management goals.
ate. However, in some cases it may be strongly indicated by the cir-
cumstances or domain of the work.
At a high level, management by responsibility is when team
leaders focus on assigning of areas of responsibility that have
well-known performance threshold, but may not have detailed
solutions or even a known end state.

For example, a campus facilities manager may assign responsi-

bility for a building’s climate control systems to an employee.
He or she may provide limited detail of how the work is to be
performed. There might be no end date or deliverable. And the
manager may give the employee clear thresholds for the accept-
able status of the area of responsibility. This manager could be
described as managing by responsibility.

The benefits are similar to those for management by objective.

The main difference may include:

• Management monitors levels of ongoing performance, not dis-

crete outcomes

• Solutions and decision-making may not improve specifically

due to the practice if responsibilities are fully self-directed,
rather than problem and solution identification being tackled
jointly

78
Section 3

Task Vs. Does It Matter?

There are two questions we should answer about choosing to

Responsibility assign tasks or responsibilities up front:

• Does the choice matter?

• Does it matter what I call it?

The answer to does the choice matter is yes, it does.

In This Section
How you assign work changes how it is done. Moreover, how
1. Does It Matter? you assign one item of work will change how other items of
work are done, to some degree. Assigning work contributes to
2. A Simple Example how the team is structured and operates, as well as to the per-
formance of the individual.
3. How To Choose
The word choice also matters. What you call an assignment
4. Time Matters
helps set expectations about it. Using a clearly understood
5. Perspective Matters name, most often “task” or “responsibility”, is a cue. If the as-
signee understands in advance that a responsibility requires
6. Explaining Why Matters some initiative on their part, when they get a clearly labeled re-
sponsibility they know how to approach doing it.

A Simple Example

79
For example, if I am a software developer and my team leader
assigns me 5 things as part of a typical week:
• Design a tool to measure performance of 3 critical web pages
• Build the performance tool
• Build a test of the performance tool
• Document the performance tool
• Demonstrate the performance tool to the team
Because those 5 things are relatively specific, and because the
assignments are typical, it is likely that I will expect relatively
specific instructions for my next tasks in the following week.
But perhaps the following week my assignment is simply to
boost performance for all web pages. That broad responsibility
is likely to generate some amount of questioning in my mind as
to where my relatively specific instructions are.
The mental adjustment I would need to do to reorient myself
away from the expectation of more specific task assignments
and towards an area of responsibility may be relatively small.
However that adjustment is an incremental drag on my perform-
ance. Many such small drags add up.
Likewise, if I am usually given broad brush responsibilities, but
for some reason one week I am given only relatively specific
tasks I may have some adjustment to do before I can perform
at my typical level.
Both of these hypothetical situations suggest that people receiv-
ing assignments do better if they have expectations for, and
practice in accepting, the type of assignment.
How To Choose
When would you want to assign a task versus a responsibility?
The main question is, how much self-definition and self-
direction is right for the work? If a lot is wanted, assign a respon-
sibility. Otherwise, your intent is to assign one or more tasks.
Time Matters
When time is short usually we narrow down the effort to fit. In
that case, calling an item of work a responsibility will make less
sense to the assignee, regardless of how specifically you define
the work. Responsibilities are typically not single activities with
limited scope. More often they are longer duration with more un-
knowns.
80

Perspective Matters
Could an assignment look like a task to one person and like a
responsibility to another?
Yes. In fact that will frequently be the case. There are at least
two reasons for this:
• The person assigned sees more ambiguity in the work than
the assigner because they work in the details and face more
decision-making than the assigner is aware of
• The work assigned may stretch beyond the assigner’s expec-
tations because it takes longer or has longer term implica-
tions then originally assumed
These two common situations, sometimes combined, may con-
vince the assignee that the work is an ongoing responsibility
they have some directive control over.
Frequently, this shift in perspective is a good thing because it
encourages greater commitment and accountability with a
lighter touch.
Explaining Why Matters
People are affected by changes in teamwork. When a team
member receives a type of assignment that is different from re-
cent assignments, or perhaps different from any prior assign-
ment, it will tend to raise questions. The questions might in-
clude why now, why me, why is this approach better, and so on.
Moreover, the change in type of assignment may result in some
level of resistance. Typically a person will not like the two op-
tions equally in general we have a preference.
Perhaps the best way the person assigning can minimize the
distraction of these types of questions, and the possibility of re-
sistance, is to clearly state:
• What the expectations are for the assignment
• What circumstances caused this assignment to be a given as
a task or as a responsibility
• If this change indicates that going forward more assignments
will be of this type, and if so why
81
82
Section 4

Implementation Some Suggestions

This chapter looked at self-direction and different approaches to
work management. It defined tasks and responsibilities as two
distinct types of assignment with different benefits.

In this last section we offer a few quick suggestions.

In This Section
Be Very Clear About One-times
1. Some Suggestions Some responsibilities are performed one time. For example, or-
ganizing and running a special convocation of academics might
2. Be Very Clear About One-times
happen once with no repeat expected.
3. Separate Feedback From Instructions
Most do-once responsibilities will clearly not be discrete tasks,
4. Using MetaTeam However, some may be confused with higher-level goals. Other
one-time responsibilities may look a lot like narrow tasks.

As we said, how an assignee understands the type of assign-

ment makes a difference in how it is performed. To get the best
performance, be clear about how much direction and definition
the assignee should expect.

Separate Feedback From Instructions

83
It is often helpful to separate feedback on job performance from • Click the Add link at the bottom to create new responsibilities.
specific instructions about the work in question. Of course you They show in the matrix as you create them.
want to provide feedback about work product right there where
the work is defined. But feedback that ties into how a person is • Click a responsibility name to open it. Notice that you can as-
sign roles using accountability levels, expected hours and a
doing overall may be better delivered in an aligned role or area
percent share of the workload. You also see an indication of
of responsibility.
the way the responsibility is performed, dates and other
Anyone can have a bad day or a bad task. But a person’s over- fields, and collaboration tabs .
all performance is generally not determined by one day or one
For more suggestions, tips and screenshots look in the
task. Roles and responsibilities are the way we define a job, so
MetaTeam blog. The RACI and Roles and Responsibilities la-
that is, more often than not, where job feedback belongs. Keep-
bels are good places to start.
ing in mind that if feedback on a role considers performance on
specific high-level goals or narrow tasks the alignment between
the role and the goals or tasks should be made clear.

Using MetaTeam
To use MetaTeam to assign tasks and responsibilities start by
doing the following:

• Log in

• Select your team from your My Teams page

An open responsibility in MetaTeam.

• Click the Roles button in the top nav bar. Then click the Re-
sponsibilities tab. You should see three default roles listed, or
whatever number you have created yourself.
84
 Introduction
The Third Skillset
GRPI
Risk Management
Decision-
making Tasks &
Responsibilities
SMART

Team Definition
RACI
Organizational Networks

85
Structured
Decision-making

7
Outlines the benefits of a
consistent and repeatable
decision-making process
and the techniques for
implementing one
Section 1
Decision-making
In This Section
1. What Is Group Decision-making?
2. The Problem of Team Decisions
3. What Is Structured Decision-making?
4. How Does Structure Help?
5. Is Adding Structure Efficient?
6. Elements of Structure
What Is Group Decision-making?
Group decision-making is a process where a number of people
work together to choose among competing alternatives.
Decision-making is a large topic. There are many styles of par-
ticipation, techniques of analysis, and processes for resolving
and implementing. This chapter will cover some of the more
common issues and approaches teams face.
The Problem of Team Decisions
Team decision-making is complex, expensive and prone to fail-
ure. Let’s break that down.
Complexity
There are a number of ways team decision-making is compli-
cated by organizational factors. They include:
• Often decisions are only resolved after escalating through lay-
ers of decision-making, each with its own style, rules and set
of facts considered
• Teams have constraints due to geographic, time, language or
other differences between the participants
87
• Teams may not be able to include management in decision-
making, creating a greater risk of management’s full commit-
ment to the resolution being delayed, considered under differ-
ent facts or withdrawn. The result may be that members have
also have weak commitment.
As well as these organizational challenges, teams have the
same difficulties any group has in making decisions. Those diffi-
culties include:
• Managing stages of activity, including fact finding, collecting
alternatives, etc.
• Picking techniques of analysis
• Determining members’ involvement
• Implicitly or explicitly picking rules for how decision-making
progresses
• Prioritizing decisions
Expensive
Decision-making is always an expensive process. Even when
the resolution is low-risk, the process requires time and atten-
tion from team members.
Members’ time can be valued in dollars. It is difficult to assign a
cost to attention paid to decision-making but you can assume it
is high because there are only a limited number of things a per-
son can give attention to in a day.
As a simple example, say a team has 10 members. The team
averages five decisions per week involving all members. Each
decision averages one hour, including all analysis, every email,
time in face-to-face discussion, etc. That is 10 hours per deci-
sion. And let’s set the internal average all-in cost of a team
member hour at $55.
Given those parameters, every 12 months the team spends
$137,500 making decisions. That expenditure is on the process
itself, not the value of the resolutions.
One way of looking at it, in this example, is that the team may
be dedicating the cost of its highest paid member solely to
decision-making.
Failure-prone
Decision-making fails in many ways. Failures may prevent a
resolution, or the implementation may fail, or the failure be an
impact to the decision-making process more than to an individ-
ual decision.
Some examples of failure include:
• Errors in problem identification
88
• Missed or specious options
• Errors in analysis
• Poor participation of team members
• Low commitment to the resolution
• The process results in team-impairing conflict
• Errors in implementation or no implementation
• Triggering scope creep or scope reduction
Returning to the 10 person example team just outlined, let’s
now add the cost of failures. Say 20% of decisions do not reach
implementation, require re-deciding or lengthening the time re-
quired for a related decision. Set the value of those process fail-
ures to the cost of the decision so that the process cost dou-
bles.
Now the team spends $165,000 per year on process. That is be-
fore considering the cost of the ultimate success or failure of
the decisions.
One way to look at this result is that the team may have dedi-
cated the cost of its two lowest paid members solely to the
decision-making process.
What Is Structured Decision-making?
Structured decision-making is a general term for decision-
making processes that:
• Follow consistent and repeatable patterns of analysis
• Have transparent group deliberations in order to reach a bet-
ter decisions with greater commitment
• Is structured with the intent of successful implementations
Structured decision-making is often implemented using techni-
cal analysis methods from decision science. However, it also de-
scribes practices that are closer to negotiation and policy re-
view. The specific approach to structured decision-making is de-
pendent on the situation and subject matter.
We will look at how structured decision-making can help teams
making many low risk to moderately risky decisions in a typical
business context.
Teams making high risk decisions will typically have more spe-
cific needs.
How Does Structure Help?
89
A well-structured process attempts to maximize qualities that • That the style of decision-making, for example by consensus
lead to stronger decisions. Those qualities include: or by decision owner, is clear up front

• Repeatable steps • That time is allocated consistently among decisions regard-

less of outcomes
• Consistency in consideration
• That the basis for a decision, its criteria, will be specified
• Transparency of analysis clearly
• Fuller participation

• Having a clear goal-oriented context

Is Adding Structure Efficient?
• Well demarcated ownership and participation
In part, that depends on the types of decision and cohesion of
The benefits of these qualities are that the ways decisions fail the group. However, in most cases the answer is a clear yes.
we listed before are minimized, and that decisions are made
more quickly. The caveat is that a team must carefully and explicitly select
those elements of structure that are most practical for them.
Structure delivers benefits first and foremost by lessening foot-
dragging, conflict and bias. It achieves that by clearly signaling Teams must balance:
that the process is fair, practical and appropriate.
• More up-front work, and
The signals structure sends include:
• Less opportunity to take shortcuts
• That participants opinions and facts will be fully considered
against the longer term efficiency of:
without bias due to who they came from
• More robust decisions
• That the process for identifying alternatives and supporting
facts is predictable and consistent for all inputs • Higher value outcomes, and

90
• Less distraction and divisiveness

Elements of Structure
This chapter will look at some of the major elements of a struc-
tured process in a section on each. The elements covered are:

• Grouping

• Roles

• Criteria

• Ranking

• Cause and effect

• Implementation

91
Section 2

Grouping Why Is Grouping Important?

Grouping decisions is important for expectations setting. Specifi-

Decisions cally, grouping:

• Makes it easier to understand and prioritize the variety of deci-

sions teams typically face

• Clearly signals how types of decisions will be made and

In This Section which decisions are of which type

In addition, as with other types of work, grouping makes track-

1. Why Is Grouping Important? ing and reporting easier.

2. Common Ways Of Grouping

Common Ways Of Grouping

There is a large number of practical grouping axes. For the pur-
poses of expectations setting and consistency, some of the
main ones are:

• By individual responsible for the process

• By individual tasked with the final resolution

• By decision-making style; consensus, majority, leader-

decides, etc.

• By cause and effect

92
• By techniques to be used; e.g. voting, criteria analysis, etc.

• By deadline or subject

Many aspects of decision-making process are themselves deci-

sions. Teams need to address these issues early in their lives.

Grouping is one of these process decisions. For a consistent

and efficient process teams need to clearly say how decisions
will be grouped. Otherwise, determining the type of a decision
may itself become a deliberative process.

93
Section 3

Decision Roles Why Are Decision Roles Important?

Decision roles indicate the relationship of individual team mem-
bers to the process steps for a given decision.

What Roles?
In This Section There are five main sources of roles in a decision-making proc-
ess. They are:

1. Why Are Decision Roles Important?
2. What Roles?
3. Team Roles Vs. Decision Roles
4. Extending the Model
• The person asking for a decision
• The person who is responsible for a decision being made
• If the decision is one within a group, the person who is re-
sponsible for all of the grouped decisions
• If the decision’s cause is identified, those roles that are
aligned with that work

• For a complex decision, the assignees to activities or tasks

within the decision-making process

The first three roles are straightforward. The fourth and fifth
sources of roles are more nuanced.

94

Team Roles Vs. Decision Roles
The forth bullet speaks to team roles. When a decision is identi-
fied, it always has a cause. The work items that cause the deci-
sion are typically assigned to a role or to individuals who have
roles. Those roles are key stakeholders in that decision, as well
being the participants.
Fact-finder. The Fact-finder role may be charged with assem-
bling competitive specifications for the different ERP vender’s
products. Another role might be a Delphi Process Coordinator
role which would interview the company’s subject matter ex-
perts using the Delphi Process to normalize and improve the in-
put.

For example, in deciding which ERP system a company should

use, one of the roles involved in the decision may be the Ac- Extending the Model
countant Subject Matter Expert role. Picking an ERP system is
In high risk, highly contentious or long duration decision-making
typically a high risk, long duration decision. Our Accounting
the deliberative phase of the decision-making process may be
Subject Matter Expert’s main concern may be advising on the
best structured as its own team. This will help keep the
configuration of the ERP system that is chosen. But their input
decision-making process roles and responsibilities from becom-
to the system selection may be critical. Being clear about their
ing entangled with roles and responsibilities in the wider team
role in the selection will make sure their opinion carries suffi-
context. The additional clarity will improve the wider team’s func-
cient weight.
tioning, including the implementation phase of the decision.
The fifth bullet above describes decision roles. A high risk, long
When a team takes this approach it is creating a sub-team and
duration decision-making process often requires a division of
should follow the typical steps of identification, goal-setting,
labor. Roles help to manage divvying up the work, including the
roles definition, and so forth.
work of finding information and settling on a resolution.
Decision-specific roles may not be closely related to team roles
outside a given decision.

For example, in the ERP choice decision just described, deci-

sion roles are likely to be needed. On such role might be a

95
96
Section 4

Criteria What Are Criteria?

Criteria are requirements.

In goal-setting, criteria describe acceptable threshold values for

outputs. For example, a goal of reducing defects per million
parts might be 20%. If the team reduces defects by any number
greater than or equal to 20% they are successful.

In This Section In decision-making, criteria are used to select among alterna-

1. What Are Criteria?
2. How Does Criteria Analysis Work?
tives. So to continue the example, if the team needs to select a
Lean consultancy to help the effort, the number of associates
located in the Midwest might be a criteria. That criteria might
have a cutoff threshold value, or it might not.

3. How Simple Can This Be? In this example, the decision criteria helps select an input that
will help achieve a goal criteria. However, the input criteria and
the output criteria are not directly comparable.

How Does Criteria Analysis Work?

In decision-making, multi-criteria analysis requires the team to
identify what will best lead to a successful implementation. That
is to say, what factors of the decision improve the team’s
chances of meeting its overall goals. As these factors are identi-

97
fied, the team draws up a ranges of values, possibly including
thresholds. The factors and their value ranges are criteria.
There are many approaches to multi-criteria analysis. Some
use hierarchies of criteria. Other approaches use different crite-
ria comparison techniques, including weighting, pair-wise analy-
sis and other methods. In some cases the process emphasizes
quantitative measures, while in others relative or rank ordering
may be sufficient.
Likewise, teams may approach setting alternatives’ criteria val-
ues in different ways. Some of these include:
How Simple Can This Be?
Most teams make more decisions then they realize. Most of
those decisions are small and efficient.
In many decisions the need for efficiency doesn’t preclude us-
ing criteria analysis. However, it does argue for using the sim-
plest elements of criteria analysis for the majority of decisions.
Hierarchical criteria, pair-wise comparison, criteria weighting,
the Delphi Process, and other detailed approaches are all candi-
dates to be skipped in the majority of cases.

• Using independent external sources Instead, the bulk of decisions may require nothing more than:

• In an open collaborative process similar to caucus voting • A clear itemization of criteria

• Using a discrete approach like the Delphi Process or one that • Simple ranked or comparative values
is similar to a secret ballot
• A consistent, collaborative value setting process
• Selecting the most expert member or members of the team to
to assign a value to each criteria

Which approach works best will depend on the team.

One of the more important considerations is that team set its

members expectations for the approach early. The team should
do this before selecting a decision to work on.

98
99
Section 5

Ranking Why Is Ranking Decisions Important?

Teams rank decisions to identify the highest value decisions.
Teams face decisions with different levels of importance. A
team may need to focus on a few decisions to the exclusion of
others.

The best return on time spent may not be obvious. Moreover,

different team members may see the relative importance of deci-
In This Section sions differently. This can easily lead to friction, lost time, and
possibly a poor use of the remaining decision-making time.
1. Why Is Ranking Decisions Important?

2. How Do We Rank Decisions?

How Do We Rank Decisions?
3. Ranking Alternatives
The more consistent the ranking process the more likely team
members will accept it decision-by-decision and the more easily
the decisions will be evaluated for importance.

There are many approaches to ranking. All of them attempt to

remove the gut feeling approach.

The most common approach is for team members to apply a

simple questionnaire to every significant decision. In order for
ranking to be minimally distracting the questions should be:

• Applicable to essentially all decisions

100
• Simple, few and quickly answered
• Consider all important axes
Clearly these are somewhat competing objectives.
The five most common types of questions address the follow-
ing:
• How quickly is the decision required
• What is the cost of being wrong
• How many other decisions does this decision impact
• Will we know if we made the right choice
• What is the value of being right
There is some overlap in these questions, particularly in the
cost and value questions. In addition, they may not be equally
helpful for every decision. However, they cover the majority of
decisions and can be answered reasonably quickly.
Ranking Alternatives
Ranking also happens within many decisions. Frequently the
alternatives in consideration are few enough that ranking them
is not worthwhile.
In some case ranking is more important. This is generally true
when:
• The number of alternatives is large
• The differences between alternatives are not clear cut
• Multiple choices will be made as part of the resolution
In those situations the team needs to use at least one ranking
method. As with other aspects of the decision-making process,
teams should identify the method in advance of needing it. And
like all team activities, the method should be as simple as practi-
cal.
Some of the more common alternatives ranking methods are:
• Criteria analysis
• Voting
• Estimation calculations
• Averaged numerical rank
Criteria were covered in an earlier section of this chapter.
Voting
Voting typically takes the form of:
101
• One member one vote, or 3. Dividing by 6

• Zero or one votes per member per alternative
Other voting options include:
• Public or secret ballot
• One voting time or a prolonged open poll
Average Numerical Rank
This is perhaps the simplest approach. It sums the one to N
ranking of each alternative by each member to find the overall
ranking.

• Single cast or a votes that are changeable

• Multiple rounds of voting

Clearly the number of possible configurations is much larger

than most decisions require. The simplest straw poll is often the
best.

Weighted Estimates

A weighted estimate usually is done by canvasing team mem-

bers or subject matter experts for an estimates of the value or
rank of alternatives.

One approach is to use a formula. A well-known example is

PERT estimation. PERT is a project management technique. A
PERT estimate is done by:

1. Asking for the low, high and most likely values

2. Adding low, 4x most likely and high

102
Section 6

Cause and Effect Why Do We Make A Decision?

Teams make decisions in order to make progress against their
goals.

It is not uncommon for specific decisions to become disassoci-

In This Section
1. Why Do We Make A Decision?
2. Implementability and Implementation
ated from their goal. This mainly happens due to the decision-
making process not providing explicit links to a decision’s
cause.
Fixing the problem of disassociated decisions is relatively easy.
All significant decisions should be documented both to facilitate
deliberation and for future reference. Extending that practice to
clarify the goals driving the decision-making process requires
just two things.

First the team needs to clearly document the cause of deci-

sions. Second, the cause link needs to be integrated with crite-
ria, voting and other activities. Basically, the decision-making
process needs to be explicitly aligned with goals, and the mem-
bers need to be regularly reminded of the goals.

This may seem like a too obvious problem and a trivial solution.
However experience says that a surprising number of decisions
become fully unglued from their cause. Even more have one or
a few members become distracted from the reason for the
decision-making effort.

103

Implementability and Implementation
Decisions are decided to be implemented. That statement may
also sound obvious. However, in some cases, some or all of the
participants to a decision may not keep this in mind.
The reasons for this include:
• Decision-making that has become fractious causing partici-
pants to settle without focusing on implementation simply to
extricate themselves
• Participants moving on to other issues
• Participants wishing for implementation to fail for some rea-
son
• Designing a creative resolution may have become the object
for some participants
• The participants may not be including implementation factors
in their thinking or criteria
Some aspects of the need for of implementability are similar to
the concept of design for constructability in the building indus-
try. But in decision-making the outcome can be relatively worse.
This is in part due to the sometimes abstract nature of decision-
making output. In decision-making the team can not create a
definite blueprint, resulting in a more difficult assessment of im-
plementability.
Once getting to an implementable resolution, teams need to re-
main aware of the chain of events of decision-making. Success-
ful implementation requires that a team not only keep an eye on
the resolution, the immediate cause of the implementation ef-
fort, but also the original goal.
Without care, the chain of reasoning may become distorted.
The effect is much like a string can telephone relay that tends
to distort a message as it hops from station to station.
The approach to maintaining clarity during implementation is
similar to the approach a team uses to maintain the link be-
tween goal and decision-making. It is:
• Clear documentation, and
• Repeatedly reviewing cause and effect, as needed
104
 Introduction
The Third Skillset
GRPI
Risk Management
Decision-
making Tasks &
Responsibilities
SMART

Team Definition
RACI
Organizational Networks

105
Section 7

Implementation Some Suggestions

This chapter explored structured decision-making processes. It
reviewed some of the elements of structured decision-making
and the reasons for including them in the design of your team’s
process.

In this last section we offer a few quick suggestions.

In This Section

Address Decision-making Explicitly

1. Some Suggestions
Generally it is best to collaboratively outline the team’s overall
2. Address Decision-making Explicitly
approach to decision-making up-front. Teams should minimally
3. Take the STAIRS address how the process will deal with each of areas that are
discussed in the sections of this chapter. Those are:
4. Be Ready To Integrate
• Grouping
5. A Project Managers Perspective
• Roles
6. Using MetaTeam
• Criteria

• Ranking

• Cause and effect

106
Keep it simple, but be complete. Decision-making is one of the
parts of teamwork where careful specificity early on is most criti-
cal to productivity.
Take the STAIRS
When the team is preparing to make a distinct set of high-value
decisions you need a more specific model of how to do it. As in
all things, be explicit about the model. And make sure it links
into the overall decision-making process.
There is an acronym for the parts of any good model: STAIRS.
STAIRS stands for:
• Stages of activity
• Techniques of analysis
• Actors’ involvement
• Inputs needed
• Rules for moving through stages
If you write up this information you have a better chance of eve-
ryone committing to the resolutions.
Be Ready To Integrate
There are many source of information and guidance on
decision-making. We encourage you to use them. As you do
consider the overall approach of each.
Typically decision-making models lean in one of two directions:
• Effectiveness
• Correctness
Effectiveness is a focus on creating an implementable decision.
It is concerned with participation, commitment, and other hu-
man factors.
Correctness is a focus on creating the optimum decision. Its
concern is finding the best alternatives, using rational analysis
to choose between them, and using other decision sciences
tools and techniques.
Both of these biases in technique is needed. According to the
situation one or the other can be most needed. And many for-
mal approaches do try to balance effectiveness and correct-
ness. But you should be ready to integrate the two from the
best approaches you can find, as needed.
107
A Project Manager’s Perspective • The RAM

• The Scope Baseline

If you are PMI-oriented project manager you are familiar with
mapping out the inputs and outputs, and tools and techniques, The outputs may be:
of your processes. In that case, you may want to put decision-
making on the same footing that the PMBOK puts Risk Manage- • A Decision Management Plan
ment.
• A Decision Register
We discuss risk management in the chapter on risks. In that
• A Decision Log
chapter we make the case that risk management is a special-
ized form of decision-making. • Updates to the RAM

Not only is risk management a specialized form of decision-

making, but decision-making as a process is likely to be more
complex than risk management by virtue of:
• Greater breadth of scope
• Greater ambiguity in many decisions, and
• Less well-known roles and approaches
Treating decision-making as a project management process
means identifying its inputs and outputs. Using Risk Manage-
ment as a guide, we can make suggestions. The inputs you
might use include:
• The Risk Register
Using MetaTeam
To use MetaTeam to implement structured decision-making
start by doing the following:
• Log in
• Select your team from your My Teams page
• Click the Decisions button in the top nav bar.
• Click the Add link at the bottom to create new agendas to
group your decisions.
• Within an agenda, click the Add link to create decisions.

108
• Click a decision’s name to open it.

• Notice that you can add alternatives, set the decisions rank,
add criteria and use the collaboration tabs within the decision,
and within alternatives.

For more suggestions, tips and screenshots look in the

MetaTeam blog. The Collaborative Decision-making and Multi-
criteria Analysis labels are good places to start.

An agenda grouping three decisions within MetaTeam

109
Risk Management

8
Explains how risk
management is a special
form of decision-making
and how teams can plan
risk responses
Section 1
Risk Management
In This Section
1. What Is Risk Management?
2. What Is a Risk Profile?
3. Do We Really Need This?
4. How Little Can We Do?
What Is Risk?
A risk is a possible occurrence relating to a particular activity. In
the case of teams a risk is something that disrupts a team’s pro-
gress.
While the words “risk” and “disruption” are typically used for
negative events; however, risks can be good or bad. When we
say someone took a risk we imply that they accepted the possi-
bility of a bad thing to possibly get a good thing.
But keep in mind that the risk of winning the lottery and the risk
of being hit by a car are both disruptions with some probability
of happening. Minimizing disruption is often the goal, but some
teams actively attempt to increase the occurrence of positive
risks.
What is Risk Management?
Risk management is the process of deciding on a risk tolerance
profile, identifying risks, preparing responses, and managing
team activities to stay comfortably within the risk profile.
What Is a Risk Profile?
111
A risk profile can mean: have better results in the event a risk occurs. And being explicit
about risk management both relies on and contributes to good
• A tolerance or appetite for risk team structure.
• A level or pattern of riskiness

In this book we will use the term risk profile to mean a team’s
defined tolerance or appetite for risk. How Little Can We Do?
Risk management is one of those things where you do as little
as possible but you do it well.
Do We Really Need To Do This?
In other words, know:
Risk management is common in financial matters and is advis-
• Your team’s tolerance for risk
able for major projects, but what about for smaller teams? Do
small, informal, agile or highly stable teams need risk manage- • The meaningful risks you face
ment?
• The reasonable responses to the most meaningful risks, and
The answer is yes, at some level they do.
• How your day to day activities affect the team’s level of risk
All teams risk having members call in sick, win the lottery or get
Then stop.
hit by cars. Most teams have organizational risks that are out
of their control. But some of which are both common and can It may still sound like a lot, but it may not actually be a lot. If
be planned for. Examples of those range from a network out- there are two meaningful risks, five practical responses, and cur-
age to a snow day. rent work patterns don’t affect the probabilities in a significant
way, your risk management job is simple, quick and well done.
Risk management does not need to be a big deal for a small
team. But essentially all teams manage risk at some level.
Teams that are explicit about their risks and responses typically

112
113
Section 2

Risks Are Risk Management Is Decision-making

Risk management as an activity is a series of risk identification

Decisions and decision-making. The primary activity for identified risks is

first defining possible responses. Second selecting the one or
more of them that is most likely to address the risk satisfactorily.
If a risk occurs the team makes a final resolution as to which re-
sponse will be implemented.

In This Section
1. Risk Management Is Decision-making
2. Risks Are More Highly Structured
All the elements of a structured decision-making process are ap-
propriate to risk management. In some cases, common sense
may suggest that the terminology be different, but the activities
are essentially the same.
However, unlike decision-making, risk management is a proc-
ess that has been defined in detail by various standards and
professional bodies. A team’s industry or standards may deter-
mine which elements of structured decision-making should be
used, and what the terminology should be in order for communi-
cations about risk to be clearly understood.

Risks Are More Highly Structured

Risk management is a highly structured activity. It is often
suited to being organized as a sub-team with a different

114
decision-making process, different activities and roles, and so
forth.

Standards, as well as common sense, may call for specific

tasks for risk identification and implementation. Specific roles
and responsibilities may also be needed. Where that is the
case, greater separation may be mandated from outside the
team. Or the separation may just be at the discretion of the
team to keep things simple.

115
Section 3
Implementation
In This Section
1. Some Suggestions
2. Structure Risk Management
3. View As If It Were a Team
4. Using MetaTeam
Some Suggestions!
This chapter outlined the similarities of risk management to
decision-making. It left the details of common processes to the
standards and industry practices of teams work within, but pro-
vided a framework for thinking about risk management.
In this last section we offer a few quick suggestions.
Structure Risk Management
In the last section we examined risks as a kind of structured de-
cision. Likewise, risk management is a highly structured activity.
Just as we want a structured decision-making process for han-
dling risks, we also want a structured process for creating the
team’s risk profile, identifying risks and responses, and monitor-
ing day to day activities against the risk profile.
Going back to an earlier point, this need not be complicated.
Adding structure does not mean adding complexity, it means
adding organization.
View As If It Were a Team
116
The structure of risk management is much like that of a team. • Notice that you can add alternative responses to your risk.
There are goals, roles, areas of responsibility, tasks, and, of You can also set criteria for risk responses to meet, prioritize
course, decisions. the risk, and link it to preparation and implementation work.

If risk management is a substantial activity due to the team
working on high risk activities, separate out the risk manage-
ment process into a sub-team with its own status reporting.
The additional clarity may actually decrease the effort required
to manage risk. This especially true if the team’s information
systems do not add significant overhead to the separation of
concerns.
For more suggestions, tips and screenshots look in the
MetaTeam blog. The Risk Management and Collaborative
Decision-making labels are good places to start. If you want to
change the default Decisions labeling to better match the lan-
guage you use in risk management start with the Customization
label.

Using MetaTeam
To use MetaTeam for risk management start by doing the follow-
ing:

• Log in

• Create a risk management team from your My Teams page

Risks grouped in two of the typical risk assessment categories within MetaTeam
• Click the Decisions button in the top nav bar

• Click the Add link at the bottom to create agendas grouping

your risks

• Add risks a to one of your agendas. Click its name to open it.
117
 Introduction
The Third Skillset
GRPI
Risk Management
Decision-
making Tasks &
Responsibilities
SMART

Team Definition
RACI
Organizational Networks

118
Organizational
Networks

9
Exploring communication
in networks of team
members and how the
quality and content affects
productivity
Section 1

Teams Are Teams Are Networks

Team members are connected in a network of relationships. A

Networks team network’s relationships include:

• Reporting lines

• Accountability and authority

• Alignments and assignments

In This Section
1. Teams Are Networks
2. What Is an Organizational Network?
3. Is It a Social Network?
• Communication
• Process participation
• Skills, work experiences, interests and friendships
Team members and teams as a whole have similar relation-
ships across an organization.

What Is an Organizational Network?

Organizational networks are defined by the set of relationships
between people that result from how a team or an organization
works.

Networks exist in abstract form with or without computer sys-

tems. But this chapter is only concerned with organizational net-

120
work applications. Organizational network applications allow The goal is to support structured work activities that are known
team members to build team structures within a system all mem- to be effective. And to do it better than general purpose collabo-
bers of the organization have access to. ration, groupware, HRIS and scheduling software do.

An organizational network models team organization to provide

an explicit framework for activities that would otherwise be done
in an inefficient, opaque, and ad hoc way. Is It a Social Network?
Teams that use organizational networks to manage the struc- The answer is no.
ture of their work should expect to see benefits that include:
In common usage, social networks are systems that manage
• Less interpersonal friction due to a clearer definition of goals, sets of interpersonal relationships and informal largely unstruc-
roles and processes tured communications.

• More participation due to better visibility of members’ efforts Social networks typically focus on:

• Faster and better decision-making due to more a regular proc- • Interests

ess
• Friendships and acquaintances
• Easier access to resources and information due to visibility
into roles and responsibilities, skills and aligned work, as well • Questions
as more systematic knowledge management
• Streams of thought
• More effective communication due to standardized terminol- The so called business social tools do much the same thing,
ogy.
but typically with an additional layer of marketing, customer in-
• Channeled collaboration based on tasks and responsibilities teraction or idea generation.

Interests and friendships are part of work life too, of course.

However, they do not define an organization or tell us anything

121
about the structures that make organizations work. Rather, so-
cial activities co-exist with an organizational network, some-
times mirroring it.

Organizational networks have similarities to, and overlap with,

social networks. But they are not the same as social networks.

122
Section 2

The Problems of Noise, Confusion and Waste

Noise is extraneous information that degrades a communica-

Team Networks tions channel. Teams are noisy in the sense that a radio signal
can be noisy.

This section looks at well-known communications problems that

contribute to noise. The goal is to highlight how an organiza-
tional network can help. The last section of this chapter will of-
In This Section fer more suggestions about how to reduce team noise.

Sources of noise include:

1. Noise, Confusion and Waste
• Overlapping communication
2. Communications Overload
• Drift in meanings and intentions
3. Value Adding, Value Destroying
• Distractions from outside the team
4. Cognitive Limitations
• Duplicated information
5. The Problem of Distance
• Information that must be corrected
6. What Makes Us Communicate?
And on and on.

All of this noise generates confusion. Confusion creates ques-

tions and lots of avoidable little decisions. Questions and little
decisions are more noise.

123
Noise is something teams need to avoid. The costs of noise
add up quickly. They include:
• Less time for meaningful conversation
• Less free brainpower for innovative thinking and unexpected
opportunities
• Frustration due to incorrect or missing information
• Frustration and negotiation due to lack of clarity around
goals, roles and processes
• Rework due to poor communication
As with the sources of noise, this list could go on and on.
To quote a savvy start-up CEO on this topic, “unstructured col-
laboration is unproductive.” The reason, he said, is because of
the noise and general confusion it creates.
The other chapters of this book have discussed clarity in team
structure and operations. Clearly an organizational network that
makes these aspects of teamwork explicit and clear will cut
down on noise and confusion.
Communications Overload
Networks of all kinds require more communication the more
members they include. There are several equations that try to
quantify how the volume of communication increases as a net-
work grows.
In some cases an increasing number of possible communica-
tion channels is described as network value. In other cases, in-
cluding this book, increasing the number of channels is de-
scribed as a burden.
The most famous equation is Metcalfe’s Law. The law states
that the number of communication channels goes up propor-
tional to the square of the network membership. In numeric
terms it is:
• Multiply n times (n - 1)
• Divide by 2
What does that mean in practice? For example, if your team
has eight members then the number of lines of communication
is:
" 8 * (8 -1) ÷ 2 = 28
If you have nine members it goes up to:
" 9 * (9 -1) ÷ 2 = 36
And if your team grows to 12:
124
" 12 * (12 -1) ÷ 2 = 72
Although Metcalfe’s Law is most often invoked to highlight the
value of a network, in the context of teamwork you can see that
this is not a trend that increases efficiency.
There are two main ways to counter the increasing amount of
communications a growing team faces. They are:
• Broadcast information rather than communicate person by
person
• Provide members with a way to pull the information they
need, rather than pushing it to them
Both of these approaches can be enabled by something as sim-
ple as a whiteboard. But online systems do it better.
Organizational network systems are the most effective. This is
because they can remove at least one entire class of low-value
communication.
Removing low-value communications makes room for more
meaningful communications.
The class of communications that is removed is person-to-
person communications about team structures. For example,
rather than one member emailing another their role assign-
ments they can enter that information into the system. Later
questions about roles can then be answered by the organiza-
tional network, rather then person to person.
This isn’t to suggest that face to face discussions or two person
collaboration shouldn’t happen. Far from it!
What we are suggesting is that making team structures and
processes clear and easily accessible in an organizational net-
work reduces the number questions about those structures.
And those savings add up fast.
Value Adding, Value Destroying
Metcalfe’s Law is one way to measure a network. Another con-
ceptually simple approach is Beckstrom’s Law. Beckstrom’s
Law is also used to describe the value of a network. Like Met-
calfe’s Law it can be equally well seen as a measure of burden
or communications overhead. The measure is:
• Estimate the value of each possible pair of members
• Sum the values
When you look at the implied negatives you are looking at:
• Estimating the waste or value destroyed by each possible
pair of members
125
• Summing those values
Some people may have a gut reaction to this because they
don’t like to look on the negative side of things. That is quite rea-
sonable. However, the waste due to poor or unnecessary com-
munications is a fact of life. Typically teams accept it as a cost
of doing business. Some don’t even notice the loss because it
is so woven into doing business as usual.
Back on the positive side of things, an organizational network
can help by adding clarity through making team structures ex-
plicit. Removing communication negatives that way is adding
value.
To repeat what we said above, an using an organizational net-
work removes a class of communications about the structure of
team goals, roles, assignments, alignments and processes. Af-
ter the initial setup this information is available on a self-service
basis.
Without this support, questions, complaints, negotiations, and
office politics crowd out more valuable communications about
the work the team was created to do.
Cognitive Limitations
Dunbar’s Number is another useful concept for teams. The idea
is that people can only maintain a relatively small number of
meaningful relationships. The number is approximately 150.
At first glance, 150 relationships may sound like a lot, or any-
way sufficient, especially for teams that are typically much
smaller. However, there are two ways to look at this number
that are more concerning. They are:
• The 150 relationship limit applies to all relationships a person
maintains, not just those within a given team, and
• More worryingly, we can extrapolate that people can only
manage a relative small of relationships of any category, not
just person to person relationships
As we have highlighted in many ways in this book, teams are
full of relationships. They include:
• Relationships based on roles and responsibilities
• Assignments and alignments
• Decision-making relationships between people, and between
causes and effects
• And so forth
In that light, the number 150 feels terribly small.
126
Here again, the value of making relationships explicit in an or- the further away people are the more they disengage from one
ganizational network system is powerful. In this case, rather another. The exponential curve makes this a dramatic fact, but
than removing communications directly, the system allows you it also fits with common sense: you talk less to people you don’t
to stop maintaining these relationships mentally. see.

Instead, the system maintains the relationship information and Of course you can turn this around to say that the closer people
let’s you refresh your memory as needed. This frees your men- are the more they communicate. Architects, facilities managers
tal energy to focus on the details of the work, not the structures and HR professionals know this. They have been using geogra-
of the team. phy within buildings to encourage collaboration for a long time.

But many, if not most, teams are not 100% co-located today
and can not change their geography. Keep in mind that even
The Problem of Distance small companies with one location bring venders and consult-
ants into their teams regularly. It is almost as uncommon to find
There are many problems with working at a distance. Some of a team with no significant distance between its members as it is
them include: to find a team that is not to some degree cross-functional.
Given that, the Allen Curve is important to most of us.
• Time zones
There is, however, another way to turn the Allen Curve around,
• The tendency to respond disproportionately to local activity
at least in concept. What if you redraw the curve so that instead
rather than remote activity
of measuring the decay in communications with distance, you
• Less ease of access to resources show an increase in the frequency of communications?

And so on. Then the curve says that the apparent distance shrinks as the
parties communicate more. That is to say, their engagement is
However, one of the most important considerations is less tangi-
brought to a level that would be typical if they were physically
ble. It is the Allen Curve. The Allen Curve describes the expo-
closer. And indeed, that is what observations have shown.
nential falloff in communications as distance increases. In short,

127
 would choose to assign a role without using the organizational
network. There is no magic bullet. But some systems face
What Makes Us Communicate? fewer hurdles than others.

Of course increasing communication is easier said than done.
Many systems rollouts fail to get adoption. This is particularly
true of enterprise social and collaborative systems. The path of
least resistance for most people is to continue to do what they
already are doing, not to collaborate or be social how and
where they are told to.
Teams have an advantage in this area. Unlike the general popu-
lation within an organization, a team is a new purpose-built
structure where people know they are expected work together.
With adoption and constant use of the organizational network,
the team gets on the right side of the Allen Curve. However
much distance is between the members, the frequent communi-
cations tied to structural relationships will typically maintain a
substantially higher level of engagement in the work.
One of the best answers to the question of what makes us com-
municate is simply the goal-oriented work we do together.

A team’s structure can be used within an organizational network

system to channel collaboration through goals, roles, responsi-
bilities, tasks and processes. Those elements are fundamental
to teamwork. They can be, and should be, fundamental to col-
laborative communication too.

In this way, an organizational network can be closer to an ERP

system than to an enterprise social application. That is to say,
it can naturally become the system by which work gets done.
Therefore it will tend to face less of an adoption challenge.

No purchasing manager would choose to not use a company’s

ERP to make a purchase. In the same way, no team member

128
Section 3
Defining Your
Terms
In This Section
1. The Language Problems
2. Why Create a Domain Glossary?
3. The Challenges Glossaries Face
4. Using Common Terms
The Language Problems
Many teams face challenges around language. The four main
types of language problems are:
• Members being native speakers of different languages
• Members understanding a common language differently for
cultural or dialect reasons
• Difficulties in learning and standardizing the words used for
dealing with the work the team was created to do
• Differences in terms and usage members use for team struc-
tures and processes
Not all teams encounter all four problems in practice.
The first two of these challenges are straightforward to under-
stand and address. Teams typically settle on a common lan-
guage. They usually accommodate non-native speakers by writ-
ing and speaking simply, and with translation support where
needed and practical.
A word of caution, the second bullet may be more challenging
then it first appears for two main reasons:
129
• Differences in dialect, for example Texan vs. London English,
may not be picked up on early, and may be disregarded until
after problems appear that might have been avoided
• Dialects affect non-native speakers, compounding their com-
munications effort. For example some Chinese speakers
learn English from UK sources, not US English, due to his-
toric ties
Teams often handle the third and fourth bullets using glossaries
and in other ways normalizing their word choices early in the
team’s life.
Why Create a Domain Glossary?
Teams very often have difficulties learning and standardizing on
a common set of words used in their work.
In part this is because the majority of teams include specialists
from multiple domains with similar terms. For example two tech-
nologists may have very different definitions for the word
“schema”.
The difficulty is also frequently caused by the main domain sim-
ply being difficult for non-specialists. An example of this is an
MIS database administrator having a steep learning curve after
joining a medical records project to work with medical informati-
cists and physicians.
In addition, some team members may become frustrated when
the learning curve appears to be steeper for the main domain
then for their domain. This often happens because their domain
is less central to the work.
For example the database administrator we just mentioned may
become frustrated because physicians are relatively unlikely to
work hard at understanding the language, tools and techniques
of DBAs.
The Challenges Glossaries Face
Both of these issues may be helped, in part, by creating a team
glossary. However, glossary efforts are frequently started but of-
ten die out.
The challenges to overcome in order to avoid this problem in-
clude:
• Glossaries tend to be owned by a single person who must
make time for it outside of other work
• Team members need network access to the glossary for prac-
tical look-ups
130
• It takes effort on the part of a team member to lookup words
• Adding words to the glossary also takes effort
The first bullet may be the most difficult. A glossary that has just
one person working on it sends a signal. In general it suggests
nobody else feels the glossary is important enough for them to
make time to help.
The second bullet is closely related to the first. If a glossary
lives in an Excel or Word file members’ access will be poor at
best. When that is the case it is more likely that the glossary ef-
fort is limited to one person. The solution is to use a network ap-
plication.
The next challenge may be most important over the long term.
If a glossary takes significant effort to use, it will not be used.
Team members will more often lookup words when it is trivial to
do so.
Many applications and websites have demonstrated this by inte-
grating dictionary or web search into context menus, reference
links or text that shows when the user mouses over a word. But
when this type of integration is not available glossary use will
suffer, as will maintenance of the glossary.
Finally, if it is hard to contribute to a glossary members will not
continue to help develop it. When the effort required to add a
glossary term is low, more development and maintenance ef-
forts are forthcoming.
In brief, glossaries are good for teams, but to be successful you
must find a way do three things. They are:
• Involve the whole team in the creation
• Use a system everyone has access to that is productive for
glossary creation
• Use a system that allows team members to do as little as pos-
sible to get the benefits
These three requirements argue for a system that was purpose-
built, at least in part, for glossary creation.
In the case that you can not achieve those three things your
team may still find value in creating a glossary. But the effort is
most likely to be worthwhile for teams that are:
• Large or frequently changing
• Doing relatively high risk work
• Where leadership treats the effort as a first-class, planned in-
vestment
Teams not meeting those criteria may want to find other ways to
address standardizing their vocabulary.
131

Using Common Terms
Regardless of if your team creates a glossary, you still need to
spend some effort to use the same words to mean the same
things. As we said above, there are two areas to work on:
• Words from the domain the team is doing work in
• Worlds about how teams work
In both cases, most teams need to find ways to encourage
members to use the same words. How this happens will de-
pend on the team, its leadership and in some cases its manage-
ment.
The second of these bullets may seem less important then the
first. In fact, that is not always the case.
Smooth team operations depend on clear communications be-
tween team members. Referring back to the GRPI chapter,
team communications is a group of closely related processes.
When processes work poorly, tensions rise.
That tension may be within the team or it may include a team’s
management. The managers with oversight of a team are impor-
tant to team operations. They provide organizational support,
external communications and other assistance.
If management receives unclear information about team opera-
tions it is common for the team to lose degrees of independ-
ence. When that happens a team’s internal structures will
change in ways that may not be predictable or helpful.
As a common example, the terms “goal” and “objective” are fre-
quently used together. They:
• Are relatively hard to define clearly
• Have dictionary definitions that tend to reference each other
• Are likely to cause confusion that impacts members’ actions
That confusion could be highly damaging to a team. The terms
may be used interchangeably by some members or manage-
ment, while others use “goal” and “objective” to distinguish be-
tween less specific, less accountable targets and hard deliver-
ables. This could reduce the alignment of goals, roles and re-
sponsibilities. A team with poor alignment will always have rela-
tively poor performance, at minimum.
In the suggestions section of the chapter will will offer some
more ideas on how teams can build common, well-understood
vocabularies.
132
133
Section 4
Implementation
In This Section
1. Some Suggestions
2. Encourage a Team Dialect
3. Add Controlled Vocabulary To a Role
4. Make Your Tools Talk Like You
5. Focus On Action
6. Reduce, Reuse and Recycle
7. Work In the Network
8. Communicate Predictably
9. Using MetaTeam
Some Suggestions
This chapter outlined some of the challenges of team communi-
cations and the benefits of building the structure of teams explic-
itly in an organizational network.
In this last section we offer a few quick suggestions.
Encourage a Team Dialect
Close knit groups tend to have their own way of talking. This
can be the result of the group being cohesive, but it can also
help create cohesiveness.
Start by limiting the number of words you use for things, adopt-
ing shorthand terms, and defining simple words for common
items and activities. This will help add consistency, and make
the process of identifying and defining routine. It will also tend
to generate some amount of slang.
In all likelihood the process will leave your hands to take on an
informal life of its own, potentially leading to a more distinctive,
and beneficial, team-speak. But if not, you will at least have
added some amount of clarity.
134
Add Controlled Vocabulary To a Role
Those teams that decide to create a glossary need to avoid hav-
ing only one person do all the glossary building. At the same
time, you do want at least one champion to build momentum for
a common vocabulary. Also a successful glossary generally re-
quires some level of formal backing. Assigning the creation of
common vocabulary or a glossary to a role will help do this.
Make Your Tools Talk Like You
Wherever possible a team’s tools, particularly the organiza-
tional network, should be configured to use the same language
as the team and organization.
For example, if your team uses the word “goal” rather then “ob-
jective”, ideally so should your tools.
The reason to adapt your tools to the language of the team and
organization is to reduce mental load. It may not seem like
much, but if team members are constantly translating terms in
their heads, and verbally or in writing for other people in the or-
ganization, they are doing work that takes away from the work
the team was created to do. Small efforts add up, and small
negative productivities erode good feeling and performance.
Reduce Nuisance Communication
Reducing noise communication frees up time and energy for
more substantial collaboration. In Section two we listed some of
the sources of noise.
As we said, fully fleshed out team structures in an organiza-
tional network system will help cut down on the problem. Moreo-
ver, if members continually work to move information out of
email and into the system, the system can progressively take
more of the load.
The need to reduce noise and focus on more significant issues
is the same reason mass-market product and services teams
create FAQs. Some of the types of information are different, of
course. Questions about the roles and responsibilities of team
members would require better definitions, rather than simply
adding a question and answer to the bottom of a FAQ. But the
principle is the same.
Adopting this strategy requires two main things:
• All team members help fill in parts of the organizational net-
work when questions come up or things are unclear
• Continually urging members to check the network first before
asking questions or acting despite uncertainty
135
Either or both of these may cause some eye rolling at first, but
the effort to build the habits is typically worthwhile over the long
term.
Focus On Action
Observation has shown that teams, and especially virtual
teams, tend to build trust and enthusiasm around explicit and
limited tasks and task-oriented processes. Trust, enthusiasm
and progress do a lot to drive communications. Frequent com-
munications brings team members together, as we described.
This is a virtuous circle you should seek.
In addition, team members are better able to prioritize task-
oriented work with well-defined deliverables. Moreover, team
members prioritize work for different teams in part based on the
concreteness and do-ability of the effort.
Roles, responsibilities, decisions and even the team itself can
be closely aligned with tightly defined goals and tasks. Even the
name of the team can help set the expectations of a limited
scope and definite outcome.
Reduce, Reuse and Recycle
You can often work to minimize noise by increasing predictabil-
ity. Predictability tends to increase clarity, focus and efficiency.
A way to achieve this is to reuse what has worked for the team
in the past.
Wherever possible try to:
• Rely on existing role conventions
• Add new decisions to successful groups of decisions
• File documents systematically in hierarchies defined by
goals, roles, responsibilities, tasks and decisions
• Use the same format for assignments, goal definitions, deci-
sions, and so on
• Use only the most common words, and use them consistent-
ly—automatically linked to a glossary if possible
Work In the Network
Team member’s work should be fully defined within the organ-
izational network. Doing their work should be tied to those defini-
tions. When these things happen it is more likely that they will
spend significant time using the organizational network to col-
136
laborate with their peers. The higher the rate of communication
the less the distance separating members impacts their work.
Remember that essentially everything done in a shared network
is communication. For example, defining a role is a potent com-
munication to the team even before the assignment of that role.
Communication is king. Do as much meaningful communication
as is practical. Preferably keep it out of their inbox and in broad-
cast or pull channels like the organizational network.
Communicate Predictably
Increasing the predictability of communications reduces the de-
mand for more communication.
As a simple example, if a team leader sends team members a
regular update email, the members are less prone to worrying
that they don’t know what’s going on. Without that worry, they
less likely to fire off distracting emails to their peers within and
outside the team. If you can achieve the same effect without re-
sorting to email, so much the better.
Using MetaTeam
To use MetaTeam to create your organizational network start by
doing the following:
• Log in
• Create teams from your My Teams page
• Add members from your My Teams page using the Members
box in the upper right
• Find teams and people team members using the Directory by
clicking the Directory button in the top nav bar. Within the Peo-
ple tab of the Directory notice that you can use the member-
ship icon to the left of names to add or remove members from
your current team, if it is your team.
• To build the structure of your team, start by clicking the Todos
button to define goals, and the Roles button to add roles.
• To start defining words, click the Glossary button in the top
nav bar. To capture notes, processes and other information
click the Knowledge button also in the top nav bar.
• When you are ready to re-label MetaTeam terms your work-
space admin can right-click the terms you want to change.
Right-clicking a term opens its edit form. Click here to see ex-
amples.
137
For more suggestions, tips and screenshots look in the
MetaTeam blog. The Team Organization and Goals labels are
good places to start.

Introduction
The Third Skillset
GRPI
Risk Management
Decision-
making Tasks &
Responsibilities
SMART

Team Definition
RACI

An entry in the team glossary within MetaTeam Organizational Networks

138
© Copyright 2013, Altova GmbH. All rights reserved.

Image credits
Cover image: “Munsell 1929 color solid transparent” under creative commons license per: http://commons.wikimedia.org/wiki/File:Munsell_1929_color_solid_transparent.png
 This book was distributed courtesy of:

For your own Unlimited Reading and FREE eBooks today, visit:
http://www.Free-eBooks.net

Share this eBook with anyone and everyone automatically by selecting any of the
options below:

To show your appreciation to the author and help others have

wonderful reading experiences and find helpful information too,
we'd be very grateful if you'd kindly
post your comments for this book here.

COPYRIGHT INFORMATION

Free-eBooks.net respects the intellectual property of others. When a book's copyright owner submits their work to Free-eBooks.net, they are granting us permission to distribute such material. Unless
otherwise stated in this book, this permission is not passed onto others. As such, redistributing this book without the copyright owner's permission can constitute copyright infringement. If you
believe that your work has been used in a manner that constitutes copyright infringement, please follow our Notice and Procedure for Making Claims of Copyright Infringement as seen in our Terms
of Service here:

http://www.free-ebooks.net/tos.html
3 AUDIOBOOK COLLECTIONS

6 BOOK COLLECTIONS