सहयोग बेकार है

• "अकेले जाओ तो तेज़ जाते हो, साथ जाओ तो दूर तक जाते हो" जैसी कहावत startup को बर्बाद कर सकती है
• प्रभावी collaboration ड्राइविंग के दौरान navigation की मदद जितना होना चाहिए, लेकिन ज़्यादातर कंपनियाँ हद से ज़्यादा feedback और role distribution की वजह से धीमी पड़ जाती हैं
• PostHog "You're the Driver" वैल्यू के तहत स्वायत्तता और ऊँची ownership पर ज़ोर देता है और अनावश्यक collaboration को न्यूनतम रखता है
• अत्यधिक collaboration के कारणों में मददगार बनना चाहना, inclusive culture, अस्पष्ट feedback request, 'let's discuss' का अति-प्रयोग, जिम्मेदारी से बचना आदि शामिल हैं
• समाधान के तौर पर तुरंत shipping को प्राथमिकता, जिम्मेदार व्यक्ति को स्पष्ट करना, सिर्फ ज़रूरी लोगों से feedback माँगना, launch के बाद feedback, और अनावश्यक collaboration को तुरंत रोकना जैसी व्यावहारिक approach दी गई है

---

सहयोग का जाल

• "तेज़ जाना हो तो अकेले, दूर जाना हो तो साथ" जैसी बात किसी कंपनी को धीरे-धीरे खत्म कर सकती है
  • यह अत्यधिक collaboration को सही ठहराने वाला जाल है
  • उपयोगी collaboration बस ड्राइविंग के दौरान दिशा या आसपास की जानकारी देने जितना होना चाहिए
• लेकिन ज़्यादातर संगठन बारी-बारी से स्टीयरिंग पकड़ने वाले अक्षम collaboration में फँस जाते हैं
• उचित feedback आपको मंज़िल तक जल्दी पहुँचा सकता है, लेकिन अत्यधिक feedback गति घटा देता है और आपको चाही गई जगह तक न पहुँचने के जोखिम में डाल देता है

feedback का paradox: feedback अच्छी तरह देना यह जानना भी है कि उसे कब नहीं देना चाहिए

• PostHog में भी growth के साथ ऐसा collaboration बढ़ा जो value नहीं जोड़ता था या लगाए गए समय की तुलना में बहुत कम value देता था
  • हाल की all-hands meeting में "collaboration is bad" विषय पर बात हुई
• "You're the driver" PostHog की मुख्य value है: "बेहतरीन लोगों को hire करो और उनके रास्ते में मत आओ"
  • कोई deadline नहीं, न्यूनतम coordination, manager निर्देश नहीं देते
• इसके बदले बेहद ऊँची ownership और अकेले बहुत काम कर पाने की क्षमता की अपेक्षा की जाती है
  • marketer कोड deploy करता है, sales व्यक्ति बिना backup के technical सवालों का जवाब देता है, product engineer पूरे stack पर काम करता है
• लगभग हमेशा कोई न कोई आपसे बेहतर होता है, इसलिए collaboration करने का लालच रहता है, लेकिन collaboration driver को धीमा करता है और उससे background, context, और अपनी सोच समझाने पर मजबूर करता है
• यह प्रवृत्ति कुछ आम वाक्यों में दिखती है
  • "जानना चाहता हूँ कि X क्या सोचता है"
  • "Y की राय सुनना चाहता हूँ"
  • "हमें Z के साथ काम करना चाहिए"
• इससे कभी-कभी उपयोगी insight मिलती है, लेकिन यह हमेशा driver की गति कम करती है
• यह driver की motivation, confidence, और efficiency को घिसता है और अंततः launch/output कम कर देता है

अगर collaboration बुरा है, तो लोग इसे करते क्यों हैं

• इसके लिए हर कोई कुछ न कुछ ज़िम्मेदार है
• लोग मदद करना चाहते हैं: जब कोई Slack पर अपना चल रहा काम पोस्ट करता है, तो feedback culture की वजह से दूसरों को लगता है कि उन्हें feedback देना चाहिए
• उल्टा, किसी खास व्यक्ति से feedback माँगना inclusive नहीं लगेगा ऐसा महसूस होने पर लोग माँगते ही नहीं, जबकि वास्तव में वह मददगार हो सकता है
• किस तरह का feedback चाहिए यह पर्याप्त रूप से specific नहीं होता: इससे collaboration के दखल की गुंजाइश बनती है. किसी feature पर चर्चा पूरे product roadmap की पुनर्समीक्षा तक फैल सकती है
• जब कोई अच्छा idea देता है, तो डिफ़ॉल्ट प्रतिक्रिया "इसे करो" की बजाय "आओ discuss करें" बन जाती है
  • सबूत के तौर पर Slack में "let's discuss" बेहिसाब दिखता है
  • इससे execution की जगह discussion हावी हो जाता है
