Agile Management VS Matrix Organisations
This article was originally published on LinkedIn on September 1, 2020. Migrated to Medium and edited on September 2022.
https://www.linkedin.com/pulse/agile-management-vs-matrix-organisations-cesar-miguel/
A brief comparison of matrix organisations and agile-minded organisations. What makes them so different? Can we make them really coexist? And the real question in the end: is there a place for management in all of that?
Just as an introductory note, remember the 3 dimensions of a Project: timing, resources (budget & people) and features. Quality is at the center and it is non-negotiable (we do not want to produce something that doesn’t work, right?).
The basic theory behind this triangle is that we cannot constrain the 3 dimensions, only 2 of them. Trying to constrain the 3 leads to the common problems in project management we see today: contracts with penalty clauses, lack of trust, projects that are constantly delayed, budgets that explode…
Reader’s discretion advised: please don’t get me wrong while describing matrix organisations… Projects and markets with low uncertainty and high predictability can benefit from command and control, waterfall and matrix organizations as a very efficient way of managing. Nevertheless, my leadership of product innovation organisations confronts me with high volatility and uncertainty contexts, highly creative environments, etc. and it is my personal belief that the world is and will continue to be more and more uncertain and volatile…
1. MATRIX ORGANIZATIONS
The origin of matrix organizations goes back to the 1950s in the aerospace industry in the US. There are some variations of matrix organizations. Some people talk about “strong” matrix organisations, “weak” matrix organizations, even nowadays “product oriented” matrix organizations. Although we won’t get into details about these differences, they all come back to the same principle.
In matrix organizations, features are fixed, timing is planned ahead and resources are variable. We fix the business units, we fix the projects, we plan the roadmap/action plan and we adjust resources (budget, people…) to meet the requirements and planning. Note: think about how many consultants and subcontracted activities your company has, you will quickly see how resources (people) are a variable for the overall organization…
First organizations had one dimension, people would report to just one single line of management.
With the rise of multidisciplinary initiatives there was a need of a second dimension: projects. Projects would require resources coming from different departments all together, we created the two dimensional matrix organisation. People on a project would report to their head of department and head of project. As complexity increases with time we can see today n-dimensional matrix organizations (n>2) where people report to more than 2 managers.
There are plenty of resources to continue reading about matrix organizations (for example here, here or here).
What side-effects do matrix organisations generate?
An increased sense of control.
More reporting means more control (right?). Having two (or more) heads means being more constrained in execution (to department needs, project needs, cross budgets, etc), and this results in lower risk of deviation (and theoretically, lower risk of failure by chaos).
The rise of the middle management.
This kind of organizations multiply the number of “managers”, fancy titles… mobility can be varied and fun at managerial level (all managerial functions being almost completely interchangeable as they are not operational).
On the down side, increasing the number of managers and heads to report increases undeniably the internal politics in the company. More heads mean more distinct objectives, that might not be inline, hence the politics, inertia in decision taking and overall loss of efficiency through difficult communication and alignment.
Dilution of responsibility.
Deriving from the previous, having many managers and heads to report is the perfect setup for a blame game. When something goes wrong you can always find someone else (other department, other function…) to blame. People in teams are not really responsible as a whole.
Budgets are not just assigned to teams but depend on departments/BUs and projects. Management of resources (hiring/firing) is not done at team level, but driven from budgets”from above” (whatever “above” might be) and not by a product strategy. No autonomy/independence means no responsibility of the team as a whole.
The shift in value generation perception.
Organizations tend to think that the value is in management and not in production or design, leading to the current culture of massive subcontracting and externalizations amon big traditional companies. This example is clearer with IT: some companies subcontract the IT functions (or do not want to hire developers in house), for development, maintenance and evolution of their own applications. The reason for this being “IT is not our core business”, showing that the perceived value for the company is in the management of the product or service but not the product or service itself (even when this service ensures the company’s survival and efficiency, like the IT department).
2. AGILE ORGANIZATIONS
What happens when the market is uncertain, the product is highly evolving, and projects outcome is unknown?
We need agile organizations… We need to make sure that we are fast, adaptive, and as close to the real value (which is not known beforehand) as possible. At this point we will oversimplify and say that agile organizations are the ones where resources are fixed, timing is delimited (but not necessarily planned) and features and outcomes are variable.
We need to create smaller teams (usually people refer to pizza teams, 5–10 people max.) with increased communication channels and reduced politics, with the maximum degree of sovereignty and autonomy while maintaining overall alignment, ensuring individual and collective team responsibility and focusing on final client value. You can find extensive documentation on values and principles of AGILE, and here is an article I wrote about lean and agile that can serve you as introduction if you need it…
It seems clear at this point that it is very complicated for matrix organizations to harbor an agile culture. It is not impossible but very complicated.
Note that agile organizations have structure, agile does not mean chaos at all! It is actually quite the opposite… rituals and role are clearly defined in the entire organisation.
Ideally a team (or squad) would be as independent as possible from each other, have all the required resources and competences to manage a product/feature from A to Z, in all channels, etc. In real life this is not always possible (squads should remain small but some product’s complexity is too important), while scaling we need some sort of global alignment and coordination.
How do we scale agile?
There are several frameworks that propose possible organizations to scale agile to bigger companies or multi team situations (SAFe, LeSS…). I will not get into details of any of these frameworks, but this might be a good idea for a future article about SAFe… 😉
When scaling up, the idea is to reproduce what happens inside a team across multiple teams. The same iterative process must be applied to cross a multi team organizations. Here is an example SCRUM-like iterative process for an AGILE team.
New coordination roles will exist like “product managers”, “head of tribes”, “head of chapters”, “release train engineers” and so on. These are not “boss”, classic manager or control positions but more facilitators and overall coordinators, they are not reported to or responsible of outcome (responsibility is collective to the team).
Let me give you just as an example the naming used by Spotify (if you want to learn more about Spotify’s culture, you can always watch the 2 20min videos here and here). Spotify’s is just an example and cannot be copied easily. As with any framework, we must understand the underlying concepts and adapt to each specific situation… (even Spotify has evolved from this nowadays). This image is the official and commonly shared representation of this organisation:
- Squads are the basic team units of work. They have all the required profiles and roles to deliver the working packages: developers, product owner, qa, scrum master (can sometimes be shared between squads)… They are fully autonomous and responsible for the decisions and outcome of their feature or product.
- Tribes appear when the product is way too big to be handled by a single squad (that would be the ideal scenario), so it is a group of squads working on the same product (but different features for example). Note: I wrote an article about the roles needed in an innovation department a while back, I could have said at the time it was a “product X squad” in the “product innovation tribe”… you will find the same roles, structure and principles… 😉
- Chapters are groups of roles across squads that must share methods, knowledge and alignment. For example: there could be a chapter “front end developers”, another chapter “backend developers”, etc… Even if they are in different squads, they must align because the share the same product, company guidelines, etc…
- Guilds are groups of larger subjects, cross tribes. For example we could have a guild “web technologies” that might include some (or all) the members of the chapters front and backend…
3. AGILE MANAGERS
Is there a place for middle management in an agile organization? Sadly, not really as is… and few companies have the courage to truly embark in a cultural transformation that might require a complete repositioning of all these managers that climbed the virtual ladders over the years, leading to failed transformations one after the other.
Is there a place for management in a agile? Absolutely! But not the way it was done before.
The role of the agile manager is not defined in any traditional framework where we see roles like product owner, scrum master, developer, etc. Here are a few hints, not written in stone, that should serve as common sense guidelines for what an agile manager should be.
- The position of an agile manager is that of a servant leader. The main goal of this position is to build trust, create a failure-acceptance environment and remove impediments for the team. In that sense it is much like the scrum master role but at a higher level.
- Many talk about “leader coach”, since both competencies are important. Agile managers need to drive the vision the teams will follow (leadership), while ensuring the individual and collective improvement (coaching).
- The agile manager embodies the values and principles of agile and the company.
- He/She is the ambassador of the tribe/product towards the rest of the organization.
- One point that is extremely contradictory and really incompatible with the traditional management and politics is the fact that an agile manager should try to make himself/herself unnecessary (… big silence in the audience …)
… Wait, what? 😱 Let me explain that last point of making himself/herself “unnecessary” before I finish the article… It happens very often (I am sure you have seen it), that managers behave more in self-survival mode trying to justify and protect their own land/territory or power, rather than the greater good for the company, the overall benefit for people/workforce or the products/teams themselves. The question that agile managers should be asking themselves is not “how can I control/steer the team?”, but rather “what is the team lacking to be completely autonomous and efficient?”, the ultimate goal being a completely efficient and autonomous team handling every aspect of the product in an integrated and aligned organisation (ideally making the role of the manager unnecessary…). Let’s be honnest, there will (always) be a need for leadership and coaching/facilitation of teams and organisations, the idea is the utopia to long for.
How are you implementing AGILE in your organisation? Are your squads truly autonomous, self-organized and people do not report to external heads? Is your decision process decentralized? How have you scaled up?
These are real challenges that do not have a shoe-that-fit-for-all solution… Most of the times what has worked for a company cannot work for another. The important first step is to absorb the basic concepts (which are always the same) and adapt them to each context, culture… And then, just try and iterate!
Do not hesitate to follow, leave a comment, re-share and like!
