अगर आप सीनियर हैं, तो कम-से-कम एक ग्राफ की ज़िम्मेदारी लें

• सीनियर इंजीनियर·PM·डिज़ाइनर होने पर आपके पास कम-से-कम एक मुख्य मेट्रिक ग्राफ होना चाहिए जिसकी ज़िम्मेदारी आप लें; यह अच्छा काम करने के सबसे तेज़ तरीकों में से एक है
• सीनियर लेवल पर संभाले जाने वाले महत्वपूर्ण समस्याओं को ज़्यादातर ग्राफ के रूप में व्यक्त किया जा सकता है; जैसे page count, performance, cost, revenue, churn rate जैसी चीज़ों में समय के साथ होने वाले बदलाव को सीधे अपनी ज़िम्मेदारी में लेना ज़रूरी है
• ग्राफ, “15% कम किया” जैसे वाक्य की तुलना में scale·trend·volatility·timing को एक साथ दिखाता है, और impact समझाने तथा सत्यापित की जा सकने वाली भरोसेमंदी पाने का सबसे ताकतवर communication tool है
• लक्ष्य तय करने और उसकी समीक्षा में ग्राफ को जोड़ने वाला loop performance tracking और feedback को बेहद सरल बना देता है, और उच्च प्रदर्शन व बेरोज़गारी के बीच फ़र्क कर देने वाले स्तर का अंतर पैदा कर सकता है
• अच्छा ग्राफ वही है जो कुछ गिने-चुने महत्वपूर्ण ग्राफ़ों में से हो जिन्हें दूसरे लोग बार-बार संदर्भित करें; quality, support, revenue, retention आदि में किसी एक ग्राफ को अंत तक own करना और उसके आधार पर चीज़ों को आगे बढ़ाना सीनियर की मुख्य भूमिका है

---

महत्वपूर्ण समस्याओं को संभालना

• सीनियर चरण में “बड़ी और महत्वपूर्ण समस्याओं” की ज़िम्मेदारी लेना अनिवार्य है, और ऐसी समस्याओं को ज़्यादातर समय के साथ बदलाव दिखाने वाले ग्राफ से व्यक्त किया जा सकता है
  • उदाहरण: page count में कमी, performance improvement, cost reduction, revenue growth, churn rate में कमी
  • कम-से-कम तिमाही स्तर या उससे अधिक अवधि में आपके काम का परिणाम दिखाई देने वाली curve के रूप में सामने आना चाहिए
• यह ज़रूरी नहीं कि हर काम सीधे ग्राफ से जुड़ा हो, लेकिन अगर आप एक भी ग्राफ की ज़िम्मेदारी नहीं ले रहे हैं, तो सीनियर के रूप में आप अपनी भूमिका ठीक से नहीं निभा रहे

impact को स्पष्ट रूप से बताना

• सीनियर लोगों की आम समस्या यह होती है कि उन्हें लगता है उनके काम को समझा नहीं जा रहा, और इसे अधिकतर मामलों में communication failure मानना चाहिए
  • अगर आप सिर्फ “page 15% कम किया” जैसा वाक्य भेजते हैं, तो शुरुआती बिंदु·अवधि·trend·यह संयोग था या नहीं जैसे कई अतिरिक्त सवाल तुरंत उठते हैं
• ग्राफ इन सवालों के लिए scale, पुरानी history, volatility, बदलाव का timing एक नज़र में दिखा देता है
  • साथ ही data source link भी दिया जा सकता है, जिससे सामने वाला ग्राफ की सच्चाई को खुद verify कर सकता है
• अगर impact को केवल धुंधले text में व्यक्त किया जाए, तो “जो काम अभी हो रहा है वह सही है या नहीं, और निवेश के मुकाबले उसका असर पर्याप्त है या नहीं” जैसे तीखे feedback मिलना मुश्किल हो जाता है
  • इसके उलट, ग्राफ के रूप में दिखाने पर श्रेय भी मिलता है और दिशा·priority पर स्पष्ट feedback भी मिलता है
