Communication. When someone has authority to make decisions, at some point they need to communicate those decisions (or their effects) to others who will use that information in making their own decisions and taking their own actions.

Sharing roles. More than one person may take on a role. For example, a role that involves providing support to a customer may have more work than one person can do. When people share a role, they have a responsibility to coordinate their work so they give consistent answers or make consistent decisions. That they share the role should be clear to all the people involved and to people who may need to work with them.

Inadvertent overlap in roles can lead to errors. If two people both believe they have the authority to do a certain bit of work, but they are not aware they are sharing the role, they can make conflicting decisions, tell others conflicting information, or produce conflicting artifacts. Each of these situations can lead to errors in the system being built or in the way the team operates.

Delegation. Authority and responsibility can be delegated. Delegation means that one person confers some part of their role to someone else, possibly for a defined period or with restrictions on the kind of authority granted. The delegation might transfer the role from one person to another, so that the first person no longer fills the role (perhaps temporarily). Alternately, the role may be shared with the other person, in which case both people are responsible for the work and for coordinating with each other. A delegated role might also be rescinded.

One way to use delegation is for one person to have the overall role for some system component, and for that person to delegate responsibility for specification to someone skilled in specification, delegate design to a designer, and so on. The person with overall responsibility for the component typically reserves authority to review and approved work that has been delegated to others.

Resilience. A well-functioning team is able to handle problems when they arise. A team’s resilience depends in part on how authority is structured within the team.

There are several kinds of problems a team will encounter:

• Someone being unavailable for a while or leaving the team; for example, when someone becomes ill for a while. Handling someone becoming unavailable involves allowing for redundancy in role assignments, and having one or more people who can take over when someone is unavailable. This implies that the person who takes over will know what they need to know—meaning there is communication before something happens.
• Someone making technical mistakes. When this happens, the mistake must be detected, then resolved, then steps taken to reduce the risk of similar mistakes happening again. This typically involves defining procedures to review work to catch mistakes, and assigning someone the role to check that the reviews have happened as well as assigning others roles to perform reviews. (This is related to Section 8.2.6—Principle: Build in checks.)
• Someone making operational mistakes. This is similar to a technical mistake, the effects of an operational mistake can affect how a team works, not just the system itself. Some operational mistakes reported by whistleblowers have legal implications. In many organizations, this includes giving someone a role to hear reports of problems from anyone in the organization, and then act on the report.
• People having disagreements. Handling disagreement usually involves giving some third party a responsibility to hear about disagreements and authority to resolve them.

There are patterns in common to how many of these problems can be planned for. Providing redundancy in how authority is organized is at the core: planning in advance for someone to take over important roles when needed, building in checks of work, and assigning roles that create alternative communication paths to resolve problems. All of these in turn depend on communication so that someone can take over a role or check work.

Formally, these kinds of structures add nuance to the definitions of scope for the roles that need to be resilient. For example, three kinds of roles are defined to catch and resolve technical mistakes: the role to do the work, the role to check it, and the role to ensure that the check is done. These imply a limitation on the authority of the first role to make any arbitrary decision about the work, because the work must be checked by someone else. It adds a responsibility to ensure that the work is reviewable (for example, adequately documented) and that the relevant artifacts are communicated to reviewers. Similarly, having someone who can take over a role implies that someone who is a backup for the work is responsible for keeping current and stepping in when needed—and also refraining from acting on the role when the regular person is doing their job.

Who is responsible? The responsibility for making the team work is spread over everyone in the team.

Looking at the team as a control system, there are two reciprocal classes of roles: the roles that fill controller functions and those for everyone on the team (the controlled process).

Everyone on the team has the role of being a team member. This role has the responsibility of following team norms and procedures. In terms of a control system, each person is responsible for accepting and following instructions from the controller, and for providing feedback about work and about how the team is functioning. In particular, when anyone on the team detects that there is a problem in how the team is functioning, they are responsible for communicating about the issue with someone whose role includes resolving the issue.

The controller part of the control system can be broken down into three classes of roles. These are:

