जब R&D से "R" गायब हो जाता है (2021)
Software और R&D भूमिकाओं में काम करने वाले लोग बताते हैं कि “work-to-rule” व्यवहार — यानी जो स्पष्ट रूप से कहा गया है, बस वही करना और उससे अधिक नहीं — अक्सर तब उभरता है जब management पहल को दंडित करता है, “glue work” की अनदेखी करता है, या performance reviews को संकीर्ण, मापनीय metrics के इर्द-गिर्द optimize करता है। Commenters का तर्क है कि इससे वास्तविक research, experimentation, और cross-functional collaboration कमजोर पड़ते हैं, जिससे खराब UX, brittle internal tools, और प्रतिक्रियात्मक corporate overhauls होते हैं, जो design, engineering, और product thinking को और अलग कर देते हैं। कई लोगों को बड़े संगठनों में एक व्यापक पैटर्न दिखता है: जैसे-जैसे bureaucracy और hierarchy बढ़ती है, genuine innovation, संचित know-how, और enabling roles अदृश्य हो जाते हैं और सबसे पहले काट दिए जाते हैं, जिससे दीर्घकालिक क्षमता कमजोर पड़ती है, भले ही हर अलग निर्णय तर्कसंगत लगे।
वर्क-टू-रूल, “इटैलियन स्ट्राइक”, और malicious compliance
- कई टिप्पणियाँ “जो पूछा गया है, बस वही करना, उससे ज़्यादा नहीं” को work-to-rule / Italian strike / “malicious compliance” से जोड़ती हैं।
- इसे खराब नियमों या “glue work” के लिए मनमानी सज़ा को उजागर करने के औज़ार के रूप में देखा जाता है, सिर्फ़ आलस के रूप में नहीं।
- पूर्ण हड़ताल से अंतर: हड़तालें वेतन, लाभ जैसे बड़े मुद्दों के लिए नाटकीय, दिखाई देने वाला दबाव होती हैं; work-to-rule अधिक सूक्ष्म होता है और विशिष्ट खराब नीतियों या enforcement को ठीक करने के लिए बेहतर है।
- एक जोखिम भी बताया गया: अगर इसे व्यापक रूप से किया जाए, तो यह बदलाव लाने के बजाय चुपचाप किसी संगठन को खत्म कर सकता है।
प्रोत्साहन, glue work, और performance reviews
- कई किस्सों में इंजीनियरों का दूसरों की मदद/समन्वय से हटकर सिर्फ़ ticket-chasing में लग जाना दिखाया गया, जब performance metrics ने glue work को नज़रअंदाज़ किया।
- Performance rubrics और “company values” अक्सर लोगों को दिखने वाले, मापनीय outputs (tickets, lines of code, overtime) की ओर धकेलते हैं और collaboration या दीर्घकालिक सुधार से दूर करते हैं।
- कुछ लोग सलाह देते हैं: “विनाशकारी नियमों का बिल्कुल पालन करो” ताकि management को उन्हें नोटिस करने और बदलने के लिए मजबूर किया जा सके।
R&D में Research का क्या अर्थ है
- कई “R&D” भूमिकाएँ असल में ज़्यादातर development या “discovery” होती हैं (यह पता लगाना कि stakeholders क्या चाहते हैं), न कि वास्तविक research।
- वास्तविक research को खुली-समाप्ति वाली, स्व-निर्देशित problem exploration के रूप में बताया गया है (जैसे moonshot teams, data science), जिसे backlog/scrum approaches ठीक से नहीं संभालतीं।
- कुछ लोग research और तेज़ prototyping के बीच संतुलन बनाने में संघर्ष करते हैं, “research hell” बनाम कम-शोधित समाधानों से डरते हैं।
UX, design, और management के फैसले
- एक पक्ष R&D टीम को खराब, user-hostile UX के लिए दोष देता है, जिसने management की overreaction को भड़काया।
- दूसरे लोग तर्क देते हैं कि असली समस्या design expertise की कमी थी; प्रशिक्षित किए बिना engineers से UX करवाना अवास्तविक है।
- UX को एक दूरस्थ silo में ले जाने की आलोचना भी की जाती है, बजाय इसके कि design skills को टीम के भीतर embedded किया जाए।
Research काटना, metrics, और अदृश्य काम
- संगठनों के “R” को कम करने के विवरण हैं (chemists, physicists, long-horizon projects) और roadmap-driven “D” पर ध्यान केंद्रित करने के।
- “कोई output नहीं” वाले लोगों को निकालना जोखिमभरा माना जाता है: metrics अक्सर संचित know-how और enabling roles को नहीं पकड़ते, जो दूसरों की productivity खोलते हैं।
- internal R के नुकसान से बाद में external innovation का मूल्यांकन या उसे integrate करना और कठिन हो जाता है।
Bureaucracy, org design, और regression to the mean
- जैसे-जैसे कंपनियाँ बढ़ती हैं, bureaucracy, hierarchies, KPIs, और turf wars बढ़ते हैं जबकि वास्तविक productive work घटता है।
- एक व्याख्या दी गई: शुरुआती survivors असाधारण होते हैं; तेज़ scaling औसत talent को hiring करने पर मजबूर करती है, जो बदले में और अधिक process को जन्म देती है।
- कुछ लोग प्रतिस्पर्धी semi-autonomous groups या “micro-organizations” को एक आंशिक antidote के रूप में सुझाते हैं।