Beyond the Matrix - Leading cross-functional teams.

Matrix organizations have severe problems

Usually, management structures are organized by discipline. That is, designers report to a head of UX, backend developers to a head of backend, and so on. The managers are responsible for several employees in different product teams (see Figure 1) and take on both management tasks (employee development, organization and planning, salary negotiations…) and leadership tasks (mentoring and coaching, creating vision and motivation). This setup brings some inherent challenges with it.

Managers are detached from the day-to-day activities of their direct reports, which makes coaching and individual support difficult. The managers themselves are usually involved in a product team on a technical level as well and are therefore overloaded by too many context switches.

A ‘shadow agenda’ emerges for individual disciplines, which employees are expected to realize in parallel to the team’s product goals. These can be cross-cutting issues, such as addressing technical debt or style guide changes. Such things can cause friction in the product team and exposes individuals to an unnecessary goal conflict (" Should I work on the next ticket of my product team or on the style guide?"). Some teams “solve” this conflict with an X% rule: “20% of the time we work on technical stories.” Which, of course, never works.

Problems escalate faster. If employees turn to their managers when problems arise, in the worst case scenario, the threads only come together again at the C-level. This results in distorted facts and a lot of fuss, which undermines the confidence in the team and can incapacitate it. The opposite can also happen, with problems not being raised at all leading to the same results.

Both technical and product team leadership are necessary

The dilemma we face can be summarized as follows:

• We need managers, who know their discipline well, because they are more likely to be respected (especially in engineering), better able to provide support, and have a better understanding of their direct report’s situation.

• We need leadership structures that mirror team structures to ensure consistent leadership within each product team and to solve problems locally.

In order to create an environment in which all employees can be productive and feel comfortable, we need to ensure consistent leadership within product teams, address problems locally, support our employees in their disciplines as best as possible and be able to understand their situation.

Understanding is more important than the specific discipline

A key assumption behind the concept of matrix organizations is:

“The technical competence of managers (especially in engineering) is extremely important.”

Most everyday problems in which a manager provides support are not technical, but interpersonal. Here, it is particularly important that a manager can understand the situation of her direct report. This does not require both to work in exactly the same discipline. Some disciplines are closer to a person’s experience than others. Frontend and backend development, for example, lie closer together than product management and backend development.

Making implicit leadership explicit helps the team

Another assumption from the context of Scrum is:

“Product teams must not have a formal hierarchy.”

Leadership includes a lot of tasks (onboarding new colleagues, communication in all directions, moderation in case of conflicts…) that must be taken over by one or more people in the team. Additionally, there are classic management tasks (salary negotiations, performance reviews, one-on-ones, people development…) that can also play into the topic of leadership. In my experience, there are very few people in most teams who can and want to take these responsibilities. Ideally, appointing managers is just a formality since they already do many of the leadership tasks. It makes even more sense to explicitly designate and support these individuals, because good, supportive team leadership is anything but simple.

A leadership team of product and engineering as solution

One possible solution to the dilemma is to introduce a leadership team consisting of a product leader and an engineering manager in each product team. Both work closely together and are jointly responsible for the outcomes of the product team. All engineers (frontend, backend, and DevOps) report to the engineering manager and all product managers and designers report to the product leader.

Pros

• Local problems can be solved locally, as the threads come together directly in the leadership team.

• Managers work close with their direct reports and are part of the product team.

• Managers invest all their time in their product team and have significantly less context switches.

• The team vision becomes the primary focus for the whole team.

Cons

• Not all members of a team are formally equal.

• Much depends on the collaboration and leadership skills of the leadership team.

For this approach to work, a strong technical mentoring of all team members is necessary. To achieve this, technical experts can provide guidance. It is important that these experts do not take on management tasks, but rather focus exclusively on improving their discipline within the company.

Conclusion

Product teams need leadership. A leadership team of Engineering Manager and Product Leader, who are jointly responsible for the team’s outcomes, are one way ensure this.