It is not ABC!

by MG

Men are wise in proportion, not to their experience, but to their capacity for experience. (George Bernard Shaw)

What really is this “capacity for experience”? Surely, it is related to “Growth Mindset” which is a belief and preparedness to change for the better in light of new knowledge. It is also related to curiosity and ability to explore—openness with healthy scepticism. And, perhaps the most important element of “capacity for experience” is the ability to experience analytically and draw lessons which work.

The most instructive experience is, of course, failure. And, not just grand catastrophic failures—an unsuccessful rocket launch or a building collapse—but the stuff that we experience everyday: a bug, a lost sale, a bad presentation, a missed deadline, etc. They upset us, dent our enthusiasm, and might make us cynical. This is more so when such failures repeat and we do not seem to have learnt anything from these experiences.

Our default toolset to deal with failures is ABC. That is, we instinctively Accuse, Blame and Criticize. It is natural that we ask ‘whose fault is this’. So, if we are late for the meeting, it’s the cab driver who took the wrong route! We are wired by evolution to see agents and intent, and that is how we tend to deal with failures as well. Alas, it is rarely helpful, it seldom changes things for the better and it only reflects a poor “capacity for experience”.

We deal with complex things all the time. Any outcome is a result of many interconnected events. A defective report, for example, cannot simply be blamed on the developer who did not incorporate the required data correction in her code. Perhaps, the access to the API she depended on was not available. Maybe the API itself did not account for an unanticipated scenario. Resorting to ABC would not lead to a lasting solution, would not solve the problem for ever. All one might possibly have is a temporary satisfaction of identifying the ‘culprit’.

One with capacity for experience should be able to see deeper, and would know that the right thing to know and learn is not who the culprit is, but where the system failed. A great way to do that is to ask earnestly, ‘What could have been done differently?’ (WCHBDD). Maybe, we would learn to be better prepared for unexpected data scenarios, perhaps we would use better components in our solution, or perhaps we would test for more cases. While none of them would specifically guarantee that there would be no errors, each of them would make the end product better.

The key thing to appreciate here is that an outcome is result of a process, a system which is built of many parts and many stages. And, that zero defect at the end of pipe does not mean lack of errors altogether. And stuff happens—it is not possible to be errorfree. Yet, it is possible to be zero defect if we ditch ABC and adopt WCHBDD!