Google ने पिछले 1 साल में छोटे टीम managers के 35% पद घटाए

 (cnbc.com)
3 पॉइंट द्वारा GN⁺ 2025-08-28 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • संगठनात्मक efficiency बढ़ाने के लिए Google ने छोटी टीमों को manage करने वाले managers के 35% पद घटाए; यह मुख्य रूप से उन managers पर लागू हुआ जो 3 से कम कर्मचारियों की निगरानी करते थे
  • जिन managers के पद घटाए गए, उनमें से कई individual contributor (IC) भूमिकाओं में रहकर कंपनी में काम करते रहे
  • Voluntary Exit Program (VEP) को search, marketing, hardware, people operations teams समेत 10 product क्षेत्रों में लागू किया गया, और 3~5% कर्मचारियों ने इसे स्वीकार किया
  • ये बदलाव अप्रभावी bureaucracy को घटाने और headcount बढ़ाए बिना scale हो सकने वाला operating model बनाने की कोशिश का हिस्सा हैं
  • Google का यह restructuring, बेहतर financial performance और stock price बढ़ने के बावजूद, employee morale पर नकारात्मक असर डाल रहा है और व्यापक tech industry के efficiency trend को दिखाता है

Google की manager कटौती और efficiency strategy

  • Google ने पिछले 1 साल में छोटी टीमों (3 से कम कर्मचारियों) को manage करने वाले managers के 35% पद घटाए
    • HR analytics और performance के VP Brian Welle ने all-hands meeting में कहा, “अब managers की संख्या पिछले साल की तुलना में 35% कम है, और direct reports भी कम हुए हैं।”
    • यह कदम bureaucracy कम करने और efficient operations के लक्ष्य से जुड़ा है
  • जिन managers के पद घटाए गए, उनमें से अधिकतर individual contributor (IC) में बदलकर कंपनी में बने रहे
  • CEO Sundar Pichai ने ज़ोर देकर कहा, “हमें headcount बढ़ाकर हर समस्या हल नहीं करनी चाहिए; scale करते समय efficiency बढ़ानी होगी।”
  • लक्ष्य management, directors और VP का अनुपात कुल workforce में घटाकर leadership structure को सरल बनाना है

Voluntary Exit Program (VEP) और restructuring

  • Google ने 2023 में कुल workforce का लगभग 6% घटाने के बाद कई departments में अतिरिक्त layoffs किए
    • Alphabet की CFO Anat Ashkenazi ने कहा कि अक्टूबर 2024 में cost cuts को “और तेज़” किया जाएगा
  • Voluntary Exit Program (VEP) अमेरिका-आधारित कर्मचारियों के लिए search, marketing, hardware, people operations समेत 10 product क्षेत्रों में पेश किया गया
    • Chief People Officer Fiona Cicconi ने बताया कि इन teams के 3~5% कर्मचारियों ने VEP स्वीकार किया
    • VEP को कर्मचारियों ने career break या family care जैसे कारणों से चुना, और इसे “काफी सफल” माना गया
  • Pichai ने कर्मचारियों की broad layoffs के खिलाफ राय को देखते हुए VEP शुरू किया और कहा कि “इसने कर्मचारियों को choice दी और यह अच्छी तरह काम किया।”

employee morale और corporate culture को लेकर चिंता

  • कर्मचारियों ने meeting में job security, internal barriers और Google की culture को लेकर सवाल उठाए
    • हालिया layoffs, buyouts और organizational reshuffling के कारण morale गिरने की बात सामने आई
  • Google ने 2023 में 58%, 2024 में 36% और 2025 में 10% की stock price growth दर्ज की, जिससे उसका financial performance मज़बूत बना रहा

competitors की policies की तुलना और internal response

  • कर्मचारियों ने Meta की 5 साल काम करने के बाद मिलने वाली 1 महीने की paid recharge leave जैसी सुविधा की मांग की
    • benefits की senior director Alexandra Maddison ने कहा कि मौजूदा leave policy competitive है, और recharge leave लाने से इनकार किया
  • Cicconi ने कहा, “Meta के पास VEP जैसा program नहीं है।”
    • Pichai ने मज़ाक में कहा, “क्या हमें Meta की सारी policies अपनानी चाहिए, या केवल कुछ चुननी चाहिए?” और इस पर असहमति जताई

tech industry के trend और तुलना

implications और outlook

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