• लोग इतने व्यस्त होते हैं कि execute नहीं कर पाते, या फिर आलस में सिर्फ बात करना चाहते हैं
  • PR → issue/RFC → Slack (अभी ज़्यादातर यहीं) → "let's discuss" की ओर खिसकना
• यह स्पष्ट नहीं होता कि owner कौन है (या कोई भी चर्चा में चल रही चीज़ own नहीं करना चाहता)
• यह चिढ़ाने वाला है, लेकिन कभी-कभी एक व्यक्ति शुरू से अंत तक पर्याप्त quality के साथ shipping नहीं कर सकता, और बस ship करके iterate करना भी संभव नहीं होता
  • टूटा हुआ code ठीक किया जा सकता है, लेकिन newsletter दोबारा नहीं भेजी जा सकती

collaboration को कैसे तोड़ें (और कैसे ज़्यादा तेज़ और दूर जाएँ)

• अगर collaboration को दुश्मन मानें, तो उसे हराएँ कैसे
• डिफ़ॉल्ट execution-first हो: Pull request > Issue > Slack message
• जब collaboration ज़रूरत से ज़्यादा हो, तो साफ़ कहें: "तुम driver हो, फैसला करो"
• feedback देते समय किससे और किस बारे में क्या चाहिए यह स्पष्ट रूप से tag करें, यूँ ही खुला न छोड़ें
• pre-launch review से बेहतर launch के बाद (अगले iteration से पहले) feedback देना है: पहले का feedback एक तरह की approval process में बदल सकता है
• leaders को feedback देने में संयम रखना चाहिए और "you can just do stuff" वाला रवैया बनाए रखना चाहिए
• हर व्यक्ति "informed captain" की तरह हो
  • feedback सुन सकता है, लेकिन फैसला वही लेता है

निष्कर्ष

• हर collaboration को पूरी तरह खत्म नहीं किया जा सकता, और कुछ collaboration उपयोगी भी होता है (इस newsletter को Ian और Andy ने edit किया)
• लेकिन डिफ़ॉल्ट रूप से collaboration घटाने की कोशिश ज़रूरी है
• अगर आप सक्रिय रूप से collaboration कम नहीं कर रहे, तो बहुत संभव है कि आप डिफ़ॉल्ट रूप से बहुत ज़्यादा collaboration कर रहे हों
• collaboration मूल रूप से गति कम करता है, इसलिए
  जितना कम collaboration, उतनी ज़्यादा दूरी और उतनी ज़्यादा रफ़्तार

• Charles Cook द्वारा लिखा गया (जो bubbles के ज़रूरत से ज़्यादा collaborative होने की वजह से sparkling water को नापसंद करते हैं)

[shakespeares]

साथ मिलकर काम करना ही सही है.
अगर वह व्यक्ति अनुपस्थित हो (मृत्यु, बीमारी, छुट्टी), तो क्या आप क्लाइंट को जवाब नहीं देंगे?

[carnoxen]

मैं इतनी छोटी कंपनी में काम करता/करती हूँ कि यहाँ काम करने वाला सिर्फ मैं ही हूँ। इसलिए मेंटेनेंस भी अकेले करता/करती हूँ और डेवलपमेंट भी अकेले ही करता/करती हूँ.... लेकिन बहुत लंबे समय से यही स्थिति है, तो अब लोगों के साथ मिलकर काम करने का मन भी होता है। अकेले काम करना बहुत अकेलापन भरा है...

[jjpark78]

यह लेख बहुत ही उकसाने वाला है।
क्या ऐसा नहीं है कि लेखक की व्यक्तिगत शैली इतनी ज़्यादा उभरकर आती है कि वे दूसरों के साथ अच्छी तरह घुल-मिल नहीं पाते?

एक फीचर बनाने के लिए
डिज़ाइनर, प्लानिंग, प्रोजेक्ट मैनेजर, फ्रंटएंड, बैकएंड, QA आदि जैसी भूमिकाएँ तो अनिवार्य रूप से चाहिए होती हैं।

