कोई भी कभी उन समस्याओं को ठीक करने का श्रेय नहीं पाता जो कभी हुई ही नहीं (2001) [pdf]
क्षमता-जाल और गैर-एकरूप सुधार
- कई टिप्पणीकार लेख के “क्षमता-जाल” को सॉफ़्टवेयर और AI से जोड़ते हैं: अस्थायी रूप से बदतर हुए बिना आप सुधार नहीं कर सकते (रिफ़ैक्टरिंग, प्रशिक्षण आदि के दौरान थ्रूपुट कम होना)।
- प्रबंधक अक्सर सुधार को एकरूप और बिना लागत वाला मान लेते हैं, इसलिए अल्पकालिक प्रदर्शन में कोई भी गिरावट दंडित की जाती है, जिससे यह जाल और मज़बूत होता है।
- “जाल” को इस तरह परिभाषित किया जाता है: इसमें प्रवेश करना आसान है (दबाव में कामचलाऊ उपाय करना), लेकिन बाहर निकलना कठिन है (क्षमता में निवेश करने के लिए कोई अतिरिक्त समय/संसाधन नहीं बचता)।
Y2K, तैयारियों का विरोधाभास, और प्रायिकता
- Y2K एक केंद्रीय उदाहरण है: बहुत से लोग तर्क देते हैं कि “कुछ नहीं हुआ” वाला परिणाम ठीक इसलिए आया क्योंकि पुरानी COBOL प्रणालियों, उपयोगिताओं, बैंकिंग आदि में सुधार के लिए भारी प्रयास किए गए।
- अन्य लोग नोट करते हैं कि कुछ देशों ने बहुत कम किया और वे ठीक दिखे, जिसके लिए आयातित सॉफ़्टवेयर, नई प्रणालियाँ, या छोटे स्थानीय मुद्दों के बाहर से अदृश्य रहने जैसी परिकल्पनाएँ दी जाती हैं।
- चर्चा “तैयारियों के विरोधाभास” को छूती है: सफलता रोकथाम को अति-प्रतिक्रिया जैसा दिखाती है, और लोग जोखिम को द्विआधारी ढंग से देखते हैं तथा प्रायिकताओं को गलत समझते हैं।
संगठनात्मक प्रोत्साहन: संकट-निपटान बनाम रोकथाम
- एक मजबूत विषय यह है कि संगठन दृश्य नायकत्व को पुरस्कृत करते हैं (देर रात की आउटेज, संकट से बचाव) बजाय शांत रोकथाम के।
- “संघर्षरत” या अव्यवस्थित विभाग अक्सर स्थिर, अच्छी तरह चलने वाले विभागों से अधिक बजट और प्रशंसा पाते हैं—कभी-कभी उन समस्याओं को ठीक करने के लिए जिन्हें उन्होंने स्वयं पैदा किया था।
- स्टैक रैंकिंग या “सिर्फ अपेक्षाओं से अधिक” वाली संस्कृतियों में सक्रिय काम को ट्रैक और रिपोर्ट करने के प्रयास कभी-कभी विफल हो जाते हैं; इससे समस्याओं को तब तक न सुधारने की प्रेरणा मिल सकती है जब तक वे फट न पड़ें।
- कुछ लोग सुझाव देते हैं कि “निकट-चूक” और दर्द को चुपचाप सहने के बजाय नेतृत्व के सामने रखा जाए, ताकि प्रणाली सीख सके, लेकिन कम-फंडिंग या दोषारोपण-प्रधान संगठनों में यह उलटा पड़ सकता है।
सरलता, सुरुचि, और जटिलता को पुरस्कृत करना
- कई लोग नोट करते हैं कि सुरुचिपूर्ण, सरल समाधान पीछे मुड़कर देखने पर स्पष्ट लगते हैं और उन जटिल प्रणालियों की तुलना में कम आँके जाते हैं जो “कठिन” दिखती हैं।
- पदोन्नति, प्रकाशन, और प्रशंसा अक्सर महसूस की गई जटिलता के साथ आती है, जिससे अतिरूपण (ओवर-इंजीनियरिंग) और नौकरशाही को बढ़ावा मिलता है।
- AI उपकरण कोड और समाधान की जटिलता को तेज़ी से बढ़ा सकते हैं, जिससे इंजीनियरों में रक्षात्मक संदेह अधिक सामान्य हो रहा है।
प्रबंधन, तकनीकी अंतर्दृष्टि, और प्रणालीगत पक्षपात
- तकनीकी कर्मचारियों और गैर-तकनीकी प्रबंधन के बीच लगातार तनाव है: रोकथाम का काम उन लोगों को दिखाई नहीं देता जो प्रणाली से दूर हैं, और वे “कुछ टूटा नहीं” को “कुछ किया ही नहीं” समझ सकते हैं।
- कुछ का तर्क है कि तकनीकी पृष्ठभूमि प्रबंधन को रोकथाम कार्य को समझने और महत्व देने में मदद करती है; अन्य लोग कहते हैं कि अच्छा प्रबंधन एक अलग कौशल है और इंजीनियर भी खराब प्रबंधक हो सकते हैं।
- कई लोगों के अनुसार यह मुद्दा मूलतः मानव और प्रणालीगत है—दिखावा, कम ध्यान-सीमा, और संज्ञानात्मक पक्षपात—न कि केवल टेक का।
समाज और व्यक्तिगत सामना करने की रणनीतियों में रोकथाम
- स्वास्थ्य-सेवा, सुरक्षा अभियांत्रिकी, अवसंरचना, और Covid नीति से समानताएँ खींची जाती हैं: रोकथाम को शायद ही कभी महिमा मिलती है, और बाद में अति-प्रतिक्रिया बनाम विवेकपूर्ण तैयारी में अंतर करना कठिन होता है।
- टिप्पणीकार व्यक्तिगत अनुकूलन का वर्णन करते हैं: हीरो खेल खेलने से इनकार करना, प्रोत्साहनों के साथ रणनीतिक रूप से खेलना, या ऐसे भूमिकाओं/उद्योगों में जाना जहाँ रोकथाम और “उबाऊ विश्वसनीयता” को बेहतर पुरस्कृत किया जाता है।