Ref:
Losada results on high-performance teams
Systems Intelligence in Leadership and Everyday Life 2007

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.

There’s a fantastic post about this by Steve Blank on his blog: The Elves Leave Middle Earth – Sodas Are No Longer Free.

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?

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 :)

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.

The chapters of a very similar older book (called “My Job Went to India”) by the same author are available online:

• Be a Generalist
• Be a Specialist

They are a good read.

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.

“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)

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.