This month, IT Chronicles reached out to executives, thought leaders, experts, practitioners, and writers about a unique initiative. ITC will donate to Second Harvest for every article submitted in December by our past contributors. Thank you to all who contribute to this food drive. We appreciate your knowledge and leadership.
Some people know me as The IT Paradigmologist. Note the ‘The’. Although I came up with this eye-catching job title for marketing purposes, it does reflect how I have spent – some would say wasted – a considerable part of my career. Paradigmology means the study of paradigms. And a paradigm is a way of looking at the world. A model. A way of framing things. A framework. So, I guess I’m a framework fetishist. And proud of it. Here are some musings about frameworks.
A framework fetishist is not the same as a framework fundamentalist. Some people are completely sold on a particular framework. It is more than their preferred way of looking at the world – it is their only way of looking at the world. They have difficulty in seeing things from a different perspective. They also have difficulty in other people seeing things from a different perspective and spend a lot of energy on being right. When this topic comes up, I am always reminded of something the psychotherapist Esther Perel said to one party (I am pretty sure it was the husband) in a marriage counselling session, “Do you want to listen or do you want to be right?”. Feel free to stop reading here and start improving your marriage.
Frameworks tend to overstretch their reach
Some years ago, market analyst Charlie Betz observed that, over time, frameworks tend to overstretch their reach. I recognised this immediately. Most frameworks start off by describing a specific area of work to help people understand or improve how the work is executed or managed. Then they realise that they interact with other domains of work, so they describe these domains as well, which is good because it helps you understand what happens in these adjacent domains and gives you the vocabulary to improve your collaboration. However, some people get the impression that the domain that the framework described initially, has now expanded. This leads to confusion about what the domain actually is. It would help if frameworks were clear about the core domain and the adjacent domains.
An example is IT Service Management (ITSM). Does ITSM include IT Operations? Is ITSM part of Infrastructure and Operations (I&O)? Another example is DevOps. Does DevOps refer to where Application Development and IT Operations intersect? Does DevOps encompass Application Development and IT Operations? You tell me.
Frameworks are a terrible place to stop your thinking
The legendary Taiichi Ohno, the father of the Toyota Production System (regarded as the precursor of the Lean movement) said many profound things. Including, “You have to face your difficulties and think for yourself. Stop trying to borrow wisdom.”
He insisted that managers observe what actually happens on the shop floor rather than base their decisions on what they think happens. He trained people by drawing a chalk circle on the part of the Toyota factory floor that was a good viewing point for the production process. He instructed the manager to stand in the circle and take notes. After an hour or so, he returned and asked what they had seen. “Look again” was his response, after which he departed for another hour. You get the picture. The lesson is that you have to work hard at it.
Some people adopt frameworks as a shortcut, absolving them of having to put in the hours. ITSM industry legend Ivor MacFarlane once said, “Frameworks are a great place to start your thinking. And a terrible place to stop.” Wise words that reflect the ‘adopt and adapt’ recommendation that accompanies most frameworks. No pain no gain. It’s your choice.