During my Business Economics and Information Systems master study at the University of Groningen I was introduced to organization design scholars like Henry Mintzberg. He captured different organizational structures in his famous Structures in Fives (1983). While the matrix organization operated by both function and product with the project as well-known manifestation is nothing new, recent management literature seems to reinvent wheels. The adagio Keep it Simple, Stupid (KISS) should be the golden rule.
Matrix organization in 1983
Mintzberg stated in 1983: “No single basis for grouping can contain all the interdependencies. Functional ones pose work-flow problems, market-based ones impede contacts among specialists, and so on. (…) By using matrix structure, the organization avoids choosing one basis of grouping over another; instead, it chooses both. (…) As a result, matrix structure sacrifices the principle of unity of command. (…) Two kinds of matrix structures can be distinguished: a permanent form, where the interdependencies remain more-or-less stable and so, as a result, do the units and the people in them; and a shifting form, geared to project work, where the interdependencies, the market units, and the people in them shift around frequently. (…) Matrix structure has its share of problems. Although it seems to be a most effective device for developing new activities and for coordinating complex multiple interdependencies, it is no place for those in need of security and stability. Dispensing with the principle of unity of command creates considerable confusion, stress, and conflict, and requires from its participants highly developed interpersonal skills and considerable tolerance for ambiguity.” (p.85-88).
I don’t think I really understood everything in these sections while studying Structures in Fives in 1992. Now, in hindsight, I share the experiences of effectiveness and problems.
Forget tradition, let’s try something new!
Mimicking the ‘cut the middleman’-approach in insurance, many large organizations formerly true examples of the Divisionalized Form in Mintzberg’s Structures in Fives, tried to flatten their organization at the dawn of the new century. Middle managers weren’t safe of their position anymore. Recent moves towards organizational agility showed a further decoupling of managers and their teams. Self-organization is the new mantra, something to believe in. More middle managers were fired. Spotify-ing organizations led to copying grouping mechanisms of expertise and product-centricity. Squads and guilds, tribes and communities of practice, like in the Middle Ages, where craftsmen all lived next door.
Projects? You must be kidding, Scrum doesn’t say anything about projects, so these are nonexistent. Project manager? Pity you, redefine yourself as an agile coach or be fired. Project management methods like PRINCE2? So 2003! Waterfall? Definitely the common enemy among agilists. Many millennials say they don’t value it, while they’re still practicing sequential stage-based lifecycles, culturally not yet embracing the agile mindset one talks about in conferences.
Where’s the manager if you need him?
Studying the Leading SAFe course material in Spring 2017, it stood out. Management cannot simply walk away. Scaled Agile Framework (SAFe), one of the leading frameworks for scaling up agile practices throughout a large organization has a clear role for management. Turning back to W. Edwards Deming quotes like “It is not enough that management commits themselves to quality and productivity, they must know what it is they must do. Such a responsibility cannot be delegated.” are a call to action: manager, manage.
Dr. Hеnrу Mintzberg states thаt thе dutу оf mаnаgеrѕ саn bе bеѕt dеfinеd bу lооking over thеir rоlеѕ аt work. There mау bе реорlе who fаil in аll managerial jobs, but there аrе none whо can ѕuссееd in аll оf them. Suссеѕѕ dереndѕ оn thе mаtсh bеtwееn thе person аnd thе соntеxt, at thе timе, fоr a time. The article Management theory of Henry Mintzberg by Martin Luenendonk illustrates this point of view.
Self-organizing professionals have a limited reach. Either the late Stephen R. Covey or a random developmental psychology professional taught you that people must understand the interdependencies in a group. Every group needs a leader to avoid inertia, someone to trigger processes, guide the way towards a goal, hire and fire, inspire, integrate, motivate, and set the example. To value a coach more than a manager disguises a blind spot, the emperor’s new clothes set in today’s organizations. The Dutch book Ga Toch Leidinggeven! – Een Manifest Tegen Overmatig Coachen (2013), roughly translated as Go and lead! A Manifesto against excessive coaching is meant as reality-check for all coaches out there.
How would you call this role?
A recent job post by a large bank that has kicked out all project managers in favor of squads, guilds, and tribes reads: “You coordinate activities in various backlogs of squads and ensure consistency. Align architecture, infrastructure, and software. You support the squads aligning various features. You manage towards incremental delivery. You facilitate quick decision making by reporting feature delivery status. You ensure that all (IT) stakeholders are aligned. You’re inspiring, passionate and energized. You have a strong market focus on IT (e.g. Lean IT, continuous delivery, cloud processes) You focus on collaboration. Your ego has less priority than reaching the best result. You facilitate others to be successful. You’re capable of absorbing knowledge quickly in order to share it. You ask for help and feedback but give feedback as well. You’re eager to innovate. You collaborate and have a mindset of continuous improvements. You’re not afraid to try new things. You are experienced in management in an agile organization. Managing various internal and external vendors and working in complex programs is your second nature. You’re an experienced coach, and manage outputs. You’ve strong analytical skills and lots of experience as IT integrator.”
Project manager, right. Another large bank, while massively turning into a Spotify meets SAFe organization without project managers model for its IT asked for a project manager to implement DevOps in a team. Why? Project managers, and hopefully managers in general, learned to organize, lead, manage, direct, inspire, solve organizational problems.
I’m called a road manager nowadays at a Dutch Spotify adept in Financial Services. Road managers are internally advertised as the ones to help:
- connect people
- plan roadmaps
- authorize work packages, etc.
I have to operate without a dedicated project team, without any formal position or power. Leading is still influencing people to get things done. The matrix organization is alive and kicking with squad members functionally reporting to chapter leads, and in their working field to tribe leads via their product owners and scrum masters. Externals have their own reporting lines as employees of their respective companies.
I can’t help but lean on my years of Greek education. So I know the etymology of ‘autonomy’. Can you really set your own rules as squad / Scrum team member? I don’t think so. There’s a lot written on autonomy as a driver for the modern worker. Daniel H. Pink regards it as one of the 3 motivators purpose, autonomy and mastery in Drive. John Hermarij laughs about it, and recommends you to become a self-employed professional if you really want to have autonomy. Marketingfacts shares wonderful thoughts: “Alignment and autonomy are no opposites. Experience teaches us that alignment makes autonomy possible.” Something to think about. Trust is key, I suggest, feeling comfortable with Patrick Lencioni (Overcoming The Five Dysfunctions of a Team) supporting me.
A less visible manager in the matrix organization is something that you earn. Delegation is fine, unless performance is insufficient. Karel van Berckel in 1999 published a book on self-organized teams (Zelfsturende teams: doelen, processen, valkuilen, tips). There no blueprints, silver bullets. Many organizations experiment, try to move around the many pitfalls.
No blueprints? Are patterns for agile organizations useful?
Since 1999 we should have gained more insights and experience in organizational development. Nowadays at least four patterns for enterprise agility are available:
- Agile portfolio management – fit for future
- Scaling agile – fit for enterprise
- Enterprise-wide DevOps – fit for lifecycle
- Agile SIAM (service integration management) – fit for integration.
The way Fred A Cummins in Building the Agile Enterprise (2017): “In the agile enterprise, we combine the workforce shift to knowledge work with shared capabilities and a network of services, contributing to value streams that deliver enterprise values. Service units provide enterprise capabilities that can be engaged in a variety of enterprise pursuits. This is a sort of “hyper-matrix” structure because collaborations are connected by deliverable flows; value streams; responsible organization units; delegations from service to service; delivery of events; and teams for planning, coordination, innovation, problem-solving, and other purposes that involve inter-organizational participation.
The management hierarchy in an agile enterprise is a hierarchy of organization units responsible for budgets, personnel, and other resources, from the collaboration of top management to service units with people who do the actual work of the enterprise. The grouping of organization units under a parent organization unit brings together organization units that have similar capabilities and operating characteristics that enable them to work together for economies of scale and comparable leadership and incentives. The organization hierarchy is not about products, but about capabilities.
A hierarchy of organization units forms the traditional management hierarchy that is extended to additional collaborations that manage resources such as project teams and business transformation initiatives. A capability method is performed by an organization unit that is responsible for the assignments of people, availability of resources, and management of capability method performance. Interorganization collaborations define interactions between members of different organizational units to do work for enterprise purposes ranging from transformation planning to ad hoc problem resolution meetings. The network of collaborations involves all of the people engaged in the work of the enterprise, many people in multiple collaborations. Most of these collaborations are not represented in typical organization structure diagrams.”
And so, in 2017 we’re still having matrix organizations and a place for project management skills to bring to the table 🙂