Section 2
Goals and Roles
In This Section
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.
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?
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 can9. What Happens When Roles Change?
not realistically have goals where achieving more success in one requires less success in achieving another.
The term alignment is also used to indicate how goals, roles, re- sponsibilities and tasks converge, diverge or compete.
Goal, Objective, Task, Work Package
These words identify work and may be used as synonyms. Equally, they may be defined to have distinct meanings, espe- cially for specialists. If your team uses similar words to identify work you should define them to meet your needs.
The list could be expanded. For instance, MetaTeam uses the word “to do list” for what might also be called a goal or work package. Likewise, project managers often use the word “activity” where others may say “task”.
It is only important to clarify these terms if they are used together. If they are not commonly used together by the team or its management the meanings are probably not a problem that needs to be addressed.
In a later chapter we will discuss the differences between the words ‘task' and ‘responsibility', another common pair. We do this in part because MetaTeam uses both words. But mainly be- cause they are often used interchangeably even though there is a distinct conceptual difference.
What Happens When Goals Change?
What happens when goals change depends to some degree on the type of goal, and if the goal is:
• Independent of other goals
• Interdependent with other goals.
Change to an independent goal is typically simpler to handle, but the approach to both types of change is the same. Regard- less of other considerations, change to goals should be handled in a way that is accessible to all members.
If the goal is independent of other goals it is usually assigned to one or a few individuals, rather than the team as a whole. In that case, the assigner may want to handle it with assignees without fanfare.
For other goals, formal and informal, generally teams fare best by making adjustments with the whole team at one time when the members can contribute as needed.
Teams may not spend as much time and attention on changes to informal goals. However, informal goals can be some of the most important performance drivers, so treating them lightly has risks.
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 organization 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 creating a team's roles.
Diversity in terms of these characteristics is useful. The advatages 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 result from too much difference between team roles and their roles outside the team
Team members often have multiple roles within a team. Assigning multiple roles can be a good idea because they create more opportunity for:
• Recognition
• Alignment
• Directed collaboration
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 individuals. They include:
• Often team membership naturally changes over time so assignments 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, external 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 automatically 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 opportunities. However, large organizations must apply templates wherever 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 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.
Section 3
Team Processes
In This Section
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?
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 recognizable processes then their less well performing peers. This makes sense because strong processes are important to group efforts because they:
• Add predicability that builds trust
• Are part of organizing repeatable work
• Can be systematically improved
Decision-making is perhaps the most fundamental team process. 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 systematic it still becomes a process very quickly.
A few other areas of activity that tend to become processes include:
• 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 matter experts for validation, implementation and quality assurance.
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
• Carefulness
Norms are an important part of smooth team functioning; al- though, we do not discuss them in detail here.
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.
Norms may include:
• 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?
There are too many types of processes for this book to answer this question in detail. Later chapters explore structured decision-making and risk management. Beyond those two, there are some straightforward rules of thumb. They include:
• Tackle the specification of a process early and directly
• 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
• Specify processes collaboratively, where practical, and in the open, again where practical
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 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 satisfaction, 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 integration 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 hand off without them having confusion about what is actually ready for testing 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.
When a process goal is expressed, and the benefits understood and accepted by all involved, confusion and conflict typically ends. If that alignment is hard to achieve it must be negotiated in some way.
Using MetaTeam
To use MetaTeam to create goals, roles and processes start by doing the following:
• Log in
• Click the Roles button in the top navigation bar to begin creat- ing roles and responsibilities
• 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
For more suggestions, tips and screenshots look in the
MetaTeam’s top navigation buttons show the GRPI concerns in order.
• Select your team from your My Teams page
• Click the Todos button in the top navigation bar to begin creat- ing goals