• ग्राफ काम की value और समय के मुकाबले उसके असर को स्पष्ट रूप से दिखाने का माध्यम है

सब कुछ एक साथ जोड़ना

• पिछली पोस्ट On Achieving Goals में बताया गया था कि काम पूरा करने की प्रक्रिया को “goal setting → review” जैसे एक सरल loop में समेटा जा सकता है
  • अच्छे goal तय करना, स्पष्ट owner रखना, और नियमित check-in के ज़रिए status और ज़रूरी adjustments देखना ही goal हासिल करने का सार है
  • goals के असफल होने के ज़्यादातर कारण बेकार goals·priority की गलती·owner का अभाव जैसी खराब goal-setting, और check-in की कमी·गलत check-in संचालन जैसे बुनियादी process के टूटने से आते हैं
  • सटीक goals और लगातार review संगठन के लिए असली बदलाव लाने वाली बुनियादी infrastructure हैं; इनके बिना कोई भी goal लगातार हासिल नहीं किया जा सकता
• यह लेख इसमें एक अतिरिक्त नियम जोड़ता है: ग्राफ को इसमें शामिल करें
  • यानी goal तय करें, और उस goal को दिखाने वाले एकल ग्राफ को नियमित रूप से देखने वाला loop चलाएँ
• यह संयोजन उच्च प्रदर्शन करने वालों और नौकरी खो देने वालों के बीच फ़र्क कर देने जितना शक्तिशाली tool हो सकता है

सार

• ग्राफ सीनियर लोगों के लिए प्रगति को track करने, परिणाम दिखाने और feedback पाने की मुख्य इकाई है
  • एक ग्राफ की ज़िम्मेदारी लेकर उसे आगे बढ़ाना ownership की वास्तविक इकाई है
• अगर इस समय आपके पास ऐसा कोई ग्राफ नहीं है जिसकी ज़िम्मेदारी आप लेते हों, तो तुरंत एक ढूँढिए और उसका ownership लीजिए

Appendix: ग्राफ ownership Tip & Trick

• अगर आपके पास ऐसा ग्राफ है जिसे दूसरे लोग बार-बार quote करते हैं, तो आप सही दिशा में जा रहे हैं
  • लोग आमतौर पर आलसी होते हैं, इसलिए अगर कोई उपयोगी और सटीक ग्राफ मौजूद हो तो वे उसे दोबारा बनाने के बजाय उसी को लेकर इस्तेमाल करना पसंद करते हैं
  • ऐसे ग्राफ स्वाभाविक रूप से आपके career के लिए भी plus साबित होते हैं
• ग्राफ को शुरुआत से परफेक्ट होना ज़रूरी नहीं; feedback के आधार पर उसे धीरे-धीरे बेहतर बनाना ही असली ownership है
• जिस anti-pattern से बचना चाहिए, वह है “बहुत ज़्यादा ग्राफ own करना”
  • कुछ लोग सिर्फ अपने narrative के अनुकूल समय पर इस्तेमाल करने के लिए ढेर सारे ग्राफ इकट्ठा करके “ownership” का दावा करते हैं,
  • लेकिन अच्छी स्थिति यह है कि बहुत कम, सचमुच महत्वपूर्ण ग्राफ़ों की गहरी ज़िम्मेदारी ली जाए
  • जैसा कि “You have too many metrics” में कहा गया है, metrics और graphs कम होने चाहिए, लेकिन बेहद उपयोगी
• इंजीनियर अगर ग्राफ ढूँढना चाहें, तो quality issues एक अच्छा शुरुआती बिंदु हैं
  • page count, incidents, bugs, performance जैसी चीज़ें ग्राफ में बदलने के लिए अच्छी हैं, और ऐसे क्षेत्र हैं जिनकी ज़िम्मेदारी लेने के लिए कोई चाहिए
