A matrix organization allows you to build teams with a high degree of specialization and top-notch skills, plan your resourcing easily, and encourages sharing knowledge between product teams. A matrix organization is great. Except that it’s not, not for developing software.
It’s not great when coders don’t do any testing because it’s the QA department’s responsibility. It’s not great when it takes a week to go through the DBA team to have a column added to a database table. It’s not great when developers have never directly talked to an actual end-user.
Please take a number. We will be able to look at your request in three or four days.
This is why startups get things done quickly. They have a small number of people, and most of them can and will do everything. There is no DBA team and no red tape. You can just add that damn column when you feel like it.
If you have separate departments for customer support, QA, development, product management, and so on, you should seriously consider tearing down those silos and replace them with real teams.
Of course, there are limits to what responsibilities teams should have to be successful. You probably shouldn’t have to set up your own network infrastructure, negotiate the rent, or unblock the toilet. If you have someone to do these things for you, that’s great. If you don’t… well, that’s life. I would rather unblock a toilet myself than try to keep it in. You?
Related posts:
If you liked this, click here to receive new posts in a reader.
You should also follow me on Twitter here.
{ 1 trackback }
{ 9 comments… read them below or add one }
Are you saying everyone should do everything? How is that supposed to work?
Everyone should do everything? Yes and no.
Yes: Teams should be cross-functional and self-organizing. The team must have a shared goal, not multiple slightly different goals from different departments. Everyone should be able to do anything within their abilities to achieve the team goals.
No: People are different and have different strengths. The team should decide amongst themselves how the work is divided. Probably there will be people mostly concentrating on coding and others mostly concentrating on customer support, for example. But it doesn’t mean that coders should never touch a support case.
Kinda generically related, but:
“A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects.”
— Robert A. Heinlein (or so widely attributed; couldn’t tell you where it was written)
Thanks Wes, that quote really resonates with me probably because I guess I’m a bit of a generalist myself.
I think it all depends on the how the teams are merged together, it could be very useful to have a database expert that reviews every modification to the database to ensure it’s done correctly. The problem with being a generalist is that you can’t be the expert in every development area. As a part of a startup, I need to be able to do pretty much everything, however as the team grows I can stop doing things I don’t like and that I’m not the best at and start focusing on my strengths.
There is a problem with over-specialization too, but a few expert here and there can be useful depending on the situation. A database expert would be crucial for a high-performance application, though a programmer should not have to wait for a modification to the database schema. I think it all comes down to how the hierarchy is done and who decides, the more equal people are, the better and faster the work is done.
Thanks Michel, I agree with your points. This reminds me of The Passionate Programmer by Chad Fowler. Fowler argues that you should be a generalist, and also that you be a specialist. A specialist knows a subject very deeply, but that doesn’t mean he should know nothing about everything else.
The chapters of a very similar older book (called “My Job Went to India”) by the same author are available online:
They are a good read.
An organization where everyone can do everything will likely be a great success or a great failure with little room for anything in between.
When many people can be changing different parts of a system communication and documentation become critical. In the example of a developer adding a column he/she could be breaking existing programs if the programs were counting on multiple tables having the same structure. Of course the ideal situation would be if programs were designed to not have such requirement, but much too often the requirement is there.
I think it is more important to have good communication than having the ability of all people in a team making changes all over the place without control or forethought.
As for tearing down “silos and replacing them with real teams” it is an oversimplification at best. If management had the right leadership those “silos” would have been the right teams for the right tasks to begin with.
I think the author of this blog entry has confused bureaucratic poorly organized structures with proper division of labor. There is absolutely nothing wrong with having a QA department just as there is nothing wrong with not having one. It is all about how a business structure is organized and the quality of the people in it.
Moreover, asking all people to do all the different areas of work does not allow room for looking the best place where people fit. You could have a developer that is absolutely great at creating at entire new system that is mostly bug free, but he is not good at testing. Should you hire a less competent developer that is better at testing, but far less capable at getting the bulk of a new system up and running?
There there is that little issue called budgets.. a company may not have the money to hire all senior developers. They may only be able to afford mostly junior people and a few Sr. So should the QA and last check be done by the Jr people or the senior people? In the fantasy world were it is always ok for all to do everything the Jr developers would be let free to debug their code and implement into production without having someone not only more experienced, but more familiar with the business and the requirements, do a final check.
Thanks for your insights, Francisco.
I’m not saying there should not be division of labor. I’m saying the division of labor should be done as best fits the team and tasks at hand, not as dictated by an existing corporate hierarchy.
The best team structure of course depends on what you’re doing. My experiences are chiefly with building software products. And in my experience, small self-organizing teams work the best. I’m not trying to say that nothing else can ever work, even though it might have sounded like that :)
Building High Performance Software Teams: http://bit.ly/656pLy
This comment was originally posted on Twitter