अगर आप remote work करते हैं, तो एक Ramblings चैनल बनाइए

• Ramblings(बातें-बातें): Remote टीमों के लिए पर्सनल जर्नल चैनल

• Remote work टीमों (2~10 लोग) में हर टीम सदस्य के नाम से टीम chat app में अलग Ramblings चैनल बनाने की सिफारिश की जाती है
• Ramblings चैनल टीम के भीतर पर्सनल जर्नल या microblog की तरह काम करता है और टीम chat room को बिखेरे बिना स्वाभाविक संवाद को बढ़ावा देता है
• इसे आज़ादी से विचार, आइडिया, रोज़मर्रा की बातें, feedback, यात्रा की फ़ोटो आदि पोस्ट करने की जगह के रूप में इस्तेमाल किया जाता है, ताकि स्वाभाविक रूप से टीम सदस्यों के बीच सामाजिक जुड़ाव बढ़े

• चैनल चलाने का तरीका

  • हर Ramblings चैनल में सिर्फ़ उसका मालिक ही top-level post लिख सकता है, और सहकर्मी thread (comments) में ही जवाब दे सकते हैं
  • सभी Ramblings चैनलों को चैनल सूची के नीचे Ramblings सेक्शन में इकट्ठा रखा जाता है, और इन्हें डिफ़ॉल्ट रूप से mute (notifications off) रखा जाता है
  • दूसरे टीम सदस्यों के लिए सब कुछ पढ़ना ज़रूरी नहीं है; यह बस एक ऐसी जगह है जहाँ वे स्वाभाविक रूप से एक-दूसरे के विचारों की झलक पा सकते हैं

• संचालन टिप्स: आमतौर पर हफ़्ते में 1~3 बार छोटे अपडेट आज़ादी से लिखें

  • मौजूदा प्रोजेक्ट से जुड़े आइडिया
  • blog post, लेख, user feedback पर विचार
  • "क्या हो अगर" तरह के नए प्रस्ताव
  • हाल की यात्रा की फ़ोटो या hobbies साझा करना
  • समस्या सुलझाने की प्रक्रिया के दौरान rubber duck debugging जैसी आत्म-वार्ता का रिकॉर्ड

• वास्तविक संचालन अनुभव और प्रभाव

  • Obsidian टीम ने 2 साल तक इसका प्रयोग किया, और नियमित मीटिंग्स के बिना भी ‘watercooler talk (ऑफ़िस की अनौपचारिक बातचीत)’ की भूमिका में यह सफल रहा
  • यह गहरे focus time को सुरक्षित रखते हुए भी सहकर्मियों के बीच जुड़ाव और creative idea exchange को स्वाभाविक रूप से बढ़ाता है
  • Ramblings के ज़रिए वास्तव में feature ideas, prototypes, problem-solving approaches जैसे कई रचनात्मक नतीजे सामने आए
  • साल में एक बार होने वाली टीम offline meeting के अलावा, Ramblings चैनल टीम के मानवीय जुड़ाव की कड़ी की तरह काम करता है और टीम सदस्यों के बीच बंधन मज़बूत करने में मदद करता है

[GN⁺]

Hacker News राय

