Second blog, in a blog series about the upcoming book: Creating Agile Organizations - A Systemic Approach, by Cesario Ramos & Ilia Pavlichenko.
Many problems at the workplace are not the fault of the individual managers or teams. They are often the result of working in an organizational design(OD) that impedes rather than supports Agility. The OD determines, to a large extent, how people cooperate, the prevailing mental models, and how work gets done. To change all of this takes time and requires people to unlearn old lessons and relearn new ones that support Agility.
An organization redesign includes re-thinking:
- Structure: Which organizational units such as departments, groups and teams are required? How are work and responsibility divided among those units?
- Processes and Integration: How do the units and roles relate to each other and collaborate?
- People: What team and employee skills and capabilities are needed?
Working in a new design helps the people learn what is needed to build the new capabilities.
Some examples of how design decisions can facilitate the development of capabilities are:
- For fast adaptation to customer insights, consider creating a short feedback delivery process that allows fast learning about the customer. Allow decision making by people who work closely with the customers.
- For teams to take ownership of delivering customer value, consider designing autonomous teams that include all the necessary skills to finish their work independently of other groups.
- For efficient product development flow, consider designing a reward system and career path that values people for developing multiple skills. Multi-skilled specialists reduce the bottlenecks in the delivery process.
Figure 1.1 shows that executing a business strategy requires specific capabilities, and these capabilities can be developed working in the appropriate OD.
Figure 1.1 From business strategy to organization design. ( Figure copied from Creating Agile Organizations - A Systemic Approach by Cesario Ramos & Ilia Pavlichenko)
Contain Reciprocal Dependencies with the Product Group
James D. Thompson wrote that we should design the work by the intensity of interdependence and then introduce specific coordination techniques for each.
There are three types of interdependence:
Pooled. Units are doing the same task in parallel or have a shared resource. Sales people often have pooled interdependence if they sell individually and combine their monthly sales numbers to get the overall result.
Sequential. Units rely on each other in predictable ways for the flow of information, work and decisions. In sequential interdependence, each unit completes its task before another in the sequence completes theirs. Classic example is an assembly line. A product must be fully assembled before it is wrapped, and wrapped before it is shipped.
Reciprocal. Units are sequentially interdependent. In addition, they work back and forth and must adjust to each others’ actions as the situation changes unpredictably.
The reciprocal interdependence resembles the dependencies between software development teams that work on a single product. These teams either have a mutual functional dependency—when a feature is divided into independent technical parts to be developed by different teams—or a mutual technical dependency when each team picks up a complete feature but works in the same software components and creates technical dependencies.
For reciprocal interdependence, it is recommended to manage the dependencies through constant information sharing and mutual adjustments. Figure 1.2 shows these three types of interdpendencies.
Figure 1.2 Three types of interdependencies.
A study about the implications of these types of dependencies was published in the paper Quantifying coordination work as a function of the task uncertainty and interdependence by Ronald E. Giachetti et al. They concluded—as shown in the figure above— that
First, "...the experiments find no significant difference between pooled and sequential interdependence and the resulting coordination load…".
And second, "…coordination load increases significantly when interdependence changes from sequential to reciprocal...".
Working with reciprocal interdependencies takes twice as much time to coordinate compared to work with the other types of dependencies.
Figure 1.3 Coordination load as a function of interdependence and analysability (Adapted from Ronald E. Giachetti et al)
The key idea is to first design the organization to minimize reciprocal interdependencies between units that produce value. When you group the necessary functions and skills to produce value, coordination becomes easier, flow increases, and rework decreases. It also facilitates team accountability for a complete work item instead of just a part. The teams can now become autonomous and can manage their work. The organization can stop giving work packages to a team to execute and instead provide customer problems for a team to solve.
Redesign into a Product Group
In the book, The Toyota Way11, pp 304, Jeffrey Liker, Professor of Industrial and Operations Engineering at the University of Michigan, recommends organizing around product families. Each product family has a senior manager responsible for the product family and controls all the resources needed, including maintenance, engineering, and quality. Such can go fast because it contains all work dependencies, but it can also quickly relocate resources to areas of highest demand. An Agile organization benefits from the same capabilities and might use a product group that is defined by:
- Its purpose or function within the organization
- The organization elements required to achieve its purpose or function such as cross-functional teams, shared functions, systems, roles, accountabilities and responsibilities
- The senior manager that leads the product group. It is a person with a deep understanding of the product and process.
- A market-focus and/or profit & loss responsibility
- Product decision-making autonomy
Avoid Designing the Product Group from the Inside Out.
An inside-out design is based on an internal business process or the system architecture.
Let us provide two examples of design from the inside-out:
- One of our customers develops a trading system, and the process of registration, trading, and billing consist of 23 process steps. How did they design their structure? They had 17 teams, and each team worked on one or two business process steps, even though a feature largely required multiple business process steps to deliver value to a customer.
- Another customer developed material analysis systems. The system architecture consisted of components like Motion Control, Data Extraction, Data Analysis, and many more. How did they structure themselves? They had one or more teams per architectural component, although 80% of customer features required changes in most components together.
Such designs make it hard to adapt to customer value; instead, they concentrate locally, optimizing the individual teams' performance.
Prefer Designing the Product Group from the Outside In
To design the product group from the outside-in:
- Start with the customer problems that need to be solved.
- Study how solving those problems for your customer works in your organization.
- Determine which organization elements such as units, processes, and people are needed to create customer value.
- Combine them into a product group.
Our next blog discusses how you can define your product group.