A lot of thought has gone into what type of team structures are best suited for different industries. And yet, often when new companies are started the managers simply play it by ear – creating something on the fly that they believe will serve them best. The thing is, that’s a lot like re-inventing the wheel.
Even worse, as we can’t see the problems coming that are some distance away and you can’t plan for something that you don’t see coming, these systems often seem to work just fine right until the moment they blow up. And as those are often the moments we need them to function at their best, that’s not ideal.
For that reason, it pays to know what other people have said on the subject. Here we’ll explore some of the styles out there, as well as their benefits and downsides. In that way, you’ll at least know the possibilities and can from there explore what will suit you best.
How should people be grouped together?
The first thing that needs to be considered is how people will be put together. There are two possible approaches here.
If you group people by similar function, then you’re putting developers with developers and sales people with sales people. This type of structure is commonly referred to as a ‘functional unit’. The advantage to creating teams in this way is that there is a great deal of efficiency as developers, for example, have different expertise and in this way the job will be more likely to end up with the developer who is most likely to be able to do it well.
A secondary advantage is that because you’re putting all the people who have a specific expertise together, they have more opportunities to learn from each other. This should mean that over time the whole team will become better as they learn each other’s skillsets and benefit from each other’s questions.
If you group people by business, then what you’re doing is putting people together in terms of business value. So, you can put them together based on product, product feature, or same customer, among others. These groups are more commonly referred to as cross-functional teams.
Here, the big advantage is in terms of the speed of communication. After all, though we might share a great deal with fellow sales people or fellow developers, the people we communicate with are the people we’re working with on a daily basis. By grouping people based on this structure, work goes more smoothly and more effectively.
As an extra bonus, people will be working with a lot of different proficiencies, which means they’re going to be learning a broader set of skills and better understanding of other roles in the company. This will make it easier for them to adapt and give a better understanding of other functions’ timelines and needs.
On the other hand, the communication among project groups become less effective, as there is less chance and reason for them to communicate. This can lead to different standards for different groups. Something that is slightly less likely to happen when groups are organized functionally, as all the developers will communicate, for example, and be more likely to keep to the same script.
One solution to this problem is what is known as ‘matrix management’. The idea here is that people have more than one reporting line. The basic structure is similar to the function structure outlined above, with the function having one overall manager, say a development manager.
But individual members from that group will also be working with managers outside of their developer group and report to a different manager who is responsible for a product, a feature or a customer. This has several advantages. For example, it creates greater flexibility as it allows people to work both with people who have the same function as well as with their individual teams who are working on a product.
It also creates greater flexibility as when teams working on a product or a customer dissolve – say because the customer goes or the product is phased out – then they simply return to their own group, from where they can then easily be reassigned should the need arise. Also, learning is broader as people can both learn from people within their own function as well as cross functionally.
This does sound like the best of both worlds, doesn’t it? At the same time, there are a few disadvantages.
The Disadvantages of Matrix Management
The biggest one is the extra layer of complexity that is introduced into the company. After all, suddenly people who work in the company won’t have to report to just one manager but might have two (or even more). This can lead to a great deal of confusion.
It can also lead to being more difficult for managers to oversee what’s actually going on and who is doing what. Even worse, some projects might end up receiving little to no attention as the people who are working on this team also have the responsibilities of other teams to consider. These might even end up taking priority for the simple reason that they’ve been established longer.
This might then not come to light because of middle management being overburdened by too many responsibilities and because they’re juggling too many balls at the same time.
So Which is Right for You?
Obviously, that largely depends on the business you’re in. In some cases the decision might be made for you. For example, if your team is small and you only have one developer and one salesperson, then chances are you’ll start off with a cross-functional design.
Similarly, if you’ve got the type of business where products have short release cycles, then you’ll be better off using a more functional approach – possibly with some matrix overtures to make sure that individual products and projects get the attention they deserve.
This should hardly be your only concern, though. You should also pay attention to what the long-term goal of your company is. Will it be more beneficial for your company if people of the same functions learn from each other or is it better that people of different areas work together and learn each other’s skills?
Similarly, you have to ask yourself if the extra complexity of employing a Matrix management system is worth it for your company. Will tackling the problems that functional and cross functional designs have outweigh this extra complexity?
Nonetheless, now that you have this oversight, you’re in a better position to at least know the upsides and the downsides. With that in mind you can consider further resources about these structural systems.
And that will be useful. After all, forewarned means forearmed.
About the author:
James Scott, experienced writer and co-founder of Essay Supply. I am an experienced creator of a successful web project with skills of project management and leadership. Apart from this, I am also musician and loving husband.