1. The observer role: a person who receives feedback in the control system, meaning they observe how team members are doing their work and are responsible for deciding when there may be an issue to resolve.
2. The decider role: a person who is responsible for deciding how to respond to an issue; that is, for deciding on a control action that should address whatever situation has occurred.
3. The exceptional role: a person who is responsible for detecting problems with the normal control system roles or for receiving reports about them. This role comes into play when the normal observer and decider roles are not handling a problem. When someone reports a problem with the control system, it is sometimes called a skip-level or whistleblower report.

These roles can be used to support many different team structures. For example, a traditional hierarchical department/team structure can be represented by each department’s or team’s manager filling the observer and decider role for their department or team. The manager over a manager can fill the exceptional role to address problems with a manager’s work. Separately, many organizations create an explicit whistleblower function to address potential corruption or illegal behavior; the people in this function then fill part of the exceptional role.

Process model. This model is how the controller understands both the objectives for the team and the state of the team.

The process model includes the team’s objectives and how well the team is meeting them; its structure, and how people are working with that structure (or not); the roles each person on the team has and how they are progressing on the work associated with those roles; and generally how well each person is doing.

The observer and decider roles use this information to determine when part of the team is how working as it should, and to decide what steps to take to make things work better.

Unlike the control system for a machine, the process model for a team accounts for the well-being of the people on the team.

The process model also needs to consider what people on the team actually understand of the team’s culture and procedures, and their roles. In managing a team of skilled and well-meaning people, I have found that miscommunication or misunderstanding is the most likely source of problems.

Control decisions. Those people who have the decider and exceptional roles are responsible for deciding when there is an issue to be addressed, and what actions to take. Sometimes when there is some indication of an issue, the choice will be to wait and gather more information.

Some issues may appear in one part of the team but, on investigation, will be found to have causes in other parts of the team. If the decider or exceptional role is shared among multiple people, decisions will require deciders working together.

Problems in team execution can arise because the team has outgrown their current structure, not because any one person is behaving wrongly. I discuss this further below.

Control actions. The control actions are how people influence the team to keep it working on track.

The example set by a team’s leaders is perhaps the most important influence. If someone the team looks up to is doing some activity one way, they will be likely to follow: if someone is seen to be careful following a procedure to get design reviews, for example, others will be motivated to do so as well.

This raises the question of who is considered a leader. Leadership is a social construct; it is not necessarily an explicit role that someone in the team is given. People who are given roles with extensive scope of authority and responsibility are often seen as leaders. Others who are understood to have experience, who mentor other team members, and who establish social connections are also treated as leaders. Having this level of social influence in the team comes with a responsibility to model desired behavior, and should be considered when taking action to fix a team performance issue.

Instructions from one person to another based on scope of authority are a second kind of control action. If someone has a role of managing a subteam, the manager (who has a decider role) can instruct someone on the team to change their behavior. The instruction need not be hierarchical; for example, when two people are peers working on designing related components and are expected to come to agreement on how those components will interact, one of them can inform the other that they will not agree to some part of an interface design.

As I noted in the sidebar on delegation and micromanagement above, there are choices to be made about how instruction should be given. It can be directive, telling the recipient exactly what they should (or should not) do. This is appropriate when related to following a procedure that requires precision, such as operating test equipment that has the potential to cause injury. In other situations this can turn into micromanagement and inhibit the recipient’s ability to improve and work independently. On the other hand, the instruction can take the form of letting someone know that there is a problem and letting them work out how to address the problem. This approach helps the recipient learn and grow, especially if they can discuss potential solutions to get feedback. However, if the recipient is not able to figure out how to make a change, this approach will leave a problem unresolved.

Next, a decider can address an issue through education. Mentoring someone about part of their work can improve their work in the long term as well as addressing an immediate issue.

Finally, sometimes the appropriate control action to address an issue is to change the team’s structure. This can happen as the team grows and authority and communication structure reaches a scalability limit. It can also happen as a project transitions from one phase of work to another—for example, when moving from the initial design and implementation into preparing for placing the system in operation.

Team member behavior. The people on the team make up the controlled process in this approach. A controlled process receives communication from the controller with input that is intended to change the process‘ behavior. The process then generates feedback to the controller as it goes about its behaviors.

The team being made up of people, not machines, so they hear and act in a human way to communication from people in the controller role. When the team’s structures are designed, the ways that people communicate should be worked out so that those who are giving instructions know how to communicate to people, and so that people on the team know how to tell when instructions are being delivered.

