ITIL, DEVOPS, Agile, etc implementations sometimes forget about Performance System Engineering

I caught up with a friend who had worked with at Sun and Oracle years ago. He is now at a start-up in the Middle-East after years with Google. A lot of the discussion was about Kepner-Tregoe process (I train him in about 2008 in the KT ways of defense against the dark arts), process he still uses and can not find better. We had a chat about KT Incident Mapping and Performance System Engineering, 2 things I would not have covered in 2008 on the Analytical Troubleshooting course as it was called then. I do spend a fair bit of my KT time training and coaching both now.

The discussion ranged through importance of emotional intelligence(EQ) in solving problems and making decisions, particularly on concerns that need collaboration. It did make me reflect that KT process respects and seeks to enhance technical ability when understanding situations, solving problems, making decisions and managing risk. You can't answer a "when in the lifecycle" question unless there is an deep understanding of the system in question and that has to come from technical experts(IT, chemical, electrical, people behavior, ....). A symbiosis of technical knowledge and KT clear thinking process. KT process understands that much of useful knowledge is tacit and needs to be coaxed out of the brain(s) of the expert(s).

I am an unusual hybrid. Part Operating System kernel and performance engineer, part academic and part KT programme leader. I love debugging "stuff"; technical problems, people, situations, fixing them and stopping the undesirable elements happening again and enhancing the positive. KT brings the HOW, in an I.T. industry awash with WHAT that comes from frameworks such as ITIL, Agile, DEVOPS, etc.

Taking ITIL has an example, when implemented well it provides a excellent structure to align the delivery of services with the needs of the actual customer. Incidents are well managed and there is clear visibility of problems at all levels.

When an ITIL implementation is a mess a common feature is that technical skill is relegated to become subordinate and a commodity that can be easily replaced. Little or no value is placed on the highly valuable tacit knowledge built from years of being curious about complex systems and pondering about "it should not do that, I wonder why?". Its not an ITIL specific weakness as such, but an other layer of HOW which considers engineers and how they work and think that has been left in the weeds.

Our friend here points out a similar set of concerns about Agile implementations that use SCRUM. Its well worth a watchand it aligns with about 50% of my personal observations of Agile projects. The common theme where Agile with Scrum goes astray is that consequences from the perspective of the the developers is not considered or not considered important.

If you are an techie/engineer, then sitting in a meeting that is not focused on addressing a particular problem (think any regular meeting) is Dante's 10th circle of hell. If a meeting has an agenda that is larger than an object-defect statement of the form "why is are widgets late", then from your perspective as a developer you could be usefully coding, debugging or whatever you drug of choice is. Attending a meeting run by a grown up is a negative consequence. Having a water-cooler(even on zoom) technical discussion with co-workers can be useful and almost fun.

Which brings us to KT Performance System Engineering and EQ. I lifted the png from the video which does a good job of providing an overview of Performance System Engineering https://vimeo.com/301275911.

When I learned the KT process I had just started working for Sun in 1997. A lot of attention was paid to the Performance System. That the Performance Systems of field engineers, software engineers (front and backline) managers, call handlers, solution center manager were all aligned with no white space and minimal adverse negative consequences for the desired response (solve the case). Technical skill was very highly prized and nurtured. KT was the common communication medium. The relationship was efficient and symbiotic.

I don't sell STUFF [delighted to put you in touch with KT people who do, but only if you agree]. If you would like to start exploring how your Performance System could do with some Engineering or even just reflect on what you have done with your red KT process card since the late 90's, then please get in touch for a chat.

I also speak Cybersecurity, AI, Major incident Management and debugging hard problems in pretty much any context.

I was lucky enough to do my PhD with Prof Ian Pyle who founded the Computer Science Department at York, worked at Harwell and at Aberysytwth Comp sci. He is now in his 80's, sharp as always and we meet for lunch last year. He coined the term artificial stupidity which he sees as trying to apply A.I. in situations that don't fit or have unacceptable risks. Next up is a article on using KT clear thinking process to reduce the effect of Artifical Stupidity. I am pragamtic, we can't eliminate any type of stupidity completely.