Cross-functional teams are capable of quickly testing hypotheses and adapting to changes in the market. They are the primary block of an Agile organization. Unfortunately, the load on different specializations and skills within the team is uneven due to the unexpected nature of the upcoming work in a complex environment.
One solution is multifunctional learning, which relieves peak loads, increases productivity and flexibility of the team. Developers who, in addition to key specialization, develop secondary and tertiary skills over time, are often called multifunctional specialists (Fig. 1).
(Figure 1: primary and secondary skills)
Scrum Masters and management, when faced with failures in their initiatives related to multifunctional learning, conclude that people do not want to learn. But they forget that people’s behavior is a product of the system. People are glad to learn when organizational design supports multifunctional development.
People’s Behavior is the Product of the System
From a systems thinking perspective, the people’s behavior is 95% dependent on the system of work or organizational design: power structure, processes of integration and coordination, HR policies, rewards (Fig. 2).
(Figure 2: system of work or organizational design)
Behavior that is repeated three or more times is called a pattern and is generated by the structure of the system. “Unwillingness to learn” is a pattern of behavior that is reinforced by specific organizational elements. It is critical to detect those elements and change them to enable multifunctional learning.
Matrix Impedes Learning
Let’s investigate a widespread organizational design that impedes multifunctional learning—a matrix structure (Fig. 3). The creation of an Agile organization based on a matrix structure is quite problematic for two reasons.
First, because of the conflict between functions and products.
(Figure 3: matrix structure)
Functional and product managers often have conflicting goals and KPIs. For example, achieving the functional manager’s goals “adopt industry standards by migrating to Kubernetes” and “reducing category 2 incidents to 2 per month” negatively affect the product manager’s goal “improve conversion by 15%.” Regular developers are given work from two different sources – the functional manager and the product manager/Product Owner.
Secondly, functional managers influence the salary and development of competencies among developers. They are direct supervisors. Naturally, they are interested in narrow career tracks and promote them.
The grading system usually looks like this:
Ba1, Ba2, Ba3.. for business analysts
Fd1, Fd2, Fd3… for front developers
The developers in a matrix structure are prisoners of the functional silos. Is it any wonder that people are not interested in multifunctional learning? Matrix design is based on the principles of Taylorism:
specialization,
focus on activities and
individual productivity.
Taylorism contradicts Agility principles:
Multifunctional learning,
focus on customer value and
system productivity.
Separating Product and Line Management
Now let’s investigate an organizational design that is organic for an Agile organization and enables multifunctional learning (Fig. 4). It unpacks the Guideline 11: Separate Product Management from Line Management from the book “Creating Agile Organizations.”
(Figure 4: separating product and line management)
Separation of product and line management means:
Only the product manager gives work to the teams. In Scrum, this person is called the Product Owner. The Product Owner and teams share the same product goals and KPIs as everyone else in a product group.
Developers have a common boss—a cross-functional manager. He takes over administrative tasks and removes organizational impediments for teams and the product manager. For example… “Please give me the metrics showing that you stay blocked. I will go to the deputy chairman and try to convince him that the risk function should be included in the product group.” He can also be responsible for people management and performance appraisals. A cross-functional manager enables developers to learn and go beyond a narrow specialization. A cross-functional manager can be, for example, the head of a product group. IMPORTANT: The cross-functional manager does not give work to the teams, only the product manager does.
When teams have a common cross-functional manager, they can learn multiple skills. But who do they learn from? This requires mentors/experts and communities. Experts are in teams. They may be former functional managers. In case they have kept their expertise. Communities are informal forums, which include representatives of teams on a voluntary principle. Communities are built around domains, technologies, functions, and so on. Communities and experts can take responsibility for assessing professional skills, developing competencies, and professional standards. IMPORTANT: mentors/experts are not developers’ managers and do not give work to the teams. The next question is: who takes responsibility for creating the learning plan and overseeing it? The answer is self-managed Agile teams. Based on the roadmap and product vision, the teams collaboratively create and own their learning plans. Agile Coaches and Scrum Masters help them set up regular cycles to create and review such plans.
Additional Practices
By separating product and line management, we create the basic conditions for multifunctional learning. This process can also be strengthened with additional practices. For example, by creating a salary formula that takes into account development in several functions at the same time. You can also add a 360 feedback process to correct patterns of behavior. You can also use a slack time practice and encourage teams to work in three modes: pair programming, mob programming and swarming. Reinforce all these with the star map (competence matrix) practice. But it might work only if the basic conditions for multifunctional learning are established using the Guideline 1: Separate Product Management from Line Management.
Summary
The behavior of the people is a product of the system and organizational design. We often interpret the rejection of multifunctional development as a sincere unwillingness of people to learn. But there may be very concrete organizational design elements that underpin such behavior.
By separating product and line management, we create conditions under which developers can start moving towards multifunctional development.