Introduction

"For decades we have known that some people are 25 times more productive than most in software engineering jobs. We also know that there are “gelled teams” which are consistently 10 times more productive than most across the whole project lifecycle.

In 1987 I built a gelled team by accident. It was an experience that I wanted to repeat, and for ten years I tried to do so, with increasing degrees of success. I discovered that (almost) everyone can become a super-programmer, and with a crew of super-programmers, gelled teams form up naturally. But I also discovered that I was playing with fire. Whenever I got a team ready to be really useful, there would be a bizarre negative reaction from all sorts of other people who were employed within the same organizations, but were not part of the teams I was working with. Sometimes this effect was so strong it could become a workplace hazard, and it always grew until the teams themselves were no longer able to function.

There was something very strange going on, that seemed to involve the cognitive state of individuals, as well as mysterious sociological effects at the organizational level. Worst of all, I had no idea why my odd collection of little talks, examples and jokes actually worked. There was already some evidence for a mystery here. Programming is labour intensive, costly intelligence work. Why has there been so little progress in understanding it since Weinberg’s The Psychology of Computer Programming in 1971?

I stopped teaching, and spent another ten years looking for a theoretical basis for the work, that would explain what was happening and enable further progress. It got to the point where I could pencil in some bits of neuroscience that didn’t exist yet, but had to be true for the cognitive and social aspects to make sense.

Now I can tell the story from the ground up, and describe exactly how to build super-productive gelled teams that make going to work a pleasure for all involved, explain where the dangers come from, and define the necessary pre-conditions for dealing with them. If you can’t establish the pre-conditions, don’t try to build a gelled team.

Best of all, this approach to “debugging the organization” addresses complex social issues without fuzziness. You don’t even have to be a “people person” to use it - that’s the benefit of solid understanding." -- Alan G. Carter on the Programmer's Stone blog