[coremaker]

ऐसा लगता है कि लेखक अपनी नज़र में दिख रही समस्या को उजागर करने के लिए कुछ ज़्यादा ही अतिरंजित दावा कर रहे हैं.
सहयोग का मतलब शायद यह नहीं है कि वह Agora जैसी किसी पद्धति से ही किया जाए.

हालाँकि, let’s discuss का अंधाधुंध इस्तेमाल और ज़िम्मेदारी से बचना — ये दो बातें निश्चित रूप से समस्या हैं.
लेकिन ज़्यादातर मामलों में ऐसा इसलिए होता है क्योंकि insight रखने वाले leader या ज़िम्मेदार व्यक्ति मौजूद नहीं होते.

इसी तरह की चीज़ों के लिए तो research किया जाता है, लोगों को विकसित किया जाता है, hiring की जाती है, या solutions खरीदे जाते हैं.
अगर टीम सिर्फ़ ऐसे सदस्यों से बना दी जाए जो बस बात मानते हों, तो यह और भी भड़क सकता है.
मुझे नहीं लगता कि यह सहयोग या अकेले काम करने से पैदा होने वाली समस्या है.

[xguru]

ध्यान रखें कि Posthog हमेशा इसी तरह की कड़ी भाषा वाले लेख लिखता है.
टोन बहुत ज़्यादा तीखी होने की वजह से कभी-कभी ऐसे लेख दिखते हैं जो विषय से थोड़ा भटकते हुए लगते हैं.
(स्पार्कलिंग वॉटर इतना अच्छा होता है!!!)

[t7vonn]

कार्बोनेटेड पानी? वो हाईबॉल लॉन्चर नहीं है क्या, खंखार।

[GN⁺]

Hacker News राय

• जब भी collaboration होता है, एक सलाह यह थी कि कहो, “बहुत ज़्यादा लोग हैं, X driver है, इसलिए फैसला तुम करो”
  लेकिन अगर manager “तुम फैसला करो” कहकर मीटिंग में ही न आए, और बाद में “मैं होता तो अलग करता” कहकर बदलाव करवाए, तो कर्मचारी चले जाते हैं

  • Apple छोड़ने की मेरी एक वजह यही थी
    manager का manager हमेशा ऐसे ही कहता था, और जब मैं PR उठाता था तो आखिर में पूरा redesign माँगता था
    आखिरकार हर project को शुरू से फिर लिखना पड़ेगा, यह जानकर काम ही डरावना लगने लगा
  • इससे भी बदतर नतीजे होते हैं
    अगर बॉस बहुत बार अपना फैसला पलट दे, तो टीम के लोग जानबूझकर हर फैसला उसी पर डालने लगते हैं
    आखिर में बॉस अपनी ही control की इच्छा में घुटने लगता है
  • यह सलाह “launch के बाद feedback दो” वाले सिद्धांत से टकराती हुई लगती है
    लेकिन “manager को निर्देश नहीं देने चाहिए” वाले संदर्भ में यह सुसंगत है
  • एक पुरानी नौकरी में “what about…” शब्द trigger word बन गया था
    क्योंकि उसके बाद endless pixel tweaks, layout changes, और full-stack rework के सुझाव शुरू हो जाते थे
  • “कर्मचारी खोने का बढ़िया तरीका है” वाली बात पर किसी ने मज़ाक में कहा, “बढ़िया तरीका? नोट करना पड़ेगा”

