I never suspected I’d come to think matrix management might be a great idea for managing project-based, professional services firms like Atomic.
My undergraduate business classes exposed me to the potential downsides and conflicts related to matrix management. Additionally, throughout my professional career, I’ve observed the pain and frustration matrix management structures impose on new product development efforts. As a result, I’ve held matrix management in such poor regard for so long that I’ve simply equated the structure with bad organizational design.
As an example of the pain matrix management can inflict, let’s walk through a simplified, hypothetical scenario.
Matrix Management Pain
Let’s pretend PayCo, a payroll processing firm, has the following departments: Marketing, Customer Support, IT.
Team members work for a specific department. Each team member strongly associates with their department as it relates to their individual, vocational identity. Consequently, individuals have KPIs and incentives related to their departments.
- Is responsible for developing customer insights and driving inbound leads.
- Manages direct mail and digital campaigns.
- Has internal initiatives including new content development and brand identity updates.
- Is responsible for helping clients and client employees navigate provided services.
- Provides live-chat, phone, and email support.
- Has internal initiatives including response time improvement and developing better support documentation.
- Is responsible for keeping business infrastructure and client-facing technology services running and updated.
- Monitors and updates systems for upgrades and works through call tickets for issue support and bug fixes.
- Has internal initiatives including a database system transition and rewriting outdated ACH automation software.
A Special Project → Competing Incentives
PayCo decides to start a new, cross-functional project for developing PayCoGo, a mobile phone app that allows client employees to review their paycheck history. They assign a few team members from each department in a part-time allocation to the PayCoGo team. The team members eagerly meet PayCoGo’s project manager and align on a high-level project plan but now report to two managers and serve two sets of KPIs.
PayCo has doomed PayCoGo to be late, or not gain traction, for factors including:
- Team members assigned to the PayCoGo project have stronger incentives and measures related to their departments.
- Team members have a longer and more career-impacting relationship with their department manager than the PayCoGo project manager.
- The PayCoGo project manager has no insight into the capacity needs or timing of departmental operations or initiatives. It will be nearly impossible to anticipate conflicts or manage capacity and dependencies. Conflicts will slow the project down, and the team members will lose excitement, momentum, and team identity.
- Department managers will view the PayCoGo project as a distraction and change that might put their KPIs and incentives at risk. Department managers may assign the least-skilled team members to PayCoGo or give their employees cover to reduce their involvement in PayCoGo when departmental needs call.
I’ve seen this play out in real life because the departmental-centric, status-quo inertia of matrix organizational structures pulls innovation projects into a gravity well of doom.
So why might a matrix management structure work for a project-based, professional services firm?
Matrix Management with Project-based, Professional Services
Self-managing project teams connected and reporting directly to their client have always been our main organizational abstraction. Last year, adding delivery leads as core members of our product development teams further improved our product quality and the client’s project experience. This aspect of our structure has performed well historically and scales pretty well, since the size of teams doesn’t change as an office grows.
As our largest office has grown, we’ve felt structural pain in the employee support dimension of our organization. This work increases linearly with the number of makers in an office. We want to be sure that Atoms grow in their careers and as individuals through satisfying work, professional development, coaching, and human resources support.
A Possible Next Step
Project team composition and scheduling, sales, and employee support currently all rest on the shoulders of our office Managing Partners. I believe we can better serve clients and Atoms by creating separate management responsibilities around the functional areas of:
- Sales and project staffing
- Individual support of Atoms
Focusing the above responsibilities into separate, functional management groups allows a manager to focus on the unique characteristics of each functional area. For instance:
- Sales and project staffing work is: high importance, short-term focused, high and variable volume, and responsiveness oriented
- Individual support of Atoms is: high importance, long-term focused, bounded in volume based on number of Atoms, and can be mostly pro-actively scheduled
The separation of functional responsibilities helps ensure the short-term focus of client-facing work doesn’t starve the important, long-term work of supporting individual Atoms.
Segregating management responsibilities into focused functional groups also allows for more focused training and development of managers. Some Atoms will naturally enjoy client-facing work and others will prefer helping support their fellow Atoms. Therefore, the separation of responsibilities allows individual managers to focus on developing their strengths.
But doesn’t having two functional management groups impose two managers on any Atom and create conflicts through competing priorities and incentives? After thinking more about the project-centric nature of Atomic’s work, I don’t believe we face the downsides of matrix management I described above.
How Matrix Management Can Work
Several key insights led to me realize why separate functional management groups could work at Atomic:
- Most Atoms work in autonomous project teams, full-time on a single project, for periods of months.
- Teams only work towards KPIs tied to client and project success.
- Atoms focusing on client projects drive business success for both Atomic and our clients. There are no competing incentives.
- Having separate functional management groups does not impose competing KPIs on Atoms. Individual support managers serve the needs of Atoms; they don’t assign them competing priorities. The only priority is the success of the client project.
- Atoms track all of their client and non-client work in Atomic’s time tracking system. Time tracking data is accurate because it directly feeds invoicing and payroll. We can see if any Atoms are working an unsustainable pace or against competing priorities and provide them with support.
Separate, functional management groups could serve Atoms well:
- A group managing sales and project staffing will establish an Atom’s next project and team assignment. Any Atom could work with someone from the sales and staffing group to discuss future work preferences, the need for more team capacity on their current project, or even a desire to rotate from a long-running project.
- The relationship between individual support managers and their Atoms is independent of project assignments, and longer lasting. Atoms could work with their individual support manager on professional development support, annual compensation reviews, workplace interactions, or navigating any benefits or policy.
We haven’t tried organizing around a more formal matrix yet, but we’re strongly considering it. If you have worked in a matrix structure at a project-centric services company similar to what I’ve described, I’d appreciate you sharing your experiences in the comments section.