People react when they receive instructions or assignment, of whatever kind. In a well-functioning team, the team members will act to confirm the instruction they think they are receiving, then adjust their work behavior accordingly—changing the roles they are working on, adjusting some technical work, and so on.

However, real humans don’t always neatly follow this behavior. Sometimes they misunderstand the instructions. Sometimes they ignore the instructions. Sometimes they develop resentment at the instructions. The communication between people with a controller role and the people on the team must include checks to catch misunderstandings, and continuous communication so that leaders understand how people in the team are feeling about their work.

The controller needs feedback from people on the team in order to continue to make accurate control decisions. In a team, this means that people on the team are providing information. The people have a responsibility to keep those overseeing their work informed of their progress. They are also responsible for communicating when they are dissatisfied with their work situation, or when they observe issues with the project.

Feedback. The people forming the control system have several ways to get feedback and observe the team. Some of these mechanisms can be designed into the system formally; others are informal behavior by the people with control roles.

Getting explicit feedback and reporting from team members is the first formal mechanism. As people on the team make progress on different tasks, they inform the controllers of the work completed, the problems found, and the steps yet to do. These reports can take many forms: updates to a task tracking system, regular status communications, and informal discussions. Explicit reporting has the advantage that it can occur regularly and in a form that encourages documentation of status. It has the disadvantage that it can become impersonal, and the reports can become inaccurate (especially optimistic) over time because team members want to look good to their teammates.

Someone in a controller role can complement these explicit reports with regular informal communication. Some organizations have advocated “management by walking around”, in which a manager informally talks with those who they oversee, without a regular schedule. This interaction ideally happens in person, so that the manager and the team member can treat each other as people and build up social bonds. In person communication also has the advantage of the full range of communication methods, such as body language. These informal communications have the disadvantage of not producing a documented record of what was learned, and if done clumsily they can lead to a team member feeling like they are being constantly monitored.

A well-designed team will account for problems in communication between a team member and those who oversee their work directly. A team can build in periodic “skip level” communication, where a team member can discuss their work and their state of mind with someone other than their direct managers, in order to detect and resolve problems with a manager. A well-functioning team will also provide feedback channels for team members to report larger or more systemic problems. In many industries, organizations are required to provide a way for anyone on the team to report corrupt or illegal behavior, for example.

Whatever feedback mechanisms a team uses, the channels should be designed to address bias and sampling problems. For example, if someone only reports on progress when they complete a task, there is no way to detect when they are having problems completing some task--in other words, reporting at completion biases information toward good news. Having only one path for information to come from a team member through a manager to higher-level controllers can show bias as the manager digests the information they receive and passes along a summary. This is one reason to combine multiple ways to get feedback.

Working with the control system. The team’s structure has to be designed and redesigned. It is expected to result in getting the system built efficiently and accurately, and for the team to maintain its satisfaction and productivity throughout.

Achieving this end only happens when the team is organized deliberately. While historically the organization choices have been made initially based on experience and then by incremental changes, it is possible to do better by explicitly designing and analyzing the team’s structure as a system.

The control system approach allows one to use techniques for designing and analyzing systems that have important emergent properties. In particular, the STAMP model of accident causes [Leveson11, §4.5] and the STPA hazard analysis technique [Leveson11, Chapter 8] provide a sound basis for analyzing how the team is organized. They provide a disciplined methodology for determining what hazards the team could face, such as duplicating work, failure to communicate, disagreements between people, or errors in the work. It also provides a structure for reasoning about how these hazards can occur and how to design the control system to eliminate or handle when the underlying causes occur.

As one example, the STPA hazard analysis methodology calls for identifying and addressing cases where multiple controllers can generate control actions for one controlled process. In a team, this happens when two people have some kind of controller role for one team member. These controllers can give conflicting instructions, or they can give instructions that have unexpected side effects. The hazard analysis methodology includes identifying cases when this can occur and then defining how the multiple controllers will coordinate their decisions to avoid conflicts [Leveson11, §4.5.3].