• मुझे लगता है असली समस्या collaboration नहीं बल्कि decision-making structure है
  feedback सीखने का मौका है, लेकिन अगर यह साफ़ न हो कि अंतिम फैसला कौन लेता है, तो गति धीमी हो जाती है
  तेज़ फैसलों के लिए decision-maker को साफ़ तय करना चाहिए, और यह समझ भी रखनी चाहिए कि ज़्यादातर फैसले वापस पलटे जा सकते हैं

  • यही मुख्य insight है
    collaboration कम होगा तो सीखने के मौके भी कम होंगे
    decision-maker स्पष्ट रूप से तय होना चाहिए, लेकिन feedback ध्यान से सुनना चाहिए
    और reversible decisions को तेज़ी से लेना बेहतर है
    कहा जाता है कि collaboration गति धीमी करता है, लेकिन असल में उसी प्रक्रिया में quality बढ़ती है
  • अगर feedback ईमानदारी से आए तो अच्छा है, लेकिन कुछ कंपनियों में feedback power game बन जाता है
    कुछ लोग सिर्फ विरोध के लिए विरोध करते हैं, और आखिर में idea की ownership छीनना चाहते हैं
  • जब कोई non-technical व्यक्ति अंतिम फैसला लेता है, तो मीटिंग बढ़ने के साथ चीज़ें “committee design” की तरफ़ बहने लगती हैं
    अंतिम decision-maker साफ़ हो तब भी, अगर उसकी राय कमज़ोर हो, तो बात आखिर में बहुमत की सहमति पर चली जाती है
  • ऐसे सहकर्मी भी थे जो PR review को अपनी निजी पसंद के हिसाब से hijack कर लेते थे
    अगर वे “request changes” लगा दें, तो सबको वही मानना पड़ता था, और आखिर में code quality और खराब हो जाती थी
    मुझे लगता है अच्छे लोगों को hire करना और decision authority delegate करना कहीं बेहतर है
  • अच्छा leader वह है जो खुद फैसला लेने से ज़्यादा autonomous decisions की संख्या बढ़ाता है
    उसे direction, priorities, और framework देने चाहिए ताकि टीम खुद निर्णय ले सके

• लेखक की sparkling water से नफ़रत से मैं सहमत नहीं हूँ, लेकिन collaboration की समस्याओं को सार्वजनिक रूप से उठाना अच्छा लगा
  कई कंपनियों में code review के दौरान छोटी style टिप्पणियों की वजह से असली implementation से 3 गुना ज़्यादा समय लगते देखा है
  मेरा रुख यह है: “अगर पसंद नहीं है तो खुद बदलो और बता दो”
  संबंधित वीडियो भी साझा किया गया

  • अगर formatter को build pipeline में डाल दिया जाए, तो style की समस्या अपने-आप हल हो जाती है
    code review के चरण में इसे उठाना बहुत देर हो चुकी होती है
  • ज़्यादातर कंपनियाँ auto formatter इस्तेमाल करती हैं, इसलिए ऐसी समस्याएँ अक्सर naming या code structure के स्तर की होती हैं
    समस्या वह व्यक्ति होता है जो आसपास के code style के अनुसार नहीं चलता
  • PR में छोटी-छोटी बातों पर आपत्ति करना collaboration नहीं है
    इसे linter या culture से सुलझाना चाहिए
  • “क्या छोटी टिप्पणी है, और क्या code cleanliness के लिए ज़रूरी है”, यह आखिरकार टीम को तय करना चाहिए
  • feature asset नहीं, debt है
    collaboration के बिना अकेले बनाया गया feature maintenance के समय बड़ा risk बन जाता है
    जब मेरे न रहने पर system टूटता है, तब collaboration की कमी असली समस्या बनकर सामने आती है

• लेखक action bias पर ज़ोर देता है, लेकिन collaboration को हटाने से silos और overconfidence पैदा होते हैं
  “मैं X करने जा रहा हूँ, कोई strong objection है?” जैसी Slack culture असरदार रही है

  • इस approach की ताकत यह है कि इसे framing इस तरह किया गया है कि जवाब “हाँ/नहीं” में दिया जा सके
    इसलिए काम सचमुच आगे बढ़ता है

• पहले मैंने GitHub पर एक किताब लिखते समय इंटरव्यू किए थे, और कुछ टीमें code लिखने से पहले empty PR उठाकर design approval लेती थीं
  यह चलते-चलते होने वाला collaboration नहीं, बल्कि planning stage collaboration है
  अगर writing और communication अच्छे हों, तो collaboration तेज़ और असरदार हो सकता है
  AI के दौर में यह क्षमता और भी महत्वपूर्ण होगी

  • उम्र बढ़ने के साथ समझ आया कि नतीजों से ज़्यादा visibility महत्वपूर्ण होती है
    अगर meetings और sharing न हों, तो credit दिखता ही नहीं
    अगर आप समस्या रोक दें तो किसी को पता नहीं चलता, इसलिए कुछ जगहों पर “समस्या होने दो” जैसी संस्कृति भी बन जाती है
  • हमारी टीम भी महत्वपूर्ण बदलावों से पहले बैठक करती थी, और उससे समय की बर्बादी बहुत कम हुई
  • सच कहें तो यह तरीका SCRUM की उत्पत्ति जैसा ही है
  • लेकिन मैं उन लोगों में हूँ जिन्हें code सचमुच लिखना पड़ता है तभी structure दिखती है
    सिर्फ planning से implementation की कल्पना करना मुश्किल होता है
  • आखिरकार वह design document से अलग नहीं है

