Over the years, people have spent a lot of time thinking about what types of team structures work best in software development. Despite that, the truth is that most companies simply create something on the fly, based on what's going on and what seems to work at the time.
The big problem? What seems to work right now might turn out not to be that great of an idea down the line. After all, there are bumps in the road and it's particularly when you're going through a rough patch that you really don't want the wheels to come off. However, that's exactly when they do if they haven't been put on all that well.
Therefore, what other people have written on the subject of teams can be incredibly useful. As you probably don't want to explore the entirety of the literature, here we'll cover a quick summary of some of the best known structures for software development, as well as their advantages and disadvantages. In that way, you'll have a good guideline that will help you make some decisions about what works well for you and where you might want to spend a little bit more time doing some research.
We'll explore three different ways that people can be grouped together. Grouping them by function, grouping them by business, and a type of hybrid form, where you combine the two.
Grouping them by function
By grouping people by what they do, you put the same kinds of people together. So, you put your developers with your developers and your designers with your designers. We call this a 'functional unit'.
There are a number of advantages to doing things this way. The biggest one is that when you put people together based on function, then they can communicate, share ideas and learn from each other. That can be incredibly useful, as in this way information disseminates through the group.
So, even if you don't send everybody to a workshop, it is still possible eventually all of them will know what was taught there. Even better, jobs can be assigned to the people who know the function best. After all, the manager will know who knows what and assign tasks based on their expertise.
On the other hand, you can put people together based on the product they're working on or who they're doing it for. So, for example, you can have them work on the software package together, or if the package is big enough that groups work on individual parts of it, then one of those. Alternatively, if you have big clients who need a lot of attention, then groups can be assigned to that.
These teams are known as 'cross-functional' teams, seeing as the teams will have different people from different backgrounds working together.
Here there are several advantages as well – the biggest one being communication. After all, we communicate more with the people who we work together with on a product. And so, if we are closer together and being managed by the same boss, then we're going to find it easier to communicate and get things done.
What's also nice is because people work with a lot of people of different disciplines, they're going to understand better what different jobs entail. This can make things run more smoothly and can even mean that they'll get ideas from each other.
It's not all rainbows and sunshine, though. Communication between people who do the same kind of thing will be less common, so they won't find it as easy to learn tricks from each other. Another problem is that quality levels can vary, as well as work standards, due to there being no central management to make sure these things stay the same.
To solve all that, the concept of matrix management was conceived. It's kind of like the two ideas mashed together, really. The organizational structure is like that of a functionally organized team, with them having managers based on that. At the same time they'll also have another management structure, where they'll answer to teams where they'll be working together on one product, or client, or feature.
The big advantages here is that people both work with people who share their function, as well as with teams who work on the same product. This creates a lot of flexibility – something that can be particularly useful if a piece of software is a one-time deal or short-term. Developers can be assigned to a team for the duration, then when the team has done what it's supposed to, they return to their original function-based group.
Obviously, there are also more opportunities to learn and deliver best services from both people who do the same thing as you as well as who do different things. So, you can become a better coder, or designer, or programmer.
The disadvantages of matrix management
The biggest problem? This does increase the complexity quite a lot. After all, people will not just have to report to one direct manager but several. This can lead to confusion, crossed signals and a great deal of stress as people are forced to potentially work on several projects at once, without the managers being aware that they're not evenly spreading the work.
Another problem is that because workers have to answer to different managers, there is the potential for conflict between different managers, as they each feel their project should take priority. Similar, new projects might not get the attention that they should get, as the people assigned to them already have other obligations which get priority simply for being around for longer.
Choices, choices. Which is good for your company?
Well, that depends on a number of factors. One is the size of your firm. If your team is smaller, then the natural go-to structure is a cross-functional one as you won't have enough programmers, developers or designers to assign them one manager. On the other hand, if products are finished quickly and clients are numerous, then you'll want to stay away from a cross-functional design and will possibly benefit from using a functional one. Need a lot of flexibility with people being able to move back and forth between different projects quickly and effectively? Then a matrix design will work best for you.
Then there's the long-term goals of your company. Will it benefit more if the people who do the same thing learn skills from each other? Or would it be better if they learn skills across functions, so that they can work together better with people of other disciplines? Or is it actually best if they can easily switch back and forth between the two types of projects – complexity be damned?
The choice is yours
Now you know what the possibilities are, you can start considering how to weigh them. What works best for you? How can you see your company functioning? And what do you think will let your employees thrive?
Once you know that, then you know how to structure your company.
This is a guest post by Jessica Fender. Jessica is a professional marketer and agile enthusiast that successfully implements it as a head of content at OnlineWritersRating.com. She loves looking for the new techniques and implementing them in life. In other words, experiments and tests are her second nature!