[Arabic] How can you plan for scaling Engineering Teams?

يا ترى لو جاتلك الفرصة انه يتطلب منك تكبّر التيم اللي أنت شغال فيه، هتعرف تعمل كده؟ ايه الأفكار اللي ممكن تيجي في بالك؟ - تعالوا نفترض سيناريو انك شغال في تيم جامد فيه ٦، والشغل ابتدى يزيد وهتحتاجوا ناس أكتر، مديرك قالك خلاص احنا هنـhire ٦ كمان، بس قوللي أحسن setup للتيم

هتبدأ تفكر في أحسن طريقة للـscaling، وهتقرا شوية كويسين .. غالبًا هتلاقي طرق كتير الشركات بتهندل بيها موضوع الـgrowth وفيه قصص كتير عن إزاي تكبر من شركة فيها ١٠ لـ١٠٠ في كام شهر، صعب جدًا صح؟ الحقيقة أيوا، وفيه كتب اتعملت خصيصًا للموضوع ده .. بس خلينا في التيم بتاعنا دلوقتي

فيه طبعًا أساليب كتير للتنفيذ وبتعتمد على عوامل كتير جدًا زي خبرة التيم الموجود. صعوبة أو سهولة الشغل، كيفية تأثير الـonboarding على إنتاجية التيم ومدى خطورته على أي deadline متفقين عليه .. بس عمومًا فيه ٣ أساليب هما الأكتر منطقية في حالتنا دي .. وانا متأكد انك شوفتهم قبل كده

مبدئيًا خلينا نتفق انه ٦ ده عدد أفراد ممتاز لأي تيم، و ١٢ هو رقم صعب يستحسن اننا نتجنبه، وبالتالي هتضطر تقسم التيم على حسب ما هتقدر تقسّم طلبات الـproduct/business لشوية حاجات ينفع تبقى مستقلة وممكن كل تيم يشتغل عليها لوحده ويبقى independent عن الباقي - لنفترض انكم نجحتم في كده

الخطوة التانية، هتقسّم التيم ازاي والأهم: أمتى؟ الطريقة الأولي ممكن نسميها Split and Add: هنا التيم هيتقسم لاتنين، كل تيم فيه ٣، وهيبقى دور كل تيم انه يفهم كويس هيشتغل في ايه تحديدًا، ويحضر onboarding materials للناس الجديدة اللي هيبقوا ٣ برضه - هيبقى كده التيم فيه ٦

الطريقة دي بتدي فرصة للتيم انه يكبر بشكل هادي ،هنبقى متوقعين كمان إنتاجية أبطأ من المعتاد من الـ٣ القدام علشان التحضير وبعدها مساعدة الناس الجديدة - عيوب الطريقة دي إنها بتاخد وقت على ما نتيجتها تظهر، وممكن البيزنس يبقى معندوش رفاهية الوقت ده ..

الطريقة التانية هي Add then Split: هناخد ريسك انه هيحصل شوية فوضى ولخبطة في الـcommunication بين التيم بسبب اننا هنقرر نكبّر التيم لفترة بسيطة ويبقى ١٢ شخص .. هناخد الوقت ده ونعتمد على خبرة اللي موجودين ومديرهم انهم يساعدوا الناس الجديدة تندمج بسرعة وتتابعهم بشكل يومي

بعدها هنقسّم التيم لـ٢ أو ٣ على حسب المطلوب، وكده هيبقى التيمز كلها فاهمة البيزنس والدومين وبنشتغل ازاي .. الأسلوب ده بيعتمد على خبرة التيم القديم وشطارته انه يفضل productive وسط الزحمة اللي هتحصل، وصعب ينجح لو التيم معظمه Jr. or mid-level، وقتها التيم هيعطل او يبقى frustrated

الأسلوب التالت وهو Sink or Swim: الحقيقة أنه أشهرهم وأصعبهم بس هتلاقيه كتير في corporates، وهو انك هتبني التيم الجديد كله ١٠٠٪ بالناس الجديدة، وهتديهم وقتهم انهم يفهموا ويتعودوا على business, culture, and technical stack، وزي ما الإسم موضّح: يا هيعرفوا يتعاملوا يا هيغرقوا

الأسلوب ده محتاج وقت ومفيش استعجال ولا أي commitment على التيم ده لأنه هيبقى ريسك، ومحتاج الناس الجديدة تبقى بتعرف تتصرف لوحدها، لأنها هتعطل كتير لو محدش متاح انه يساعد، الأسلوب ده ناجح في الـenvironments اللي مش بتتحرك بسرعة وبتاخد وقت في التخطيط، ونادرًا ما تلاقيه في startup

يا ترى هتختار أي أسلوب؟ بالنسبة لي جربت الـ٣ وكلهم بيعتمدوا على المكان وطبيعة البيزنس والشركة والتوقعات .. أقدر أقول انه الأسلوب الأول أقل ريسك فيهم، الأسلوب التاني أحسنهم بس محتاج تيم تقيل وتاخد بالك من تفاصيل كتير بس نتايجه مبهرة .. الأسلوب التالت محتاج ظروف كتير علشان ينجح

فيه طرق تانية زي انك تاخد واحد بس يكون superstar وتبني حوليه التيم الجديد، فيه انك تعمل التيم backward من البيزنس، يعني يبقى التيم فيه مثلاً testing engineer and product owner عارفين البيزنس علشان يساعدوهم وتخلّي التيم يغرق في التفاصيل التكنيكال لوحده، الأوبشنز كتير زي ما قلنا

💡 تقدروا تلاقوا تفاصيل ومناقشات أكتر حول الموضوع ده في الـthread ده على twitter، شكرًا ..