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

 (staysaasy.com)
61 पॉइंट द्वारा GN⁺ 2025-12-11 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें
  • सीनियर इंजीनियर·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 को बहुत आगे ले जा सकता है

संबंधित पढ़ाई

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.