Skip to main content

The Karenina Principle

· 4 min read

Leo Tolstoy begins his novel Anna Karenina with the profound observation that:

“Happy families are all alike; every unhappy family is unhappy in its own way.”

Not to be maudlin, but an engineering development team is a lot like a family, especially where Tolstoy's observation is concerned. I would state the Karenina Principle as:

“Successful development teams are all alike; every unsuccessful development team is unsuccessful in its own way.”

I believe that engineering teams are more alike than different, that the management of a lawn mower engineering team is very much like the management of a software team. For software development, I believe the best example of the Karenina Principle is the Joel Test. Joel Spolsky has identified 12 simple yes-or-no questions that determine a successful software team from a doomed software team. Joel realized that successful teams are all alike.

I think of the questions of the Joel Test as symptoms rather than causes. For instance, Joel’s first question is “Do you use source control?” Having a version control system is very important, but it is not the cause of a successful team; it is a symptom of successful team. That which makes the team successful will naturally lead the team to implement a source control system.

I want to walk you through a scenario in an attempt to highlight the Karenina Principle. I draw this scenario in part from my own career, but I have found that many engineers have a similar experience.

Step 1: The train wreck. Big Company has horrible cost overrun and huge time delay on a software development project. The project is so bad that it is eventually cancelled. The company decides to take steps to reform its development practices. The company implements a formal methodology to enforce best practices.

Step 2: The bureaucrats. Big Co. places managers in charge of the methodology. These managers become specialists in the methodology rather than in the software development for which the methodology is intended. The methodology becomes an end in itself rather than a means to an end. More and more work is piled on to the developers. The software projects have cost overruns and missed delivery dates.

Step 3: The revolt. Engineers leave Big Co. and join Small Co. in order to do “real engineering”. These engineers have acquired a horror of methodology. They just build stuff, without the encumbrance of designs, specifications, schedules, architecture, documentation and all the things that they hated in Big Co.

Step 4: The tar pit. A year goes by and the engineers at Small Co. have not achieved their goals. What had started as a very successful project with lots of energy has become a disgruntled team. Costs are escalating and the schedule keeps slipping. More and more things seem to be going wrong with each passing day. The project has become an unholy mess. No one knows what is going on or how things work. There is no documentation, no design. The team fixes one thing and, in the process, two other things break.

Step 5: The inflection point. At this point, one of three things can happen: (a) Small will shut down the team or let it die; (b) Small Co will institute draconian methodologies as Big Co did; or (c) Small Co will bring in someone from a successful team to implement reform. If they choose (a) or (b), then the pendulum will continue swing from failure to failure. If they choose (c), then you will see, among other things, the team pass the Joel Test.

In our scenario, the engineers left Big Co. with the wrong conclusions. They equated symptoms with cause. They thought that methodology was the cause of the problems at Big Co. Big Co was an unsuccessful team. As such, there is any number of reasons why the company was unsuccessful. One thing is certain: the root problem at Big Co caused it to be unsuccessful without methodology and the same root problem caused it to be equally unsuccessful with methodology.

In our scenario, the engineers at Small Co reacted the same way as the leadership had in Big Co: they went to extreme. It is a natural tendency that you see in our culture: we swing from one extreme to the other rather than seeking the balance, the compromise. Big Co went from no methodology to methodology mania. Small Co went from methodology mania to no methodology.

The pendulum can be off center in an infinite number of places, but it is only balanced at one single place. That is the Karenina Principle. As a senior technology leader, you must seek that balance in your organization. When you do, you will find that you are just like all the other successful teams.