• (855) 278-3678
  • info@artizen.com
Life in the (Agile) MatrixLife in the (Agile) MatrixLife in the (Agile) MatrixLife in the (Agile) Matrix
  • Home
  • About
  • PM Services
    • Large Program Management
    • Program Problem-Solving
    • Program Management Review
    • Program Health Assessment
    • Merger Integration
  • Agile Services
    • Agile Coaching
    • Agile at Scale
  • AI Data Solutions
  • Contact
✕
Waddayamean It’s Not Done?!
August 31, 2020
The Challenge of Distributed Agile Teams
March 8, 2021
Published by Rosanna Hayden on November 19, 2020
Categories
  • Articles
Tags

Life in the (Agile) Matrix

How often have you read a job description including language something like “Must be comfortable operating in a matrix-management structure”?  This denotes that team members report to multiple bosses, and in a software development context often means each team member has their “functional” boss and their “project” boss. Typically, one of those relationships is considered “solid-line” and the other “dotted line”, but to be sure both managers exert some level of authority over the team members.

Since the 1970’s, countless articles and papers have been published about the concept of matrix management, and like most things in our society the reviews are mixed. I recently came across a paper from 1994 citing matrix management as one key reason for the downfall of Digital Equipment Corporation, at one time the second leading supplier of computer systems in the world. A May 1978 article from Harvard Business Review decries the “pathologies” of matrix structures, while another article from McKinsey as recently as 2016 extolls the virtues of this approach. After reading many such articles, and reflecting on my own personal experience over thirty years, my conclusion is that done well a matrix structure can be incredibly powerful, but done badly it can mean the death of an organization.

A Typical IT Project-Oriented Matrix

Most clients I’ve worked with in the Tech industry are very familiar with matrix organizations and use  them routinely to execute large projects and programs. The typical structure follows functional silos as the primary or “solid-line” axis, while cross-functional project teams are temporarily formed by cutting across these functional boundaries, and assembling team members from each silo.

This functional silo orientation matches very well the typical phases of a waterfall project, which I suppose is why it has been so popular over the decades. It does however lead us toward the problems cited in numerous articles:

  • Silos within each project team create communication gaps, knowledge attenuation, arduous hand-offs, and the need for “contracts” between functions within each project (e.g. requirements documents, functional spec’s, etc)
  • Such temporary teams can be slow to form and norm, often taking months to reach a reasonable level of performance and never approaching high-performance
  • Conflicts between functional priorities and project priorities weaken focus and create uncertainty
  • Lack of clarity about boundaries of authority and accountability leads to slow and bureaucratic decision making
  • Endless time spent in meetings
  • Loss of collective knowledge upon project closure as team is disbanded

 

Lean-Agile Suggests We Pivot the Matrix

The bottom line for any Agile organization is the delivery of value. Therefore Lean-Agile practitioners recommend creating long-lived, cross-functional teams aligned to value streams, rather than forming and dispersing teams as projects come and go. If your teams align to products or the value streams those products support, they will be together long enough to bond, to adapt lean-agile practices to their unique needs, to learn from multiple project experiences together, and to have a chance of performing at a high level.

But what do we lose if we pivot the matrix? Will architects become less effective over time because they’re not interacting as often with other architects? Will developers become bored and de-motivated if they work on the same product(s) for years? Will resource utilization suffer because we’re no longer juggling developer assignments from sprint to sprint?

Such risks are easily mitigated, and far outweighed by the advantages of product-team orientation. Cross-team collaboration can be fostered by adopting a CoE or “Chapter” model, as it’s referred to at Spotify, to encourage interaction and knowledge sharing between team members performing similar functions on different teams. Management can provide team members opportunities to migrate across teams periodically, to allow for individual growth and combat “ennui”. Finally, management must take a Systems Thinking view of the development organization, and strive to optimize for total throughput of value rather than sub-optimizing for resource cost or utilization.

 

Improving Engagement & Clarity of Purpose

The McKinsey study mentioned earlier makes clear one advantage of a matrix organization – employees operating in a matrixed structure expressed a higher degree of engagement and collaboration than those who were non-matrixed. Alignment to a product or set of products gives all team members a greater clarity of purpose, which is a key driver of engagement and motivation:

”higher levels of the ownership mentality predict higher levels of collaboration, organizational commitment, and corporate citizenship”

Delivering products that delight our customers is a mission most professionals can embrace enthusiastically. Particularly when bolstered by regular contact with and feedback from those customers, this purpose can drive tremendous results from teams that are aligned around products, and have full collective accountability for their outcomes. By contrast, those teams in which the “solid line” follows functional silos never have more than partial control or accountability for the actual results they deliver.

 

Making the Change

First and foremost, management education in Lean-Agile principles and practices is crucial to making the case for change. Middle management must be engaged and actively participating in defining the new structure, and how roles, accountabilities and rewards will pivot.  Managers may themselves need development plans, to ensure they are well-equipped to oversee product-oriented teams, rather than the functional teams they now lead. How well will your Software QA Manager function, once she becomes responsible for all aspects of certain products? Will she need training on other functional best practices herself? Addressing this risk openly and in an environment of safety will help everyone envision a different future, and reduce change resistance.

These managers must be further empowered and encouraged to take a broad view of the organization, its goals and its value-delivery process. They must be trained on Lean budgeting and portfolio management so they can envision the future in a matrix principally aligned around value-streams and products, rather than functions. Then they must be challenged by leadership to make it so. Without doubt, inertia will fight against this change in most organizations, so manifest leadership commitment will be crucial to sustain it.

Share
0
Rosanna Hayden
Rosanna Hayden

Related posts

March 8, 2021

The Challenge of Distributed Agile Teams


Read more
August 31, 2020

Waddayamean It’s Not Done?!


Read more

Comments are closed.

Agile Services

  • Agile Coaching
  • Agile at Scale

PM Services

  • Large Program
    Management
  • Program Problem-Solving
  • Program Health
    Assessment
  • Program Management
    Review
  • Merger Integration
  • RFP Management

AI Data Solutions

  • AI Data Solutions
  • Consulting Content
    & Articles

Social Media

Artizen-Inc-Logo-Header-White


Do you have questions?

Contact us

(855) 278-3678
Send us an email

Privacy Policy and Terms & Conditions

© 2025 Betheme by Muffin group | All Rights Reserved | Powered by WordPress