One of the hardest things to get right at any organization, especially as it scales, is how teams are organized and work together. You also have to factor in whether certain employees will work well with certain managers, potential personality conflicts, areas of growth for high performers, and the list just goes on…
At the end of the day, what really matters is how well you can serve the needs of your customers. Hence, you need to find an organizational structure that balances the needs inside the company while still delivering a high-quality product or service.
If engineers only work with and report it to other engineers, they likely are getting great mentorship and management; however, their teams may not be fully equipped to solve all of the problems that matter to customers. But, if engineers were always interspersed with other disciplines, their teams might be great. It’s all in customer problems, but their managers might need to gain the skills to help them grow as engineers.
Matrixed organizations are a potential way of balancing these problems and finding the best of both worlds. In this article, we’ll learn about the pros and cons of a matrix organizational structure, examples of how it works, and more.
Having a matrix organizational structure is a way of potentially solving this problem. Employees are organized into both functional groups and product groups.
In a matrixed organization, each employee in the company has:
In a matrix organization, it’s unlikely that your career manager is also the one directing your work (likely with the exception of engineers).
This allows organizations to group people together into teams that allow them to best solve customer problems. At the same time, it’s still encouraging and enables mentorship from employees who can help other employees grow and understand the work that they do.
The dual-reporting structure of matrixed organizations helps balance the need for specialization and the need for cross-functional collaboration. However, matrixed organizations are more complex to run and involve more setup and maintenance.
Matrixed organizations are very common in the technology world, especially in software development. Most teams that create software that goes out to customers are in some form of a matrix structure.
The matrixed org structure is the default for most of the technology world that produces B2B or B2C products. Product teams at Google, Facebook, LinkedIn, Amazon, and most startups organize into a matrixe structure to give each team the right mix of autonomy and accountability. This is because (typically) no individual person in a software company has the full skill set to build and maintain high-quality software and then take it to market.
To make a great software product, you need great engineering, great design, an understanding of customer problems, a solid business strategy, the ability to measure and understand the impact of the future you release, and more.
In the modern tech industry, it’s much more common for employees to specialize in one of these areas, e.g., become software engineers, product managers, designers, data scientists, or marketers.
To get all of the skills you need, you need to group these people together on a team, like this:
These are commonly referred to in the industry as product teams. Depending on the type of software or product that a team is working on, they will have:
Each of the people on this team will have a separate career manager, so the product manager will report to a director of product management, the designers will report to a head of design, etc.
However, the product manager and engineering manager will likely direct the work that this team does with partnership from the rest of the team.
There are both pros and cons to structuring teams this way. Advantages include assembling the best skills for the problem, easier re-organizations, and more cross-department collaboration. Cons include its complexity and overhead, stakeholder management, and the difficulty of staying organized and efficient.
Let’s dive a little deeper.
By forming teams with diverse skill sets, you have the option of assembling strong teams that can hopefully build the best product for your customers.
Each team in the company doesn’t have to have the exact same composition — you can customize who’s working on what problem and still keep a relatively neat organizational structure.
This means that if your team was focused on customer acquisition, it might include folks from the marketing team. Whereas, if you just focused on backend optimization of the code base, you wouldn’t need a designer. This allows you to assemble the skills that you think will best solve the problem for your customer and hopefully get you to the best outcome.
While reorganizing teams is never easy, it is easier to change people’s functional grouping than their career managers.
The most important relationship that someone has with a company is with their manager. Numerous studies show that whether or not an employee likes their manager is the #1 leading indicator of whether they’ll stay or leave.
As companies grow and evolve, which is especially the case in the technology world, you’re likely going to need to change the team structure to fit the current goals of the company.
The way that you need to organize your company when you have 40 employees is going to be very different than when you have 200. Using a matrixed structure means that you can reshuffle the functional teams without running the risk of changing people’s managers.
The more teams that are built up from people across the departments the more organically information will flow between the departments.
Needless to say, it’s easier for engineers to understand what design is doing when they sit together in a cross-functional team all day.
You tend to have less siloing between the different departments in a matrix organization.
When you create the two layers of reporting to make a matrix organization work, you’re increasing the complexity in the company. The increasing complexity of the company adds management costs and likely requires more skilled managers.
Whenever you’re doing employee reviews, you need to get the perspective of each employee from both their functional manager and their career manager.
It’s harder for their career manager to fully understand the work that they’re doing because the career manager likely needs to see their day-to-day progress.
Because most of the heads of each department are no longer directly involved in the day-to-day work of all of their employees, the need to find dedicated stakeholder management processes that work for the size and the scale of the company becomes more important.
In a matrix organization, you can no longer assume that your manager is aware of 100 percent of the things that your team is doing. You need to find ways of servicing and getting buy-in for the work that will have the biggest impact in the company but also potentially carry the biggest risks.
When you’re pulling together people with different skill sets and perspectives, you need to have a way of keeping work organized and efficient so that your team is churning out as many valuable things to a customer with the highest degree of confidence they can.
Virtually all of the ways modern software teams stay organized (scrum, agile, etc.) arose from the need to keep teams of diverse skill sets and interests on track and accountable for important projects.
Most of the modern product development workflow — concepts like product reviews, design reviews, specification documents, business requirement documents, user stories, story points, etc. — arose from the need to explain scope and timelines to other employees with a different skill set than you.
If everyone in the team had the same skill set, passing requirements between each other would be much easier.
This complexity is worth the cost of better solving customer problems, but it still is a notable disadvantage of the matrix organization.
The matrix organization has become the standard practice of the majority of technology companies and you can find this structure at all big-name technology players such as Google, Microsoft, Facebook, Uber, Amazon, and more — especially in departments that develop products or work on Hardware devices.
A matrix structure is something that all companies should seriously consider as their products become more complex and you become more reliant on employees with specialized skill sets who need to collaborate across departments.
The way that employees are organized is one of the foundational elements of company culture and the way in which work gets done. Finding the right structure for your team and company is key to success.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Product crises happen—bugs, breaches, or PR disasters. Here’s how PMs can plan ahead, stay calm, and lead through the chaos.
John Arquette shares his experience working in the early days of ecommerce and how it’s drastically transitioned over time.
Discovery isn’t always worth it. Learn when to skip the research, trust your gut, and ship fast without slowing down your product team.
Mike Fantigrassi shares his experience helping transition NASM to a product-led growth model and the challenges that came with it.
Learn more →
