When our team grew our matrix structure met significant challenges. Instead of adding more functional managers or additional management layers I decided to extend management responsibilities horizontally. We pulled together comprehensive cross-functional teams, assigned teams to the same projects, and measured team performance (over individual performance). Within 3 months we witnessed a measurable improvement in quality, productivity, and customer satisfaction.
The organizational structure guides the operation of day to day activities. It is one of the pillars of organization design. It represents the formal guidelines around communication and collaboration.
[caption id="attachment_1678" align="aligncenter" width="576"]
McKinsey 7s Model of Organization Design[/caption]
This article is to share my recent experience and observations, and the conclusions they've led me to.
General Notes About Matrix vs Team Organization Structure
[caption id="attachment_1689" align="aligncenter" width="468"]
matrix organization struture[/caption]
- In a Matrix, Functional Management means opportunities for individuals to mature and advance their skills
- In a Matrix, staff members may feel frustrated trying to serve two managers with potentially competing interests
- In a Matrix, there is an increased potential for isolation, called the "silo effect," where functional organizations don't integrate their knowledge and experience
Scaling a Matrix Often Implies Adding Layers of Management
I manage a business unit that is part of a comprehensive technology consulting company. We are mid-sized with 13 offices and 200 employees. The business unit I am responsible for focuses on delivering high-performance eCommerce experiences and a fully integrated back-office for small to medium size companies. Our projects are technical and involve a variety of skill-sets. The projects are large enough that they often span several months but usually won't require all resources full attention throughout the entire project. So resources will not be dedicated to one project but have multiple projects.
Over the past 2 years our practice has changed considerably; we have doubled in size, have started taking on bigger projects, and have adopted agile methods. As we have more implementations in the wild support requests have increased in frequency. We've separated managed services to enhance customer relationship with formal SLAs for rapid response time and quality.
At one point I made a list of our most difficult challenges:
- Prioritization & Coordination
- Managing Quality
- Meeting Timelines
- Managing Budgets
- Customer Satisfaction
Reflecting on these challenges it became clear that our organizational structure was not well aligned with our work.
- Interruption Driven Development: with multiple projects and support requests pulling resources coordinating between the PMs for resources was inefficient and centralizing project management (e.g. PMO) was impractical
- Technical issues were rare; most developers had the skills to execute on their projects and we had made an initiative to create a foundation for our development that served as a launchpad for new developments
- Project managers were a bottleneck but since they were measured on the project level then project efficiency would often be emphasized at the expense of resource utilization
- Onboarding teams to projects was inefficient: Each person brought something different to a project and it would take time to get a project team up to speed to adapt to each person's unique personality / skill-set
I needed some way to scale, plan, and improve quality. Perhaps if there was a greater need to stratify technical expertise or a wider variety of projects then a matrix would have lent some advantages. However in a fast paced environment, context is a vital ingredient which a team organization structure could bring.
An organization that relies on the "boots on the ground" has the context it needs to make decisions before they escalate and become major problems. The thought was that if I empowered the individuals doing the work and measured success as a team, teams would be incentivized to resolve issues that I didn't know existed and therefore improve quality while remaining nimble to our client's needs. So I decided to tighten the organizational structure around teams.
Transition to Teams
I decided to make a rapid shift to teams. I used the following criteria for selecting teams:
- Complementary skills
- Complementary personalities
- Balanced teams (no one team purposefully stronger than the others)
I made an effort to educate team members on operating within teams. Unlike our previous matrix structure, teams would act like franchises. Each would have responsibility for the business goals like utilization, quality, and customer satisfaction. Since each team would have the same projects, their daily standup would be together and their job would be to collaborate often to ensure that interruptions were kept to a minimum, roadblocks were addressed in a timely manner, and important issues were escalated quickly.
The Result: Metrics
The result was unambiguous and positive:
- Utilization improved from ~65% to ~75%
- Productivity as measured by realization improved from ~80% to ~90%
- Client relationships as measured by number of escalated issues reduced by %90
The metrics did not immediately materialize but took several months. In that time some team members were moved from one team to another. In some cases team members that were not successful in one position were changed to another position.
Why Teams Worked for Us
After reflecting on the experience, I've come to some of the conclusions:
- When constant change is present, empowering bottom-up leadership enhances agility
- When team members share the same context, continuous improvement will occur organically
- When vertical management is removed, self-organizing teams will resolve issues before they become problems
- When multiple projects are present, team members should share the same portfolio so planning can be performed by the whole team in order to identify dependencies and mitigate risks
- Teams encourage an adaptive approach to fit a team's unique mix of skills and personalities
- Tracking team metrics over individual metrics encourage a positive competitiveness between teams and a support system within teams
- Teams are more scalable because they allow for a more adaptable self-organizing model
When a team is balanced and working together morale is significantly increased, they build pride in their own successes and strive to achieve better and better results. Our transition from Matrix to Teams made us more productive, increased the quality of our work, and increased customer satisfaction. It insulated teams from change that happens outside the team while leveraging one another to resolve issues within their own portfolio.