• PM और डिज़ाइनर के नज़रिए से support tickets, revenue, competitive win rate, retention को प्रभावित करने वाले ancillary products का attach rate अच्छे उम्मीदवार हैं
• यह ज़रूरी नहीं कि आप अकेले अपने दम पर ही उस metric को हिला सकें,
  • किसी महत्वपूर्ण metric को लगातार monitor करना और लोगों को लगातार उस दिशा में align करने के लिए प्रेरित करना भी आपके career को बहुत आगे ले जा सकता है

[t7vonn]

मेरा वज़न ग्राफ़ ऊपर की ओर जा रहा है।

[wedding]

मेरी सैलरी की बढ़ोतरी का ग्राफ पिछले 5 सालों से 0% पर है।

[husky81]

इसे सामान्य बनाकर कहना आसान नहीं होगा, लेकिन फिलहाल मैनेजमेंट को मनाने के लिए यह सबसे अच्छा टूल है, यह तो निश्चित है।

[roxie]

मैं आम तौर पर सोचता था कि performance को percentage में दिखाना बेकार है, और लगता है यह लेख मेरी उस सोच को पूरा करता है.

"बिक्री में 5 प्रतिशत वृद्धि में योगदान" कहने के बजाय, मुझे लगता है यह बताना चाहिए कि किस अवधि में कितना बढ़ाया, और अपने योगदान से पहले की तुलना में वह कितनी अधिक steep हुई.

[barrelhouse]

मुझे लगता था कि उपलब्धियों या लक्ष्यों को संख्याओं में व्यक्त करने की क्षमता महत्वपूर्ण है, लेकिन इस लेख में कहा गया है कि उन्हें ग्राफ़ तक में भी दिखाना चाहिए। सामने वाले की समझ और भरोसे के नज़रिए से यह बात काफ़ी समझ में आती है।

[geesecross]

तो शायद उस ग्राफ़ के दूषित होने की संभावना काफ़ी ज़्यादा होगी।

Goodhart का नियम: "जिस क्षण कोई मापदंड लक्ष्य बन जाता है, वह मापदंड फिर अच्छा मापदंड नहीं रहता"

[findnamo]

Goodhart के नियम का खंडन करने वाले एक उद्धरण के रूप में
मैंने Peter Drucker से जोड़ा जाने वाला यह कथन याद किया: "अगर आप इसे माप नहीं सकते, तो आप इसे प्रबंधित नहीं कर सकते (If you Can't measure it, you Can't manage it)"।
और खोजने पर पता चला कि Drucker Institute भी कहता है कि Drucker ने ऐसा कभी नहीं कहा।

बल्कि मुझे इसका उल्टा कथन मिला।
यह मान लेना गलत है कि अगर आप किसी चीज़ को माप नहीं सकते, तो आप उसे प्रबंधित नहीं कर सकते। — यह एक महंगा मिथक है। (It is wrong to suppose that if you can't measure it, you cant manage it-a costly myth) - Edward Deming

[dongho42]

फिर भी, मुझे लगता है कि कुछ सार्थक measurement criteria ज़रूर होंगे। खासकर, अगर कोई ऐसा व्यक्ति हो जो एक-दूसरे के विपरीत जाने वाले दो metrics, दोनों की जिम्मेदारी ले, तो यह और भी प्रभावी होगा। SRE के नज़रिए से incident count कम हुआ कहकर खुश हुआ जा सकता है, लेकिन उतना ही ज़्यादा सतर्कता बरतने के कारण deployment देर से हो सकता है और feature development धीमा पड़ सकता है। वहीं Dev के नज़रिए से feature development ज़्यादा हुआ कहकर खुश हुआ जा सकता है, लेकिन उसी अनुपात में incidents की संख्या भी बढ़ सकती है।

मुझे लगता है कि p99 latency, response success rate, request per cost, MTTR, incident count जैसे metrics भी ऐसे अच्छे संकेतक हैं जिनका abuse करना आसान नहीं है। (बिलकुल, इनका abuse हो सकता है, लेकिन इन्हें track और manage करने से नुकसान की तुलना में फ़ायदा ज़्यादा होगा...)