Beware the Matrix Model?

And now for the fifth post in the series following my Drupalcon Austin session, entitled "Oh look, we're growing!" This post follows closely on the heels of the fourth post in the series which focused on small, cross-functional teams. One of the questions that post raises is in regards to management structure: who determines the outcomes of the teams and who manages individual team members? This common conundrum can lead to the implementation of a matrix management model, but we plan to avoid multiple managers per employee. Read on for the how and why!

Other Posts in This Series:

1. A Formula for Healthy Project Size Compared to Organization Size
2. Scaling Projects and Scaling the Organization
3. Unit Change During Project & Organizational Growth
4. Family-Sized Business Units & the Agency Holding Company Model
5. Beware the Matrix Model?
6. Communication Styles and Team Dynamics
7. Agile Versus Waterfall, Once and For All
8. Process Frameworks That Weather Growth
9. "Why" Not "What" Documentation
10. Project Manage the Organization
11. Plan or Pain?

Teams Versus Groups

When an organization moves to a team-based model, two distinct areas of competency emerge for each team member: the knowledge and ability required to complete projects as part of the team, and the discipline-based specialties that each team member brings to the table. For instance, a developer on a team is responsible for working effectively with their teammates to achieve the overall scope, while also bearing responsibility for specific development tasks relative to their skill set that others on the team aren't able to complete. This dual-responsibility tends to point to the historically-grounded answer of a matrix management model, where each team member reports to both a team manager and a discipline manager.

At Metal Toad, we’re defining our matrix of sorts as teams versus groups. Teams will be the business units responsible for fulfilling client projects, while groups will maintain standards across disciplines (for instance, the PM group will maintain processes and techniques for successful project management, while the development group will maintain development standards and practices). However, we’re looking to steer clear of matrix model and avoid any one employee having multiple managers. Why? Well…

The Challenge of Matrix Management

The matrix model certainly has some things going for it, but it comes with plenty of challenges and complexities. First and foremost is the need for multiple levels of united fronts from all levels of leadership. One of our primary goals in a shift to production teams is to decrease the communication overhead required to keep things humming. Multiple managers can and usually does trend the opposite direction, if anything. Both managers need to present highly aligned communication and have the same goals (AKA the united front), or the employee receives mixed messages. Clearly communicating the model of the matrix itself to the management team is often the complexity that trips up matrix organizations to begin with. And if the communicating the matrix model to those responsible for implementing it is too complex, then maintaining and growing it is near impossible. In short, we’re saying no to matrix management. The question then becomes…

Who Leads? Who Manages?

The distinction of leadership versus management is at the core of a successful model with production-focused teams and discipline-based groups. To lead a team consists of many things: inspiring action, directing outcomes, challenging groupthink, contributing to efforts, and supporting team needs. To manage employees takes a slightly different twist; managers should focus on directing and supporting their career growth, challenging them to develop professionally, removing blockers so they can get their day-to-day jobs done, and aligning their personal goals with high-level company goals.

Metal Toad has historically focused on making sure our project managers understand that their role is to lead a team to project outcomes, not to manage the team’s members. This applies in a cross-functional, high-autonomy team business unit model as well. As such, we plan to continue having PMs lead business outcomes for their project team by being a peer rather than a manager, while employee management will be discipline-based. This should result in individual employees feeling empowered to contribute their knowledge and skills to team outcomes, while being managed and supported in their career development based on their chosen area(s) of specialization.

Catch me at the Digital PM Summit

Interested in the topic of organizational growth from a PM perspective? Join me and a bunch of fellow PMs at the 2014 Digital PM Summit in Austin! I'll be presenting a talk similar in nature to my Drupalcon presentation and related to this blog series, but new and improved after additional months of experience and iteration. The Bureau of Digital Affairs did a great job with the inaugural 2013 event, and 2014 promises even more in store. With a great lineup of speakers, topics, and of course after-parties, you'll definitely get your monies worth. I hope to see you there!