Many companies align their organizational structure with their process structure. For example, in SAFe, Agile Release Trains are used to create corresponding organizational structures. LeSS, too, advocates for the “Product Group” as the sole organizational structure. In this post, I’d like to explain why “virtual” organizations—or matrix organizations—are sometimes entirely justified. Welcome.
It All Starts with the Process
We’re all familiar with the mantra: processes first, organizational charts second. SAFe also advocates for an in-depth value stream analysis in its Implementation Roadmap to enable the Agile Release Trains (ARTs) to be skillfully aligned—the famous Development Value Streams (DVS). SAFe legitimizes this as the “Organize around value” principle .
We also advocate for a reasonably thorough value stream analysis. In all our projects (whether SAFe-based or not), we strive to understand both the operational and development value streams—either to gain technical expertise or to make them transparent if they haven’t (yet) been defined. Here, we sometimes like to make use of classic techniques such as value stream mapping, which has also been adopted in SAFe.
Simplified representation of value stream mapping in SAFe to determine “flow efficiency.”
In this phase of value stream analysis, organizational charts are completely irrelevant. Likewise, one should not talk about people, but rather about roles that support or enable a value stream. This is because organizational charts are “dangerous.” They represent the stability and hierarchy of an organization—and that contradicts the flexibility and agility of processes.
Example of a Value Stream / Business Process in a Manufacturing Organization
We try to postpone discussions about organizational charts for as long as possible. We know they are inevitable. At some point, boxes and lines must be drawn. Organizational charts also manifest internal power structures and can either fuel or resolve certain power conflicts. Organizational charts are risky, but unavoidable.
Structural organization and process organization are not the same thing. However, if you merge them—even if the motivation is noble and the goal is to prioritize process organization over structural organization—you create a compromise that dilutes the strengths of both.
Process-oriented organizations are dynamic; they are not concerned with positions, organizational charts, or business cards— they aim to create value as quickly as possible and do the right thing. Structural organizations, however, are frameworks that invest in the stability and professional development of employees. They structure the dynamics within the company; they also sometimes serve as an anchor for employee identification.
Example of a dual matrix organization. The process organization is grouped into projects, which extend from the business units into the relevant business functions.
Both organizational forms are legitimate, and both can play to their strengths. In a SAFe setup, for example, the process organization is optimized to do the “right” thing—and the “traditional” functional organization ensures that the right thing is done “right” by, for instance, promoting community work and investing in professional development. Work on the system itself could also be assigned to the functional organization, thereby strengthening it.
Merging the operational and functional organizations also carries risks. The most common risk in such well-intentioned mergers is the tyranny of urgency. The operational organization can always prevail; it no longer has a natural “counterbalance.”
A healthy organization thrives on a certain degree of instability within the system. Operational and organizational structures compete for the same resources—albeit with different goals. The operational structure aims to produce value and use resources wisely, while the organizational structure aims to conserve, optimize, and build up resources.
An average service company in Switzerland with a maximum of five thousand employees might celebrate the merging of process-oriented and structural organization as a milestone in its transformation.
Presumably, in the past, a “project-centered” organization deepened the lines of conflict between operational and structural organization; people are pushed toward work instead of work being directed toward people, or project-versus-product organization. As a consultant, I helped shape this trend myself in this country more than ten years ago.
Now, however, I’m no longer as certain about this as I was back then. I’ve also come to know industries where this strict separation is critical to competitiveness. All emergency response organizations are structured functionally. Yet even for everyday incidents, these functional organizations are consolidated into a lean operational structure—and this is even more true for major events (WEF) or disasters (fires).
Both organizations hold power: The operational organization (process) has the (operational) experience, the staff, and the reputation. The management organization (structure) holds the budget, possesses the (specialized) expertise, and ensures the necessary training. Naturally, conflicts arise between these organizations—but negotiating them, in my view, is part of what makes an organization healthy.
Emergency response organizations that exist solely for operations (execution) will automatically set different priorities than those that also value and respect leadership (structure).
Simplified representation of the U.S. Armed Forces’ organization
Not necessarily. But I would advise against mapping all Agile teams in a SAFe setting exactly as teams focused on organizational development. I also consider the currently popular approach—consolidating all employees into a “pool” based on their roles and having them “managed” there by a People Leader or Developer—to be risky.
Risky, on the one hand, because it implicitly suggests that this type of responsibility isn’t that important and that one can therefore easily “manage” 40 employees in a pool. This devalues the People Leader/Developer role. On the other hand, because this organizational form is subordinate to the operational organization, it must always yield in case of doubt and can never assert itself (“no power”).
This pool approach is appropriate only if it is organizationally situated as “far” as possible from the operational organization and is sufficiently “powerful” within the organization. This pool must have sufficient authority to allow employees to be distributed across the operational organization at up to 80% of their capacity—and to allow these employees to rotate, meaning they are not bound to a single operational unit until retirement. The remaining 20% of their capacity can then be invested in community work.
Example of a medium-sized national service provider with approximately 5,000 employees and a 300-person IT department, where the “structural organization” is stable and employees are consolidated into a virtual operational organization (e.g., “Back Office” ART)
The projects aren’t coming back—hopefully not as a “funding instrument.” However, I still consider some form of project organization to be sensible for certain industries and certain types of tasks . I don’t call this a project organization, though; I simply call it a “normal” and healthy matrix organization.
I view the organizational effort required to run a matrix organization as a necessary evil—or rather, as an investment needed to reap the benefits of a matrix organization. This organizational effort can be minimized through small measures such as joint prioritization, clear rules regarding authority, transparency, and modern communication tools.
Matrix organizations are here to stay. Matrix organizations remain unbeatable in knowledge work. The efforts made over the past decade to move toward purely process-oriented organizations will give way again to a gentle matrix structure in the coming years. The role of People Leader/Developer is becoming more important and more influential again—but increasingly specialized in terms of subject matter expertise or role-specific knowledge. People Leaders/Developers without an understanding of the subject matter or the specific role will find it difficult to assert themselves.