• 2014 में Cloudflare में DDoS response का काम करते समय, James(Jog) नाम के एक सहकर्मी के साथ बहुत सारे सवाल-जवाब करते हुए सहयोग का अनुभव बना। "सर्वर में login कैसे करें", "anycast क्या है", "इसका जवाब आपने कैसे दिया, ज़रा विस्तार से बताइए" जैसे सवाल बार-बार आते रहे, तो लगा कि ये बातचीत नए कर्मचारियों के लिए भी उपयोगी हो सकती है। onboarding से जुड़ी चिंताएँ, कम-ज्ञात workflow, सैद्धांतिक concepts जैसे कई विषय थे। इसलिए ऐसे सवालों को कंपनी के अंदर एक public channel में इकट्ठा करना शुरू किया, और शुरुआत में उसका नाम “Marek's Bitching” रखा गया, ताकि लोग अपना नाम दिखाकर शिकायतें या झुंझलाहट वाले सवाल पूछ सकें। धीरे-धीरे और सहकर्मी जुड़ने लगे, और कंपनी के भीतर ऐसे technical topics, खुली चर्चाएँ, छोटी शंकाएँ, और अटकलें तक (जैसे Intel firmware bug की जाँच) स्वाभाविक रूप से वहाँ जमा होने लगीं, जिन्हें दूसरे channels में उठाना मुश्किल था। इससे काफ़ी मूल्य बना। बाद में नाम बदलकर “Marek's technical corner” कर दिया गया, और 10 साल से ज़्यादा समय से यह technical culture का केंद्र बना हुआ है। लेखक इस बात पर ज़ोर देता है कि इस तरह खुलकर शिकायत, सवाल और चर्चा करने के लिए “मेरा चैनल” या टीम/ऑफिस-वार "rambling/bitching" channels का होना संगठन के भीतर संचार और विकास के लिए खास तौर पर मददगार है

  • मैं वही James(Jog) हूँ। उस समय बहुत मज़ेदार बातचीत होती थी, इसलिए अच्छा लगता था। बाद में कंपनी में internal blog culture भी बना, जिससे सब लोग अपने experiments या discoveries स्वाभाविक रूप से साझा करने लगे, और यह बहुत उपयोगी रहा। internal blogs subscribe करने पर सच में बहुत कुछ सीखने को मिलता था
  • मैं लेखक की बात समझता हूँ, लेकिन manager के नज़रिए से देखें तो किसी खास व्यक्ति को केंद्र में रखकर बना Q&A format searchability, discoverability, और नए कर्मचारियों के लिए इस बात का भ्रम पैदा करता है कि वही व्यक्ति project का केंद्र है। सवाल पूछने की जगह तो ज़रूर होनी चाहिए, लेकिन चर्चा को व्यक्ति-आधारित नहीं, topic-based channels की ओर ले जाना ज़्यादा प्रभावी है। जब भी कोई random channel (जैसे #random, #general) में technical सवाल पूछता है, मैं हमेशा उसे project-specific channel की ओर भेजता हूँ। सबके लिए प्रासंगिक बातचीत और जानकारी सही channel में इकट्ठा हो, यह आदत ज़रूरी है
  • हमारे संगठन में स्वाभाविक रूप से "Study Hall" नाम का एक channel बना, जहाँ technical सवाल खुलकर पूछे जा सकते हैं और आलोचना नहीं होती, इसलिए टीम में यह बहुत उत्पादक साबित हुआ है। अनुभव के आधार पर कह सकता हूँ कि यह सबसे असरदार chat channels में से एक है
  • पोस्ट में जिसका ज़िक्र है, वह “Marek's technical corner” आज भी मौजूद है, और अब भी थोड़ी-बहुत गतिविधि जारी है
  • वैसे, “Marek's technical corner” आज भी ज़िंदा है और कभी-कभी काफ़ी सक्रिय भी रहता है

• पोस्ट पढ़ने के बाद मैं remote work environment में स्वैच्छिक “rambling” के महत्व की भी सिफारिश करना चाहता हूँ। हर सुबह लगभग एक घंटा टहलते हुए अपने लिए समय निकालना बहुत मूल्यवान है, क्योंकि इससे commute और घर के बीच एक सीमा बनती है, routine exercise हो जाती है, और चलते समय कई विचार भी आते हैं

  • मुझे लगता है कि बच्चे को स्कूल छोड़ने का समय भी लगभग वही भूमिका निभाता है। जब संभव हो, मैं अपनी बेटी के साथ कुत्ते को घुमाते हुए बस स्टॉप तक जाता हूँ, और पहले daycare तक आना-जाना करते हुए 45 मिनट पैदल चलता था
  • पूरी तरह remote काम करते हुए कभी-कभी मैं खुद को कोसता हूँ कि “मैं बच्चे को लेने क्यों नहीं जाता, तबीयत खराब हो तो बस offline हो जाता हूँ, traffic jam की वजह से देर भी नहीं होती, और इधर-उधर के कारण मुझे जल्दी निकलना भी नहीं पड़ता।” ये सब वाजिब वजहें हो सकती हैं, लेकिन जब ऐसी बातें रोज़ सुनता हूँ तो मज़ेदार भी लगता है। असल में मैं अपने काम से संतुष्ट हूँ और आलसी तरीके से काम भी नहीं करना चाहता
  • मैं अपने अनुभव से साबित कर सकता हूँ कि यह तरीका सच में काम करता है। घर पर बेचैनी हो तो आसपास के पार्क में सिर्फ 30 मिनट चल लेने से भी मन बहुत बेहतर हो जाता है। कितना चलें, इससे फ़र्क नहीं पड़ता; चलने से जो आज़ादी महसूस होती है, वही बड़ी बात है
  • दिन का सबसे अच्छा समय करीब 10 बजे का होता है, जब मैं straw hat पहनकर, कपड़े उतारकर, धूप को पूरे शरीर पर महसूस करते हुए मोहल्ले में टहलता हूँ। बिना फोन के चलने की आज़ादी सच में बहुत अच्छी लगती है

• मैं भी दूसरे commenters की तरह कुछ हद तक सहमत हूँ, लेकिन “rambling” को औपचारिक रूप से assign करना मुझे उल्टा dystopian लगता है। ऐसे channels/space सबसे अच्छे तब होते हैं जब वे स्वाभाविक, अपने-आप बनते हैं; जब जो बात मन में आए, उसे सही सहकर्मी के साथ साझा किया जाए, group chat धीरे-धीरे बढ़े, और ज़रूरी बातें बाद में पूरी टीम तक पहुँचें। इस तरह की चर्चा अपने आप में स्वस्थ है और remote teams के लिए ज़रूरी भी हो सकती है, लेकिन मेरा मानना है कि हर टीम को अपने तरीके की communication culture खुद बनानी चाहिए। कृत्रिम institutionalization की ज़रूरत नहीं है

  • “इस हफ़्ते आपने 15 बार बातें उड़ेली हैं।” “लेकिन minimum तो 15 है, है ना?” “हूँ, minimum तो वही है। लेकिन Todd तो पहले ही 37 बार उंडेल चुका है।” “अगर सच में 37 चाहिए था, तो उसे minimum ही बना देते।” — इस तरह के मज़ाक से यह चतुराई से दिखाया गया कि quantitative targets रखने पर क्या दुष्परिणाम हो सकते हैं
  • अनुभव से कहना चाहूँगा कि ऐसे “sensational career advice” अक्सर भले इरादे से होते हैं, लेकिन बढ़ा-चढ़ाकर पेश किए जा सकते हैं या गलत समझे जा सकते हैं। कई बार juniors इन्हें शब्दशः लागू करने लगते हैं, और फिर सहकर्मी व managers और ज़्यादा उलझ जाते हैं। इसलिए मेरे जैसे managers Reddit जैसी जगहों पर ऐसे पोस्ट घूमते देखें तो सरसरी तौर पर पढ़ लेते हैं, ताकि अगर टीम में कोई अचानक वैसा व्यवहार शुरू करे तो उसके पीछे की पृष्ठभूमि समझकर पहले से स्थिति संभाली जा सके
  • मुझे “channel” थोड़ा ज़्यादा random लगता है। एक पुरानी कंपनी में मैंने Confluence में “Personal Space” बनाकर personal blog की तरह अपने विचार लिखे थे, और नई कंपनी में भी वही तरीका जारी है। code refactoring जैसे बड़े फ़ैसलों से पहले अगर मैं अपने विचार अंग्रेज़ी में लिखकर साफ़ कर लेता हूँ, तो केवल coding में लगे रहने से कहीं ज़्यादा स्पष्टता मिलती है। टीम के साथ अपनी योजना साझा कर सकता हूँ, feedback भी ले सकता हूँ। इसी तरह, नए algorithms या analysis methods पर सोचते समय मैं LaTeX equations support वाले blog software का उपयोग कर विचारों को औपचारिक mathematical notation में लिखता हूँ; अंग्रेज़ी में व्यवस्थित करके formula में ढालने की प्रक्रिया में गलतियाँ और गलत assumptions पहले ही पकड़ में आ जाती हैं। इस तरह किसी आधे-खुले स्थान पर लिखना गलतियाँ कम करता है और सोच को ज़्यादा structured बनाता है। अगर पूरी company में से कुछ ही लोग पढ़ें तो भी ठीक है, क्योंकि publish button दबाने से पहले सोचने के लिए भरपूर समय मिल जाता है, और “सोच के बहाव” के बजाय वास्तव में उपयोगी ideas बन पाते हैं
  • अगर ऐसी गतिविधि “बातें करने का allocation” या “performance metric” बन जाए, तो सच में सबसे बुरा होगा — इस बात से मैं सहमत हूँ। Obsidian में जो उदाहरण था, वह स्वाभाविक रूप से उभरी हुई practice थी, और छोटी टीम व flat structure होने की वजह से संभव हो सका। और पोस्ट में यह जो साफ़ कहा गया है कि “channels default रूप से muted हैं, किसी पर पढ़ने का दबाव नहीं है”, वही ज़्यादा महत्वपूर्ण बिंदु है
  • मेरा दावा है कि इस लेख में कहीं भी किसी कर्तव्य, मजबूरी या allocation की बात नहीं है। असली समस्या तो यह है कि इतनी high-value वाली informal channels लगभग कभी भी अपने-आप पैदा नहीं होतीं

• मैं इस बात से सहमत हूँ कि “rambling” channel सामान्य ऑफिस के watercooler talk जैसा है। लेकिन व्यवहारिक रूप से ज़्यादातर teams के पास पहले से ही रोज़ की नियमित meetings schedule में होती हैं, इसलिए rambling channel किसी स्वाभाविक ज़रूरत से पैदा होने के बजाय “काम के लिए करनी पड़ने वाली एक और चीज़” जैसा महसूस हो सकता है, और इसी कारण यह अक्सर अच्छी तरह काम नहीं करता

  • मैंने खुद कभी rambling channel इस्तेमाल नहीं किया, लेकिन रोज़मर्रा में “बातें” बहुत करता हूँ। बल्कि सबसे परेशान करने वाली चीज़ regular meetings हैं। daily जैसे meetings में लगभग कभी कुछ नया नहीं होता; पहले से पता बातों को दोहराने में बस समय बर्बाद होता है। जो भी रोज़मर्रा की बात हो, मैं meeting का इंतज़ार किए बिना तुरंत साझा कर देता हूँ। और informal gathering में scrum masters यह नहीं कहते कि “यह कहीं और करें”, इसलिए ideas को खुलकर बढ़ने की जगह मिलती है
  • ऐसी channels तभी अर्थपूर्ण होंगी जब टीम खुद social interaction की ज़रूरत को महसूस करे — यह टीम की maturity पर निर्भर है। नियमित meetings अपने-आप watercooler talk नहीं बन जातीं, इसलिए meetings होने पर भी स्वाभाविक सामाजिक बातचीत की कमी महसूस हो सकती है
  • हमारी पूरी तरह distributed team हफ़्ते में दो बार 15–30 मिनट की “rambling meeting” schedule करती है, जिसमें काम की बात नहीं होती। मुझे लगता है इसका असर बहुत बड़ा है। Slack में अलग rambling channel भी है, जो लगभग पूरे दिन सक्रिय रहता है
  • कोरोना के बाद remote companies में काम किया है, और मुझे लगता है कि रोज़ meetings होने पर भी rambling के लिए अलग जगह होना एक अच्छा विचार है। हम आमतौर पर meetings को जितना हो सके उतना on-topic रखने की कोशिश करते हैं
  • आजकल दिन का 30–50% हिस्सा meetings में निकल जाता है, इसलिए कोई-न-कोई हमेशा कहता रहता है, “यह अलग से बात करते हैं” या “इसे बाद में फिर discuss करेंगे”

• हमारी टीम ने भी बिना सोचे-समझे स्वाभाविक रूप से अलग “rambling” chat room बना लिया। main group chat में “ज़्यादा समझदार न लगने वाले” सवाल पूछना या शिकायत करना असहज लगता है, इसलिए managers के बिना एक दूसरी chat बनाई गई, जहाँ सच में दिल की बात कही जा सकती है — जैसे देखने में मामूली लगने वाले सवाल, भूल चुकी प्रक्रियाएँ, थोड़ा non-professional सा venting, services/tools/processes पर तुरंत की गई आलोचना वगैरह। main chat में सवाल का जवाब मिलते ही आगे की बातचीत को बिखराव समझकर रोक दिया जाता है, लेकिन इस room में कोई बीच में नहीं रोकता और हर कोई स्वतंत्र रूप से आकर बात कर सकता है — यही इसकी सबसे अच्छी बात है। मुझे लगता है कि टीम को ऐसी जगह ज़रूर चाहिए

  • मैं जानबूझकर “मूर्खतापूर्ण सवाल” बार-बार पूछता हूँ, क्योंकि हमेशा कोई-न-कोई ऐसा होता है जो हिचकिचाहट में कुछ बोल नहीं पाता, और कभी-कभी इसी से गहरी चर्चा शुरू हो जाती है

• एक संशयवादी दृष्टिकोण से, मुझे लगता है कि ऐसे channels आख़िरकार सिर्फ पढ़ने की चीज़ें बढ़ाते हैं और बस यह आभास देते हैं कि “टीम communication अच्छा कर रही है।” remote team की social bonding बनाने की कोशिश अच्छी है, लेकिन इसे मेरे लिए तनाव पैदा करने वाले ‘team communication check’ के साथ मिलाना ठीक नहीं लगता

  • लेकिन पोस्ट में साफ़ कहा गया है कि “channel को mute रखें, और भागीदारी की अपेक्षा न करें”
  • Slack में unread messages को दाँत साफ़ करते समय या tea maker के इंतज़ार में यूँ ही स्क्रॉल करना मेरा शौक है। जब काम करने का मन न हो, तो इसे “to-do” या “done/ignore” में जल्दी-जल्दी निपटाने वाली एक तरह की “कामकाजी Tinder” की तरह इस्तेमाल करता हूँ
  • क्या लोग सच में Slack में inbox zero बनाए रखते हैं? यह अपने-आप में अलग नौकरी जैसा लगता है

• कुछ leaders को यह महसूस होता है कि अगर टीम के भीतर communication उनके control से बाहर हो जाए तो वह ख़तरा है। ऐसे leaders के अधीन Slack जैसी जगहों पर यूँ ही राय उछालना “collaboration बिगाड़ने” या “ध्यान भटकाने वाले व्यक्ति” का टैग दिला सकता है। जबकि असल में लोग सिर्फ inspiration और ideas साझा कर रहे होते हैं, लेकिन company/culture के हिसाब से खुलकर बात करना जोखिम भरा हो सकता है। ऐसे leaders remote environment में और भी कमज़ोर साबित होते हैं, और यहाँ तक कि Slack DM भी खोजकर “problematic people” ढूँढ़ने की कोशिश करते हैं। अगर संभव हो तो ऐसे संगठन को जल्दी छोड़ देना बेहतर है, लेकिन वास्तविकता में यह आसान नहीं होता

  • अपने अनुभव से कहूँ तो, जब किसी बहुत hierarchical जगह पर आप सार्वजनिक रूप से सवाल पूछते हैं या समस्या उठाते हैं, तो leaders इसे बेहद चिढ़कर लेते हैं और सक्रिय रूप से संवाद करने वाले व्यक्ति को “मुसीबत” मानते हैं। मैं juniors के लिए उदाहरण बनना चाहता था, इसलिए मैंने जानबूझकर ज़्यादा सवाल पूछे, ज़्यादा बोला, और वे चीज़ें और ज़्यादा कीं जिन्हें leaders नापसंद करते थे। आख़िरकार मुझे निकाल दिया गया, लेकिन उसके बाद मुझे उल्टा राहत और गर्व महसूस हुआ
  • पिछली नौकरी में मैंने देखा कि manager चोरी-छिपे लोगों के chats, emails, और दूसरे accounts तक MITM software, SSL strip जैसी कई तकनीकों से निगरानी करता था, और इसे office politics में इस्तेमाल करता था। IT staff से भी feedback मिला, जिससे पक्का हुआ कि मैंने जो देखा वह सच था। यहाँ तक कि admins चाहें तो दूसरे लोगों के emails भी देख सकते थे, और conversation logs इकट्ठा करना बहुत आसान था। एक और मशहूर company में भी chat content की वजह से किसी को निकाले जाने का मामला एक परिचित से सुना। सबक यही है कि अगर software, device, और network company ने दिए हैं, तो हर शब्द सोच-समझकर बोलना चाहिए
  • “लिखित रूप में छोड़ना” ज़्यादा भारी लगता है, क्योंकि उसमें nuance और meaning और गहरे रह जाते हैं, और वह किसी भी समय निगरानी के दायरे में आ सकता है। आमने-सामने की बातचीत की तुलना में यह बात काफ़ी ज़्यादा परेशान करती है। असल में सामने मिलकर कभी-कभी असहज बातें भी हो जाती हैं, लेकिन messenger या email में एक बार लिख दिया तो उसका रिकॉर्ड बना रहता है, इसलिए दबाव बढ़ जाता है। यह सिर्फ “control पसंद CEO” की बात नहीं, बल्कि उससे कहीं अधिक आम मानवीय भावना लगती है

• कुल मिलाकर मैं शीर्षक से सहमत हूँ, लेकिन उसका ठोस तरीका मेरी पसंद का नहीं है। मुझे लगता है कि सबसे उपयुक्त channel group (टीम-आधारित/प्रोजेक्ट-आधारित/manager-आधारित आदि) चुनकर बस बातचीत शुरू कर देनी चाहिए। व्यस्त channels अपनी communication culture खुद विकसित कर लेते हैं, और काम की बातों के साथ कुत्ते को घुमाते हुए दिखी कोई अजीब चीज़ की फोटो भी आराम से मिलाई जा सकती है। “threads” feature होने से इसे संभालना भी आसान होता है

  • “threads” सच में यह काम बहुत अच्छे से करते हैं। अलग-अलग channels बहुत ज़्यादा बना देने से उल्टा भ्रम पैदा होता है। मुझे लगता है कि यह उन छोटे संगठनों की पुरानी आदत है जहाँ पहले threads feature नहीं होता था

• मुझे जिज्ञासा है कि यह तरीका मौजूदा off-topic channels (#general आदि) से किस तरह अलग है। ख़ास तौर पर 2–10 लोगों जैसी छोटी organization में, मुझे नहीं लगता कि कई “rambling” channels की ज़रूरत है; एक off-topic channel ही काफ़ी होना चाहिए

  • “Claude Code का इंतज़ार करते समय” वाला वाक्यांश बड़े मज़ेदार तरीके से “compile होने तक इधर-उधर करना” वाली पुरानी धारणा का नया संस्करण लगता है
  • व्यवहार में 2–10 अलग-अलग personal channels में 1–3 पोस्ट होना, एक ही जगह 30 पोस्ट होने से आसान लगता है। “कहीं मैं कुछ महत्वपूर्ण मिस तो नहीं कर रहा?” वाला डर कम हो जाता है। हमारी टीम में off-topic channel है, लेकिन व्यक्तिगत rambling channels ज़्यादा सक्रिय रहते हैं। मौजूदा बातचीत के उलझने का जोखिम कम होता है, और हर व्यक्ति के विचारों की continuity भी बनी रहती है
  • उल्टा, अगर सबको एक ही single off-topic channel में बात करने के लिए कहा जाए, तो छोटी टीम न हो तो यह कहीं ज़्यादा बोझिल हो सकता है
  • एक नज़रिया यह भी है कि Slack का #general मूलतः यही भूमिका निभाता है