Team structure and planning. The structures and procedures that a team follows are related to but separate from how the team plans its work. The interactions within the team’s control system are continuous and immediate. They serve to maintain the social bonds that keep a team together. In building social cohesion and team culture, a team’s structure makes the team able to plan and carry out its work.

Ongoing team operation. A team’s structure and culture should determine how the team works and interacts. The purpose of treating the team as a control system is to ensure that it continues to work well, and to provide a basis for adjusting the team’s structure or its members to meet that end.

In ordinary operation, the assignment of roles and tasks has a great effect on how the team is functioning. A good assignment of roles will have at least one appropriate person covering each needed role, and work to spread the workload as evenly as possible across the team. In control system terms, to whom a task or role should be assigned is the control decision. It is based on the decider’s understanding of each person’s ability, current workload, and interests. Communicating the assignments make up the control actions, and then team members do the work.

Once assignments have been made, those with control roles monitor progress. One person may become busier than expected, and workloads adjusted in response. Someone may have unexpected trouble doing some task, which needs to be detected so that that person can be given help.

The team’s culture and social cohesion also needs to be monitored and managed. In control system terms, the controller sets the expected norms and procedures and communicates those to the team. The control actions that communicate this information take many forms: documented procedures, documents of team charters and cultural norms, and the examples set by leaders. The team, as the controlled process, will observe all this input and respond in their behavior. The controller is then responsible for watching how the team members work together, learning how they feel about each other, and identifying when some people aren’t meeting the expected cultural norms or getting along, and make adjustments accordingly.

Team member evaluations are a part of many organizations‘ procedures. These provide an opportunity to give people feedback on how they are doing at performing tasks and how they are fitting into the team’s culture. Having clearly-defined cultural norms and work assignments enables people to give feedback that measures a team member’s work against criteria that everyone should understand in the same way. (And if the feedback process reveals that some people do not understand the criteria in the way they were intended, then this is feedback to the team that the documentation needs to be improved.)

When people detect that the team is not operating as planned, they initiate corrective action. The kind of action depends on the kind of problem. If one person is not working as expected, the actions can be focused on that person: giving them suggestions or education, changing their work assignments, or in the worst case moving them out of the team. If the problem is between multiple people, then the next step is to determine why they are not working well together in order to address the working relationship between them. Sometimes, however, investigation will reveal that the team’s structure or culture needs to be improved. I discuss that below.

Forming a new team. A new team is an opportunity to design the team’s structure and culture. While this is often left to chance, with the first team members jumping into technical work, spending effort early in the process to plan how the team will work pays off in a project that functions well as it proceeds and starts to face organizational challenges.

The way that a team starts out affects how it continues to work years later. The habits that a team forms in its early days continue to influence how people work, and changes to these habits is difficult and slow (Section 8.1.5—Principle: Team habits). This means that some effort early on will pay off for a long time.

The model in this chapter provides a way to organize the thinking about how a team should work. How should authority and work be divided among people? Should the team have a hierarchical department structure, or a matrix organization? What cultural norms are expected for people’s behavior toward each other? What procedures should the team follow to do different parts of the work?

The structure of a team is not just a theoretical construct. To work, it must fit the abilities and experience of the people involved. A structure that requires perfection will not work, because nobody can work perfectly. A structure that people can’t understand or is too complicated won’t be followed, or worse, people will try to follow it but do so in some odd way.

The team’s design provides opportunity to think about how to make the team resilient. What functions should be shared? How can people working on one part of the system help each other? How do those people who are responsible for maintaining team operation keep aware of how the team is doing? What should happen when there is a serious problem within the team?

The decisions about how the team will work should be documented for everyone to read and follow. Having these documented—and brief—helps get everyone into agreement. Going through a process of building draft documents and getting team feedback helps build consensus early on. It also makes the task of adding new people to the team easier (they can read the documents) and smoother (each new person gets the same information others do).

Documenting the rationale for why the team is designed the way it is, along with analyses of how the team’s structure will meet its objectives, provides a basis for maintaining the team’s structure as it grows or as the work changes. It also helps people understand the spirit of the structure, helping them interpret the intent behind the documented structure.