• लेख की आख़िरी पंक्ति की तरह, “अच्छा collaboration मौजूद है”
  शीर्षक clickbait है, लेकिन PostHog वैसे भी इस शैली के लिए जाना जाता है

  • मज़ाक में कहा गया कि clickbait भी किसी तेज़ी से लिखने वाले बहादुर driver का ही नतीजा है
  • परिचित concepts को नए ढंग से पैकेज करना उपयोगी है
    इससे “collaboration” जैसे meme को आलोचनात्मक नज़र से देखने का मौका मिलता है
  • समस्या का असली सार committee design है

• यह लेख एक गलत thought experiment है
  समस्या collaboration नहीं, बल्कि decision authority की कमी है
  किसी एक व्यक्ति को साफ़ तौर पर फैसला लेना चाहिए, और यह अधिकार जितना नीचे दिया जाए, गति उतनी बढ़ती है

  • सहमत। decision-maker न हो तो सब कुछ रुक जाता है
    ऐसे लेख भाषा को विकृत करते हैं और ज़रूरी concepts को बेकार बना देने वाली विषाक्तता पैदा करते हैं
  • लेकिन यह सिर्फ फैसले की समस्या नहीं है
    अगर कोई अटक जाए और संस्कृति तुरंत “Bob से पूछो” कहे, तो वह भी समस्या है
    short term में यह तेज़ लगता है, लेकिन long term में सीखने के मौके का नुकसान और काम का बोझ बढ़ना पैदा करता है

• मुझे अच्छा लगता है जब सहकर्मी मेरे काम में रुचि लेते हैं
  “तुम खुद देख लो” का मतलब असल में “मुझे दिलचस्पी नहीं है” होता है
  समस्या collaboration नहीं, बल्कि inefficient collaboration है

  • लेख जानबूझकर hot take की तरह लिखा गया है, लेकिन 3~4 से ज़्यादा लोगों वाली बैठकें ज़्यादातर समय की बर्बादी होती हैं
    PR में ठोस output होता है, इसलिए चर्चा साफ़ रहती है

• मुझे लगता है collaboration दो लोगों पर सबसे अच्छा काम करता है
  दो लोग codebase को साथ समझ सकते हैं और एक-दूसरे के PR review कर सकते हैं
  लेकिन तीन या उससे ज़्यादा लोग होते ही combinatorial complexity फट पड़ती है
  इसलिए मैं project को 2-person team structure में design करना चाहूँगा

  • यह लगभग Amazon ka Two-Pizza Team concept ही है
    संदर्भ लिंक

• लेख की उपमा की तरह, F1 racing बेहद collaborative sport है
  driver पूरे race के दौरान coach से लगातार संपर्क में रहता है
  सोचता हूँ software में ऐसा उदाहरण क्या होगा

  • pair programming उसका उदाहरण है
  • या cross-functional team
  • या GitHub Copilot

[slowandsnow]

कॉमेंट्स कुछ अजीब हैं। लेख का सार देखें तो बात यह नहीं लगती कि अकेले काम करो या टीम मेंबर्स की ज़रूरत नहीं है, बल्कि यह कि टीम मेंबर्स के बीच होने वाले अत्यधिक collaboration को कम किया जाए।

[t7vonn]

सहमत हूँ

[guarder]

लगता है यह उकसाने वाले शीर्षक और बिना ध्यान से पढ़े हुए पाठक के मेल का नतीजा है।

[ndrgrd]

सिर्फ ऐसे लेख ही नहीं, YouTube पर भी बहुत से लोग सिर्फ़ शीर्षक देखकर ही कमेंट कर देते हैं।

[joone]

जब आप कोई नया काम शुरू करते हैं, तो बहुत सुरक्षित तरीके से आगे बढ़ने की कोशिश में आप आसपास के लोगों से जरूरत से ज़्यादा review मांग सकते हैं। लेकिन असल में, आसपास के लोग या टीम उस विषय को अच्छी तरह नहीं जानते हो सकते हैं, इसलिए उनके लिए अच्छा feedback देना भी मुश्किल हो सकता है। आखिरकार बात शायद यह है कि पहले कुछ बना लेना, चाहे वह गलत दिशा में ही क्यों न हो, और उसके बाद ठोस feedback लेकर फिर से काम करना, कुल मिलाकर समय बचा सकता है।