Reliability vs Efficiency

Having been - a little - disappointed by the Wieck/Sutcliffe book I talked about here, I went back to the source and dug out the article :from which the book draws some of its stories (specifically the narratives of operations on aircraft carriers). “Collective Mind in Organizations: Heedful Interrelating on Flight Decks”, first published in 1993 and collected in Making Sense of the Organization.

Its a stimulating read (and convinces me of the value for practitioners of going back to the source - leave the management books for management types…). Among many insights - the contention that organisations concerned with reliability offer more examples of adaptive group intelligence (the “collective mind” of the title) that those that are concerned with efficiency.

In software, agile practices are directly concerned with building strong, adaptive teams - so one of the misunderstandings that arises when agile is implemented is that practitioners come at development process from the direction of reliability (we can build an iteration’s-worth of features again and again, under precise steering from product owners) whereas management thinking is grounded in organisational thinking that emphasises efficiency (lowest cost, predictability).

Organisations that develop reliable group practices often do so because “the consequences of any lapse in attention are swift and disabling”. At the other end of the scale, repetitive industrial processes are clearly areas in which cost and predictability rule. Software development is in the middle, and it’s going to be interesting to see how the tug-of-war between reliable (agile) and efficiency (outsourcing and its friends) continues…

One Response to “Reliability vs Efficiency”

  • Kevin McGuire responded:

    At Eclipse we turned to a milestone process primarily because the previous way of working was just too hard on the people. The historical revisionists will cite issues around reliability but that was actually a byproduct, not the goal. Yes we wanted to reduce the number of bugs but mostly we wanted to reduce the end-game chaos that always took such a huge human toll. Somehow this notion tends to get lost in the discussions; that as knowledge workers, good things happen if you can make the process fit our human limitations of planning, energy, and organization. Methodologies that ignore these factors are doomed to failure. Plans are easier to change than people.

Add your own comment...