The Firm as a Network of Teams
What determines the distribution of knowledge and information flow between teams in a firm? Why are some bigger than others? Why do some teams collaborate more with others? Many small choices made by different people, inside and outside a team, accumulate to hard-to-reverse distribution of expertise, decision authority, and resources, that is, into the set of teams that exist at some given time, and their interdependencies, i.e., an organizational structure.
Another view of organizational structure is to see teams as modules and collaboration between them as transactions. In that view, the boundary of a team is affected also by decisions of which transactions should be performed between team members, and which should be done outside. This is comparable to how the boundary of a firm has been discussed in economics, at least since Coase’s 1937 paper in Economica, “The Nature of the Firm” [1], the foundation of transaction cost economics.
However, a firm is clearly not the same as a team within a firm. Different rules apply. A team and its members are subject to relations of authority in the firm. A team’s scope of work is not going to be determined solely by the abilities of its members, their intentions and actions – it is the result of decisions of others in the firm, who have authority to decide the parameters of organizational structure. The extent of a firm’s transactions is determined by “the market”, or more specifically its strategy, product and service portfolio, applicable regulations of the geographical areas they operate in, its relationship with others, including suppliers and firms selling substitutes, and so on.
For example, if a team needs a service performed, and another team can do it then it is less likely that an outside firm will be used, even if it might provide superior service. That would be a case of a preference or rule to buy internally the service as opposed to looking for it outside the firm. Another consideration is that it may not be possible to price the internally provided service, which would make it amenable to straightforward comparison with external providers. Obviously, many services involve work which is simply such that it cannot be easily priced, innovation or creative work being evident examples.
The questions I started with above all look back: they are about why a given organizational structure is as it is. While history is interesting and knowing it helps understand constraints, the background and genesis of decisions, making the best assumptions about history will not matter so much if future decisions about organizational structure are disconnected and incoherent.
The interesting question, then, is how to think about organizational structure as the result of design decisions, and from there, think about how to make such decisions in the future.
A Modular View of the Firm
To design an organizational structure, we need a simplified way of thinking about it. The organizational chart, for example, is limited because it focuses usually on one type of relationship between individuals and teams, the relationship of decision authority. While allocating decision authority is important, it is only one of the parameters to consider.
‘Team’ can be any kind of grouping recognized within the firm: business units, departments, which often are teams of teams so to speak, and small teams themselves, the atomic groupings of individuals.
To create a team is to create a boundary; by putting some people inside the team, and others outside, a team bundles related expertise, experience, function, preference, relationships, and therefore, ensures that some transactions happen inside the team, while others cross its boundaries.
Designing structure means choosing why and how to set such boundaries. Explaining why there should be a boundary requires explaining what Langlois [2] calls the “modularization” of the firm, perhaps simply the structure in terms of:
- Architecture that defines which modules there are, and the function of each,
- Interfaces that defines how modules interact with each other, and
- Standards that measure the performance of each module.
This gives a simplified model of the firm, in which teams are modules. Architecture, then, is about setting boundaries and thereby identifying teams. Interfaces are about how teams interact with each other, and in most cases the fundamental questions are those of information flow: Which information do teams exchange? Why? When? How? Finally, standards are concerned with how performance of teams gets described, so that targets can be set, and it is possible to know when to take corrective action.
The interesting implication of the above, is that we see just how simplistic the organizational chart is. Knowing who has authority is useful, but does not say much about information flow and responsibility. In the organizational chart, there will be a team, and it may have more authority than another team; in the modular view, we also need to say how the two teams interact – which decisions does the one with authority need to make, in order to produce outputs that the second team uses as input?
The modular view of the firm consists of seeing organizational structure as a network of interdependent teams, where dependencies between teams are, but not only about authority: they are about teams depending on each other for services. For example, while it is common to think of an executive team as having the highest decision authority, it is less common to think of an executive team as providing services to others – such services are, for example, resource allocation decisions, strategy formulation, and so on.
Factors Influencing Modularity in a Firm
It is easy to name many factors that probably influence, more or less directly and frequently, the current architecture, interfaces, and standards in a firm.
For example, goals and targets (and understanding of how teams relate to those), perceptions of which expertise to match with which opportunities and problems, structure of business processes, hiring decisions, actual expertise of individuals hired, promotions, incentive mechanisms in place, informal networks, and more. Then, there are planned significant changes to organizational structure, where teams are reorganized in response to perceptions of opportunities to improve, or frictions, need to assign and/or redistribute authority, or to respond to external positive or negative pressures, such as, say, managing new product lines, vertical integration or disintegration, changes in regulations, and so on.
Although all of the above, and more, certainly have some (hard-to-measure) role in shaping boundaries in a firm, considering them together may be confusing – there are many of them, and their relationships are not clear.
One feasible approach is to see the firm as interconnected processes, and make teams as groupings of individuals responsible for specific parts of such processes.
The process-oriented approach applies to work which is well understood and repetitive. Depending on the volume of work to perform according to a process, teams can be made to group together expertise required in subsets of steps in the process; teams could be made to support parts of the process, and their boundaries would be determined by the expertise they need to group together, and size by the volume of work.
Work that involves uncertainty about what to do next will not be described by a clear sequence of steps, i.e., will not be described by a process. An obvious example are invention and innovation, that is, work that is done in order to create something new in the case of invention, and something new and useful in the case of innovation. The blueprint of a business process does not exist and cannot be an input into the definition of team boundaries and interactions.
Adaptability
Ideally, architecture, interfaces, and standards are designed to make the firm adaptable.
Where adaptability is preferred over predictability of a process, or (equivalently?) where the latter is not feasible, an approach is to design teams by service(s) they provide to others, i.e., by defining well the information they need to do so and the deliverables they produce. The internal functioning of teams can be transparent or opaque to others, as long as they follow standards, i.e., as long as there is a mechanism to ascertain that they do.
At this point, there are two types of teams in the firm: teams that have a role in processes, and teams that provide services on demand and in absence of a process that they have a role in. When the process exists, it orchestrates interactions between teams; when it doesn’t exist, messages between teams, without a predefined and stable order, will trigger work.
Clearly, these two types are not sufficient: what happens if there are problems or opportunities that cannot be matched to processes, or to services that existing teams provide?
Team Development
There needs to be a mechanism for creating new teams, in response to opportunities and problems that are not in the scope of work of any existing team.
This leads to a third type of team, those whose service is to identify opportunities and problems, and whose output is work in a format that can be communicated to an existing team, or that supports the case to set up a new team. Straightforward examples are executive teams when they set direction, goals, targets for other teams, teams tasked with innovation and/or diagnosis of events internal and external to the firm, as well teams executing projects intended to deliver improvements to products, processes, or other.
Service Types
Three types of work that teams do were identified above: (i) work that is part of a well-defined process, (ii) work that the team provides in response to events that are not generated as a result of a well-defined process, and (iii) work that cannot be matched to the expertise in any of the teams, and so one team is designed to deal with such work. If the last type of work seems counterintuitive, note that it is inevitable most of the time in any growing firm, as it will never have all possible expertise it may need internally, and will expand into areas of expertise it does not have via hiring, or through some form of education of its current staff. Project management offices, strategy offices, internal consulting groups are examples of teams that handle the third type of work.
The nature of the work, as above, is the perspective from inside a team. From the outside, these are services that the team provides. When it executes steps in a process, it is doing work of the first kind above. When it mobilizes the expertise in response to a request that has nothing to do with a well-defined process, then it does work of the second type. And the third type of service is to do work that none of its members did in the past.
The service types are called, respectively, type A, B, and C.
Interfaces of a Team
Interfaces are specific to each service type, and so the interfaces of a team will be determined by the types of services it provides.
The fundamental difference between services of type A, B, and C, are the stability of requirements and the maturity of the knowledge required to deliver the service, and satisfy the requirements.
Stability of requirements is about the differences between requirements over time: if there is a well defined process, and a service involves doing some specific steps in it, then because the process is well defined, then the more stable the requirements to satisfy by delivering the service. A team that is responsible, say, to clean windows, provided its members are appropriately trained, delivers a type A service.
The more stable the requirements, and the more mature the knowledge to satisfy them, the closer we are to type A.
The less it is clear why requirements exist, and why they exist at some given time, but where knowledge to solve these requirements is available, the more we move from type A and get closer to type B: the team still has the knowledge, but requirements came unpredictably, and the rationale for them may be unclear or absent. If the same cleaning team is working always in a given building, and is now asked to clean in a different one, they still have the expertise to clean, but the requirement is now different, as it diverges from stable requirements that team is otherwise satisfying.
Finally, if the requirements that the team receives are new to it, and it is not clear how the team’s expertise relates to these requirements, then this is closer to type C.
The principal implication on interfaces is that type A services involve a clear set of inputs that the team needs, and they will be expected to have a clear and stable set of deliverables in response. Clarity and stability of requirements and deliverables drop when moving from type A to type B, and then type C. Therefore, interfaces will require less two-way communication for type A and B services, and more for type C (in order to understand requirements and then get feedback on solutions, given the higher uncertainty, relative to types A and B).
Standards
The implication on standards of distinguishing between services of type A, B, and C, is that criteria for evaluating the performance of services will be better defined and more stable, the more stable and well understood the input requirements and output deliverables of a service.
Design of a Firm’s Network of Teams
To conclude the above, the design of organizational structure can be seen as the problem of designing architecture, interfaces, and standards. This, in turn, is the problem of setting boundaries of teams, and defining interdependencies that reflect transactions happening between teams. Architecture, in practical terms, amounts to a network of interconnected teams, where links between teams show interactions, and thereby dependencies. The network shows architecture and interfaces. Standards are about setting, where and when appropriate, metrics on interactions.
The discussion also leads to a simple process for designing and redesigning an organizational structure:
- Each team maintains the description of its services, standards to meet, and interfaces, or relationships to other teams;
- Changes to teams are evaluated in terms of how they affect a given team’s boundary and its relationships to, that is, interactions with other teams.
Note that the classical organizational chart is implied in a network of teams in more detail, since if team A depends on team B for a service, the latter has authority in terms of that service over A.
References
- Coase, Ronald Harry. “The nature of the firm.” economica 4.16 (1937): 386-405. https://onlinelibrary.wiley.com/doi/full/10.1111/j.1468-0335.1937.tb00002.x
- Langlois, Richard N. “Modularity in technology and organization.” Journal of economic behavior & organization49.1 (2002): 19-37. https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.460.2822&rep=rep1&type=pdf