जब टीम बहुत बड़ी हो जाए

• विशेषज्ञ-केंद्रित बड़ी टीमें आंतरिक dependencies, communication errors, bottlenecks और responsibility dilution की वजह से productivity और collaboration efficiency में तेज गिरावट लाती हैं
• डेली stand-up meeting में ज़्यादातर बातें अनावश्यक या उबाऊ हो जाती हैं; यानी टीम के आकार में बढ़ोतरी और specialization communication gap और disengagement पैदा करते हैं
• तकनीक-आधारित विभाजन (front/back-end), अस्थायी feature teams, external consultants का उपयोग जैसे कई प्रयोग हुए, लेकिन आखिर में generalist roles में बदलाव ने सबसे व्यावहारिक असर दिखाया
• Mob programming जैसी सामूहिक collaboration knowledge sharing, self-direction, responsibility और motivation को बढ़ावा देती है, और सिर्फ़ एक domain पर अड़े रहने की बजाय result-oriented collaboration और growth के लिए ज़्यादा अनुकूल है
• हालांकि, generalization के side effects (expertise में कमी, burnout का जोखिम) भी मौजूद हैं, और लगातार experimentation और cultural improvement ज़रूरी है

---

जब टीम बहुत बड़ी हो जाए तो समस्याएँ

• 14 लोगों की बड़ी टीम में शुरू हुई समस्या: stand-up में ज़्यादातर बातचीत अनावश्यक थी, और काम के handoff छूट जाना तथा अनौपचारिक काम का होना आम था
• asynchronous stand-up (Slack आदि) में बदलने पर भी ज़रूरी बातचीत और collaboration के मौके गायब हो गए, और वह एक साधारण status report बनकर रह गया

विभाजन और संचालन के विभिन्न प्रयोग

• तकनीक के आधार पर (Task Force) विभाजन: front-end/back-end में बाँटा गया, लेकिन तुरंत mutual dependency की समस्या आई और अतिरिक्त stand-up में शामिल होने से समय और बढ़ गया
• अस्थायी feature teams: किसी खास feature implementation के हिसाब से लोगों को अस्थायी रूप से फिर से तैनात किया गया, जिससे maintenance और resource management की समस्याएँ पैदा हुईं
• external consultants की तैनाती: टीम पहले से बड़ी होने के बावजूद inefficiency बनी रही, और senior management की resource utilization वाली दबावपूर्ण अपेक्षाएँ भी थीं

जो समाधान अंततः प्रभावी रहा

• specialist की जगह generalist model अपनाया गया
  • front-end, back-end, QA, DevOps जैसी भूमिकाओं को अलग करने के बजाय एक goal/product के आसपास पूरी skill set साझा की गई
  • knowledge sharing, responsibility dilution में कमी, bottlenecks का समाधान, और तेज delivery/उच्च quality हासिल हुई
  • Mob programming जैसी सामूहिक collaboration से communication, autonomy और ownership मज़बूत हुए

generalist प्रभावी क्यों रहे

• साझा context और purpose: नया domain होने पर भी उसी product/goal के आधार पर learning curve आसान हुआ
• सीमित आवश्यकता: कुछ खास tools (CI/CD आदि) सीख लेना ही काफी था; गहरी specialization से ज़्यादा productivity और maintainability को महत्व दिया गया
• motivation के 3 तत्व (autonomy, mastery, purpose) सभी पूरे हुए, जिससे टीम की ownership भावना और growth को समर्थन मिला
• Egalitarian culture: समान access, self-driven knowledge acquisition, authority और responsibility का वितरण, और collective learning
• responsibility के 3 तत्व (knowledge, authority, responsibility) स्पष्ट हुए, जिससे ownership-आधारित तेज़ और उच्च-quality नतीजे मिले

side effects और सीमाएँ

• विशेषज्ञों का अलग होना: generalization हर किसी के लिए उपयुक्त नहीं होती, और कुछ लोगों में burnout या resource overload हो सकता है
• expertise की गहराई में कमी: कई stacks को सतही रूप से संभालने के कारण किसी एक क्षेत्र में गहरी महारत प्रभावित हो सकती है

निष्कर्ष और सीख

• कोई एक जैसा समाधान नहीं होता; experimentation और improvement की culture अधिक महत्वपूर्ण है
• specialist model की कमियाँ (bottlenecks, communication gap, fake work, context fragmentation) को generalist approach और collective collaboration से कम किया जा सकता है
• अंततः goal, लोगों, budget और product की विशेषताओं के अनुसार सबसे उपयुक्त model अलग हो सकता है
• सबसे महत्वपूर्ण है open experimentation, feedback और continuous improvement की culture

[codemasterkimc]

मैं एक generalist हूँ, लेकिन काम के मैदान में मैंने यही महसूस किया है.
काम का generalist होता है, लेकिन असली 'value' specialist को ही मिलती है.
एक ही university, एक ही grades होने पर भी आखिरकार specialist लोगों को 2~3 गुना ज़्यादा compensation मिलता है — यही हकीकत है.

[kandk]

मेरी भी लगभग यही राय है।
लेकिन मेरी राय में, software के मानकों से देखें तो अगर वह अमेरिका का deep tech नहीं है, तो specialist वास्तव में इतने special नहीं लगते।

[roxie]

क्या आप कोई उदाहरण साझा कर सकते हैं! मैं यह जानना चाहता/चाहती हूँ कि व्यावहारिक तौर पर जिसे specialist कहा जाता है, उसमें 'special' आखिर कितनी हद तक होता है...

[codemasterkimc]

HR के मानक के हिसाब से लगता है कि बड़े या mid-sized enterprise में लगभग 3 साल का अनुभव मांगा जाता है, और मेरे मानक में ‘specialist’ वह है जो backend दृष्टिकोण से LLM का उपयोग करके ऐसी संरचना डिज़ाइन कर सके जिसे कोई भी आसानी से इस्तेमाल कर सके और जिसमें high availability का भी ध्यान रखा गया हो.
उदाहरण के लिए, मैं generalist हूँ, लेकिन किसी भी घरेलू service के लिए 10 करोड़ से अधिक users का traffic ऐसी सादगी से डिज़ाइन कर सकता हूँ कि एक प्राथमिक स्कूल का छात्र भी उसे समझ सके.
लेकिन फिर मैं generalist हूँ, इसलिए बड़ी कंपनियों में resume screening में ही कट जाता हूँ lol