I’ve worked in a variety of organisational settings including matrixed and non-matrixed. Based on this experience I thought I’d write up a few observations about organisational structures.

Traditionally companies have been organised into functional teams. More recently, partly as a result of Scrum and Lean for Software Engineering, companies are moving to departments containing cross functional product teams. Some organisations have a mix, for example, design might be a functional department but other departments might contain product teams. Other companies try to combine function and product into a explicit matrix structure. This ensures both product and function are represented on the management team.

As it happen I don’t think pure examples of either of product or functional organisations really exist. Even organisations without a formal matrix structure will have an implicit matrix. I will go through a couple of examples. I will also explain why Lean advocates oppose what I call a function led matrix and suggest moving to a product led matrix.

Functional Teams

Functional teams has been quite a common structure for organisations. A company organised by functional teams will have departments like Product Management, Project Management, Design, Engineering, Quality Assurance / Testing. This can add a lot of handover to the work. Worst case is the work is handed from one department to another until it is complete.

Functional Departments

The advantage of organising by functional teams is that:

• Line managers are from the same field as their staff
• So recruitment for a skill set is always handled by a person in the field
• Somebody, the line manager, is considering the assignment of a skill set across all projects/teams
• The line manager can use assignments as staff development opportunities
• There are economies of scale for training as it can be organised for entire specialist teams

But their are disadvantages:

• Work may have to be shifted between departments, thus imposing big handover challenges
• Staff can be reassigned to other projects at short notice thus undermining the benefit of long running project/product teams

In reality projects teams are usually assembled by assigning people from different functional departments to a cross functional team and the work is done in the team. Which is what I call a function led matrix.

Function Led Matrix

A function led matrix has functional groups as the dominant axis of the matrix but acknowledges that projects (possibly products) are cross functional and span departments. This minimises the cons of functional departments – shifting work between departments and reassigning staff – but does not eliminate them.

This type of matrix might be appropriate in a software house providing teams to a variety of clients.

Function Led Matrix

Advocates of Lean aren’t keen on matrix organisations – and it is function led matrixes they are thinking of. For example Larman and Vodde (2009) suggest “Avoid … Matrix organizations in product development” (p. 250). The basic gripe is that matrix structures give individuals two reporting lines (function and project), but more significantly a matrix increases the number of managers hence reducing the average productivity of the organisation. Larman and Vodde claim the self-managing teams of lean-agile make matrixes unnecessary by moving management responsibilities to the teams. I think the argument should be is less about self-managing teams and more about putting emphasis on product teams.

Product Teams

Companies are increasingly moving to permanently embodied cross-functional teams. Scrum mandates this type of structure and others, such as Lean Software Development and Marty Cagan of the Silicon Valley Product Group, encourage it on efficiency grounds. Silicon Valley Product Group: Dedicated Product Teams gives an example of a typical e-commerce company with teams like “Search and Recommendations,” “Product Pages and SEO,” “Fulfillment Systems,” “Infrastructure,” “Rapid Response” and “New Business Opportunities.”

Product Groups

The pros of this approach are:

• Teams work on the same product over a long period of time
• This maximises product knowledge within the team
• Which increases productivity
• The product group manager is solely responsible for the output of their group – the one wringable neck of Scrum.

The cons are:

• Team members are stuck in a product silo and, depending on company policy, have to apply for jobs to move rather than just being reassigned.
• Staff development and recruitment are the responsibility of somebody who is from a different field, e.g. a product manager might be responsible for hiring all of the project managers, designers, engineers, QA under them.
• The product group manager, or whoever runs the team, has less time to do their day job (i.e. product management) because they have to do all the jobs related to running a team.

Although the pros are very compelling however I believe the cons undermine some of the advantages.

Larman and Vodde (2009) suggest introducing “Communities of Practice” with a Community of Practice Coordinator, budget, etc to overcome the limitations. The authors push the self-organising aspect of this but it is fulfilling the “function” aspect of the organisational structures described above and, to me, is a form of matrix … the product led matrix.

Product Led Matrix

A product led matrix is similar and has the product teams as the dominate axis but acknowledges the role of practice leadership (i.e. the Community of Practice mentioned by Larman and Vodde, 2009). The practice leads ensure/advocate standards across teams, help or organise recruitment within their community, etc. But they are outranked by the product group managers and in a conflict of interest will generally lose. At the extreme the practice lead might be the line manager for the people in the practice but this isn’t necessary – and Lean / Scrum types would oppose. At the other extreme the practice lead just exerts influence rather than applying direct management power. At the light end of the spectrum an organisation might not even realise it has a matrix structure – a situation I refer to as an implicit matrix.

This type of matrix is very appropriate for product development, including most software companies.

Product Led Matrix

As I mentioned above I think the “Communities of Practice” mentioned by Larman and Vodde (2009) is a light version of the functional axis in this matrix. Their Community of Practice Coordinator is the Practice Leader in the chart.

Personally I think a light weight product led matrix is the best of the options available. It has the advantages of the long term product teams but uses some form of practice leadership to counter the problems of pure product teams. There is a danger, however, that the practice leaders will feel disempowered as they can set standards but might not be able to enforce them. None-the-less it is better than nothing and cheaper than a full matrix.

References

Larman, C. and Vodde, B. (2009). Scaling Lean & Agile Development: Thinking and organizational tools for large-scale Scrum. Addison-Wesley.

Silicon Valley Product Group: Dedicated Product Teams