1 टिप्पणियां

 
GN⁺ 2025-08-28
Hacker News टिप्पणियाँ
  • Google में इस भूमिका को TLM(Technical Lead/Manager) कहा जाता था, TLM का काम असल में कोडिंग करते हुए कुछ junior engineers को मैनेज करना था। हाल के वर्षों में कंपनी hybrid roles कम करके manager और engineer की जिम्मेदारियाँ अलग-अलग रखने की दिशा में बढ़ रही है। ऊपर से इसे efficiency बढ़ाने के तौर पर पेश किया गया, लेकिन असल में इसका मतलब सिर्फ यह था कि TLMs को पूरी तरह programming पर फोकस करने के लिए लगा दिया गया।
    • लगभग 3 साल पहले से Google ने व्यवस्थित रूप से TLM role को खत्म करने की दिशा में बढ़ना शुरू किया था। उस समय मेरे manager staff level के थे और 4 लोगों से reports लेने वाले IC TLM थे, लेकिन उन्हें ज़बरदस्ती EM(Engineering Manager) में बदल दिया गया। पिछले 3 सालों में TLM को सिर्फ overloaded EM की मदद करने वाली भूमिका की तरह इस्तेमाल किया गया। मैंने जो पैटर्न देखा, उसमें EM-IC-junior संरचना वाले किसी project में अगर dedicated manager फिट नहीं बैठता था, तो कोई Senior IC अस्थायी रूप से TLM role ले लेता था, और बाद में या तो आधिकारिक रूप से EM बन जाता था या फिर वापस IC बन जाता था। मेरे आसपास मैंने ऐसे 2 मामले देखे, और दोनों में 1~2 साल बाद लोग फिर IC बन गए, क्योंकि TLM रहते हुए 70% IC और 70% EM जैसी संयुक्त जिम्मेदारी उठानी पड़ती थी। अब आधिकारिक रूप से TLM खत्म हो चुका है, इसलिए Principal EM तकनीकी कामों का अधिकांश हिस्सा delegate कर देता है लेकिन औपचारिक title नहीं देता। मैंने भी Senior IC के रूप में project C संभालते हुए ऐसा अनुभव किया है।
    • TLM की भूमिका मुझे हमेशा एक trap जैसी लगी। अगर मुझे यह role ऑफर भी किया जाए, तो मैं कभी नहीं लूँगा। बाहर से इसे 50% coding, 50% managing कहकर बेचा जाता था, लेकिन असल expectation 80% coding और 80% managing की होती थी।
    • ऐसा लगता है कि Google धीरे-धीरे एक सामान्य ‘technical lead’ मॉडल की तरफ जा रहा है। Lead के पास आमतौर पर mentoring role और authority होती है, लेकिन वास्तविक management chain में कोई दूसरा manager संभालता है। अनौपचारिक रूप से tech lead junior लोगों को guide कर सकता है, लेकिन अगर सीधे disciplinary action की जरूरत पड़े तो अलग manager को हस्तक्षेप करना पड़ता है। TLM शायद big tech की एक अजीब-सी संस्कृति रही हो, लेकिन efficiency से अलग भी देखें तो मुझे यह अच्छा management structure नहीं लगता।
    • हमारी कंपनी में भी TLM थे, और कुछ cases सफल रहे तो कुछ विफल। आमतौर पर वही लोग लंबे समय तक TLM रहते थे जो उस भूमिका में टिके रहे, और 1-2 junior लोग उनसे knowledge absorb करते थे। अगर domain बढ़ रहा हो और TLM code में लगातार शामिल रहे, तो चीज़ें अच्छी चलती थीं। लेकिन fail होने पर company के नज़रिए से ROI कम रहता था और यह सभी के लिए खराब अनुभव बन जाता था। Junior लोग grow कर भी जाएँ, तो अगर domain छोटा हो तो promotion के मौके लगभग नहीं होते थे। कई बार TLM सिर्फ अपना छोटा-सा kingdom बचाए रखते थे और सालाना 5~10% raise पर टिके रहते थे। जब पैसा बहुत हो और hiring ज़्यादा हो, तब ऐसी positions career growth का मौका बन सकती हैं। लेकिन headcount स्थिर हो जाए, तो आखिरकार या तो हर साल bank की तरह restructuring करनी पड़ती है या promotion impossible हो जाता है। इसलिए मुझे नहीं लगता कि 2022 के बाद ये roles लगभग गायब हो जाना कोई संयोग था।
    • मुझे लगता है यह बदलाव अच्छा है। Dual tech/management roles वाले लोगों को मैंने हमेशा बहुत stressed और overworked देखा है। इसके अलावा, अगर कोई manager तकनीकी समझ रखता है और team members के technical decisions को approve या reject कर सकता है, तो power balance की समस्या पैदा होती है। अगर कोई TLM अजीब technical दिशा को push करे, तो उसका विरोध करना मुश्किल हो जाता है क्योंकि वही व्यक्ति मेरी performance review और compensation का भी जिम्मेदार होता है।
  • <i>35% की कमी का मतलब उन managers की संख्या है जो 3 से कम लोगों को manage कर रहे थे</i> अगर किसी manager के under 0~2 लोग हों, तो मुझे वह आमतौर पर inefficient structure लगता है। हैरानी होती है कि Google में इतने manager बने ही कैसे। बाकी 65% क्या कर रहे हैं, यह भी जानने की जिज्ञासा है।
    • ऐसे छोटे team setup में यह प्रभावी हो सकता है कि manager अपना आधा समय managing में लगाए और बाकी आधा team के actual काम में सीधे योगदान दे। लेकिन अगर उसके पास breathing room न हो, तो वह दोनों में से कोई भी काम ठीक से नहीं कर पाएगा। Part-time manager का संगठन में influence कम होता है, इसलिए team की ठीक से वकालत करना भी मुश्किल हो जाता है। हमने यह structure इस्तेमाल करके देखा, और अंत में वह setup बेहतर लगा जिसमें सभी लोग engineer की तरह काम करते थे और छोटे pods एक dedicated manager को report करते थे।
    • मेरे अनुभव में ऐसा अक्सर reorgs या लोगों के जाने के बाद backfill सीमित करने से होता है। शुरुआत में manager सामान्य रूप से कई लोगों को manage कर रहा होता है, लेकिन समय के साथ headcount घटते-घटते यह स्थिति बन जाती है।
    • व्यक्तिगत रूप से मुझे 0 लोगों को manage करना सबसे अच्छा लगता है। अगर किसी को manage करना पड़े, तो मेरी खास इच्छा नहीं है। बहुत हुआ तो एक सचमुच independent व्यक्ति तक ठीक है।
    • जब मैं join हुआ था, तब मैंने सुना था कि L5 promotion पाने के सबसे आसान तरीकों में से एक manager बनना है। मुझे नहीं पता कि उस समय यह वास्तव में सही था या नहीं, लेकिन हो सकता है कि local optimization के नतीजे में ऐसे managers की संख्या बढ़ी हो। अब लगता है कि L5 पर नए managers बनाए ही नहीं जाते।
    • मैं Googler नहीं हूँ, लेकिन मेरे अनुभव में ऐसे cases में promotions अक्सर इस उम्मीद पर किए गए कि भविष्य में headcount बढ़ेगा। व्यवहार में लोग job change करते रहे या resign करते रहे, इसलिए managed headcount बढ़ने के बजाय उलझता गया।
  • पहले non-technical कर्मचारियों को निकाला जाता है। Google जैसी big tech कंपनियाँ कहती हैं कि coding सबसे महत्वपूर्ण है। फिर वे उन middle managers को निकालती हैं जो coders को manage करते हैं, और फिर भी कहती हैं कि coding महत्वपूर्ण है। उसके बाद वे lower-level managers को हटाती हैं जो हर product के domain experts हुआ करते थे, और फिर भी कहती हैं कि coding पर फोकस करना चाहिए। फिर शायद वे senior engineers को भी निकालेंगे, यह कहकर कि seniors architecture design पर बहुत समय खर्च करते हैं। फिर भी अगर उन्हें यह कम लगे, तो वे सामान्य engineers को भी निकाल देंगे। अंत में सिर्फ ऐसे ‘pure coders’ बचेंगे जिन्हें product की कोई समझ नहीं होगी। और आख़िर में juniors को भी निकालकर सिर्फ Greg नाम का एक आदमी बचेगा, जिसके पास 'webmaster of google dot com' title होगा और वह PHP में पूरे Google को फिर से बना देगा — यही मज़ाक है।
    • सवाल उठता है कि क्या वे अभी भी फल-फूल नहीं रहे हैं?
  • Development teams को manage करना वास्तव में बहुत कठिन काम है। अच्छे managers परिस्थितियों के बावजूद खुद value create करते हैं। बाकी ज़्यादातर लोग environment के हिसाब से खुद को ढाल लेते हैं और ऊपर वालों पर ही ध्यान केंद्रित रखते हैं। नतीजतन वास्तविक value कम होती है और सिर्फ TPS reports नियमित रूप से जमा होती रहती हैं।
  • आजकल executives जिस तरह employees से बात करते हैं, वह बहुत उदास करने वाला है। जब मैं पहले वहाँ था, उसकी तुलना में corporate culture बहुत बदल गया लगता है।
    • 2013 से 2017 के बीच भी corporate culture में बड़ा बदलाव महसूस हुआ था।
    • ऊपर से सड़न शुरू होती है — यह बात बिल्कुल सही लगती है।
  • एक technical team के first-line manager के लिए 5 लोग उचित संख्या लगते हैं। 10 तक पहुँचते ही management लगभग असंभव हो जाती है। Managing एक ऐसा काम है जिसमें समय लगता है। अगर team 10 से बड़ी हो, तो या तो लोग काफी independent और self-directed होने चाहिए, या फिर भरोसेमंद line managers की अतिरिक्त परत चाहिए।
    • मेरे अनुभव में people-to-manager ratio जितना ज़्यादा रहा, उतना बेहतर रहा। जब manager हर चीज़ में शामिल नहीं हो पाता, तो delegation बढ़ता है और अनावश्यक managing कम होती है। सबसे खराब structure वह था जहाँ हर 2~3 लोगों पर एक manager था और उसके ऊपर भी manager था। अंतहीन meetings, साप्ताहिक 1:1, goal setting, तरह-तरह की development training जैसी बेकार चीज़ें बढ़ती चली जाती थीं। Managers अपने role को सही ठहराने के लिए अनावश्यक रूप से व्यस्त दिखते हुए team का समय खा जाते थे।
    • लगभग 5 लोगों की team में रोज़ 30 मिनट standup, शुक्रवार summary meeting, साप्ताहिक 1:1 जैसी job से सीधे जुड़ी न होने वाली गतिविधियाँ अतिरिक्त रूप से जुड़ जाती हैं। अगर 5 लोगों की team को dedicated manager चाहिए, तो इसका मतलब है कि उस group में कोई 'adult' नहीं है।
    • 5 लोगों की team में manager अक्सर अपने अस्तित्व को सही साबित करने के लिए बेकार का काम पैदा करता है।
    • 10 से बड़े teams में लोगों का independent होना ज़रूरी है, और भरोसेमंद line managers भी ज़रूरी होते हैं। जिन Apple hardware teams में मैं था, वहाँ ऐसा ही structure था, और middle-management kingdoms बनने से रोकने के लिए organization को जितना हो सके flat रखा जाता था।
    • मैंने सीधे ऐसे manager के under काम नहीं किया जो सिर्फ 5 लोगों को संभालता हो। Team size के रूप में 5 ठीक लग सकता है, लेकिन manager कई teams साथ संभाले तो भी बड़ी समस्या नहीं होती। Manager को हर व्यक्ति की रोज़मर्रा की गतिविधियों में शामिल होने की ज़रूरत नहीं होती।
  • अब शायद जल्द ही ex-Google PMs अपनी नई jobs में यह कहते हुए शिकायत करेंगे कि “Google में तो ऐसा नहीं होता था”।
    • यह phenomenon तो पहले से ही 10 साल से अधिक समय से चलता आ रहा है।
  • यह तथ्य कि 35% लोग 3 से कम लोगों को manage करते थे, सच में जिज्ञासा पैदा करता है कि ऐसे लोग manager बने ही क्यों। यह title सोच से कहीं अधिक फैला हुआ था — इससे या तो लगता है कि stat ही गलत है, या फिर Google सचमुच बहुत inefficient है।
  • मुझे लगता है big tech कंपनियाँ इसलिए अनावश्यक रूप से फूली हुई हो जाती हैं क्योंकि leadership स्पष्ट vision communicate नहीं कर पाती। यह आसान समस्या नहीं है, लेकिन Apple अब भी Steve Jobs जैसे व्यक्ति की vision की विरासत पर टिका हुआ लगता है।
    • 2018 में Google के बारे में मेरा यही एहसास था। हाल के वर्षों में कुछ सुधार हुआ है और organization कुछ अधिक efficient हुई लगती है, लेकिन CEO अब भी autopilot पर लगता है।
  • लेख का लगभग 2/3 हिस्सा पढ़ने के बाद अचानक page गायब हो गया और footer पर पहुँच गया। वापस ऊपर आया तो सिर्फ title और मुख्य बातें बची थीं, और बहुत बड़ा Taboola ad दिखा। Article provider के लिए यह feedback है कि ऐसा UX अच्छा नहीं है।