यह एक वास्तविक तनाव है, कोई पहेली वाला सवाल नहीं। Productive struggle ही वह तरीका है जिससे engineers टिकाऊ skill बनाते हैं, लेकिन संघर्ष केवल एक बिंदु तक productive होता है, और deadlines वास्तविक हैं। जवाब एक पक्ष चुनना नहीं है; यह stakes और व्यक्ति को पढ़ना है, फिर जानबूझकर चुनना है।
मेरा default playbook
- संघर्ष को time-box करें। Productive struggle की एक shelf life होती है। पहले से सहमत हों: "इस पर एक घंटा बिताएं, फिर मुझे ping करें।" यह सीखने और schedule दोनों की रक्षा करता है।
- जवाबों से पहले सवाल और संकेत दें। "stack trace किस ओर इशारा करता है?" या "क्या आपने config जांचा है?" approach सिखाता है, जो अगली समस्या में transfer होता है। fix सौंपना कुछ नहीं सिखाता।
- वास्तविक deadline दबाव में, अभी unblock करें, बाद में सिखाएं। जब ship date जोखिम में हो, तो बस जवाब दे दें, फिर अगले दिन वापस आकर समझाएं कि क्यों यह काम कर गया। एक teachable moment की वेदी पर एक release की बलि न दें।
- इसे व्यक्ति के level से मिलाएं। एक junior को संकेत जल्दी चाहिए हो सकता है; एक senior को आप अधिक देर बैठने दे सकते हैं।
एक सरल decision lens
| Stakes | सही कदम |
|---|---|
| Low / learning task, समय उपलब्ध | उन्हें संघर्ष करने दें, केवल संकेत |
| High / critical path पर, घड़ी चल रही है | अभी unblock करें, बाद में debrief |
| एक ही चीज़ पर बार-बार अटका हुआ | रुकें, अंतर्निहित concept को सीधे सिखाएं |
एक ठोस उदाहरण
एक mid-level engineer launch से एक रात पहले एक flaky test पर अटका हुआ है। मैं रात 9 बजे Socratic seminar नहीं चलाता; मैं pair करता हूं, हम इसे ठीक करते हैं, हम ship करते हैं। अगली सुबह हम बीस मिनट इस पर बिताते हैं कि इसे flaky किसने बनाया ताकि सबक फिर भी सीखा जाए।
यह क्यों महत्वपूर्ण है
हमेशा जवाब देना निर्भरता और ऐसे engineers बनाता है जो कभी नहीं बढ़ते। हमेशा उन्हें रोके रखना समय, मनोबल, और deadlines जलाता है। अच्छी mentoring दोनों के बीच के निर्णय में बसती है, एक नियम के रूप में नहीं बल्कि case by case लागू की जाती है।