A team typically grows and goes through distinct phases where it needs different kinds of structure; I discuss this below. The initial team structure will likely be simpler than what the team will need a few months later. However, the initial design for the team’s structure should include some thinking about the team will work as it grows. Because the social organization that is a team has inertia in its habits, starting out the team’s structure in a way that can grow into what it needs to be later will help avoid reorganizations that upset team operations and affect productivity.

Maintaining team function. Sometimes the planned team structure doesn’t work the way it was expected to.

When this happens, the response should be to work out why the structure isn’t working, and then determine how to change the structure to work better.

The tools for systems accident analysis are available to analyze why a team is not functioning. The STAMP methodology provides an organized way to determine possible reasons that a team is not functioning as desired [Leveson11, Figure 4.8]: people with the decider or exceptional role are not providing the needed instructions for some reason; those people do not have an accurate understanding of the state of the team; they are not getting accurate feedback from the team; the team are not getting instructions or acting on them as expected; or conflicting control actions. An analysis following this kind of methodology can reveal where the underlying problems are, and in turn suggest ways to change the team structure or culture.

For example, a team has people who are not following defined procedures for getting component designs reviewed and approved before moving on to implementation. An analysis might find that some people are not aware of the procedure (a problem with the control action/controlled process), suggesting that improving documentation and education about the procedure. On the other hand, the problem might come from one group being under pressure to deliver quickly, and those who are supposed to do reviews or give approval are not able to respond at the needed pace. This would suggest that streamlining reviews or adding reviewing resources would address the problem, or that the group needs schedule relief.

As a different example, consider a team organized into groups based on the component hierarchy. This team is having trouble with component integration: components that interact have passed design and implementation reviews, but when they are combined for verification they do not function as expected. This situation could arise from many sources. The organization into groups might be inhibiting communication between groups, leading to interfaces being designed that do not meet the needs of components being built by different groups. This might, in turn, come from flawed procedures that do not account for cross-group reviews; or it might come from group managers that don’t get along; or it might come from a problem with how interface design artifacts are managed. An issue like this could also show related problems, such as the project management not detecting the problems quickly or accurately until there is a crisis. I have found that in situations like this there are often several small changes that need to be made together to address the problem.

Team growth. A team’s organization generally starts small and informal, as a very small group starting to investigate a customer’s need or a potential system project. As the project moves forward, the team grows and its needs for structure change. The team also changes as people join and leave, and as people move from role to role.

I have found that most teams go through phases as they grow—rather than showing smooth changes over time. These changes arise from the combination of complexity growth, development of group relationships, and the growth in understanding of the work ahead.

Small groups (of just a few people) have been observed to go through a development sequence [Tuckman65][Tuckman77]. These small groups begin as the group forms, and the people work out how they should relate to each other and how to get work done. As time goes by they develop into a cohesive group that gets work done and where people trust each other. (The studies do not discuss how this process can fail, leading to a group that does not cohere or disbands.)

The interpersonal complexity of a team grows with the size of the team. The number of potential connections between team members is $O(n^2)$ in the size of the team. In my anecdotal experience, the amount of time spent on coordinating work within the team grows in line with the number of connections. If there is no structure to the team, at some point the amount of time and effort spent on communication will exceed the amount spent doing work building the system.

When a project starts, the nature of the system to be built is not well understood. The team has to go through a process of working out the purpose of the system, developing concepts, and eventually beginning to design. Along the way, the team gets increasing understanding of the work ahead.

In practice, the combination of these causes leads the team to change its organization over time. At the beginning, the initial exploration of what the project might be (working a purpose and finding some initial concepts) is typically a small group. This small group will go through a process of learning to work together, but typically the group can self-organize and does not need hierarchy for much. As the work progresses and a few more people join the project, they will initially try to fit into the self-organized small group. These additions will alter the interpersonal relationships, but at some point the complexity of using consensus will necessitate creating some initial structure. The team will settle into this structure. But as the team continues to grow, it will initially accommodate people into the structure but eventually reach another point where more structure is needed to manage complexity.

The message is that a project should expect its team organization to change over time. Almost every project I have been part of has been resistant to addressing a need for changing team structure, and has put off dealing with it until a crisis occurs. In every case this cost the organization time and money, needlessly setting back the project. A project’s leadership should be alert to the need to periodically reorganize the team so that this can be done before it causes problems.