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:
- The Birth of the Grumpy Asshole Programmer
- Do You Make These Mistakes When Recruiting Software Developers?
If you liked this, click here to receive new posts in a reader.
You should also follow me on Twitter here.
Comments on this entry are closed.
{ 12 comments }
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 :)
I see no other good way to go about software than small self-organising teams. Most software developers need to have knowledge and skills that overlap the neighbouring areas. Only then can they get the whole of their work done. It takes a lot of time and effort to learn to effectively work around all the red tape that some organisations have and it still never amounts to the same.
I think it’s clear that the best way to organise a software company is to use small startup like teams. It is well known that only the people actually creating the software know what needs to be done and they need the room and power to be able to do just that.
However, not many larger companies really work this way. Maybe it’s just in the DNA of organisations to grow into a halt. I guess that’s just as well, because how would startups make it, if the existing companies would be as effective as they are?
When companies grow, they tend to start organizing work heavily based on financial decisions. Traditional management wisdom says that operations are cheaper when you move similar functions to big units, thereby invoking economies of scale and whatnot. Even if this may not be exactly true for software development, managers still tend to do these “safe” decisions. If things go wrong, at least they won’t be blamed if they did what everyone expected. This is called failing conservatively.
There’s a fantastic post about this by Steve Blank on his blog: The Elves Leave Middle Earth – Sodas Are No Longer Free.
Yes, I guess that it’s a management thing to protect against failing in the politically incorrect way. They do say that there are no good project managers, just lucky ones. So, it’s just self-preservation.
The downside of it is that it’s also the beginning of the end when you start going that way. The spirit will fade away and all that will be left is mind-numbing drudgery, which is exactly what I wanted to avoid by becoming a programmer.
Programmers get to create wonderful things and that’s what the job should be a lot about. About creating something profoundly beautiful, about being able to transcend our everyday reality to something truly magnificent. Being a programmer is a wonderful thing and to have the people who truly appreciate the engineering and the art of it I think it is needed to keep the sense of wonderment about it all.
The thing is, I think one might need to be a programmer to see what I mean. A lot of people don’t have that and hence operate from different premises.
I think Losada’s results on high-performance teams are interesting.
Ref:
Losada results on high-performance teams
Systems Intelligence in Leadership and Everyday Life 2007
{ 1 trackback }