ثمة استعارة من الرياضات الجماعية أستخدمها منذ سنوات لوصف أسلوب قيادتي: Playing Captain — الكابتن اللاعب. اللاعب الذي يرتدي الشارة أيضاً. ليس المدرب في المقعد البديل، وليس المساهم الفردي البحت الذي يطحن الزوايا — بل الشخص الذي يرسم الخط ثم يركض معه مع الفريق.
أعرف أن قول “أستخدم استعارة رياضية” اعتراف يمكن أن يكون محرجاً قليلاً في تدوينة. أتقبّل ذلك. إنها أدق إطار وجدته.
ما تعنيه فعلاً
Playing Captain وضع قيادة محدد. إنه ليس “أنا قائد تقني يحضر بعض اجتماعات المعمارية.” وليس “أنا نائب رئيس هندسة يكتب بعض الكود للبقاء على صلة.” إنه أقرب إلى: ما زلت بشكل ملموس في قاعدة الكود. أتخذ قرارات معمارية ليس من مستند على مسافة أمان بل من نفس callstack الذي يُصحّح فيه الفريق. أُزاوج وأُراجع وأكتب ميزات غير تافهة وألتقط مشاكل التصميم قبل أن تصبح ندمات ترحيل.
في الوقت نفسه، أقوم بعمل القيادة: تشكيل خارطة الطريق، وإزالة العوائق، وتنمية المهندسين من حولي، وإدارة المحادثات عبر الفرق.
الهدف — وهذا الجزء الذي يبدو مثالياً لكنني رأيته يعمل — هو أن يستطيع الفريق التنفيذ باستقلالية لأن المعمارية نظيفة وموضّحة جيداً، لا لأنني في كل اجتماع أوافق على القرارات. Playing Captain هو كيف تتجنب كلا نمطَي الفشل: القائد التقني الغائب الذي لا يعرف لماذا الخدمة بطيئة، والمهندس العملاني الذي لن يدع أحداً يتخذ قراراً.
كيف يبدو هذا مع 12 شخصاً مقابل 3
في AFAQ كنت مديراً تقنياً لفريق من 12 شخصاً. هذا صغير بما يكفي لأكتب كود إنتاج بموعد، وكبير بما يكفي لدي أشخاص أحميهم من التعقيد، وخارطة طريق أملكها، ومجلس يريد تحديثات يجب أن تكون لي آراء بشأنها. Playing Captain في ذلك الحجم يعني أنك فعلاً الصوت التقني الأكبر في معظم الغرف، وتستخدم ذلك للتحرك بسرعة — تتخذ القرار الصعب بشأن schema قاعدة البيانات لأن انتظار الإجماع أبطأ من أن تكون مخطئاً أحياناً وتُصلح.
في Bytro كنت Lead Developer في جهد تحديث متعدد الفرق. نسيج مختلف. كان للفريق بالفعل مهندسون كبار؛ لم تكن مهمتي أن أكون أسرع من يكتب كوداً، بل أن أملك الرؤية المعمارية عبر فرق كانت تتحرك بالتوازي ويمكنها خلاف ذلك إنشاء أربعة تجريدات غير متوافقة لنفس مفهوم الدومين. بقيت في الكود لأعرف أي التجريدات تصمد وأيها على وشك الانهيار. لا تستطيع فعل ذلك من مستند Confluence.
في auxmoney كانت منصة تقييم الائتمان تمتلك من التعقيد — ومن التسارع — ما جعل العمل العملاني لا نوستالجيا للمساهمة الفردية، بل الطريقة الوحيدة التي أستطيع بها تقديم إرشاد تقني مفيد. تستطيع شمّ مشكلة latency في الطبقة الخاطئة حين كنت تتتبع نفس مسار الطلب الذي يتتبعه الفريق. لا تستطيع شمّها من لوحة Jira.
الحجة المضادة، مُقوَّية
“مديرو الهندسة يجب أن يتوقفوا عن البرمجة” نصيحة حقيقية، من أشخاص حقيقيين رأوا ضرراً حقيقياً. رأيت النمط الذي تصفه: المهندس الكبير الذي رُقِّي ويحجب الآن كل مراجعة تصميم لأنه لا يزال يرى نفسه أفضل من يكتب كوداً في الغرفة. الذي يأخذ التذاكر الممتعة. الذي يجعل كل مراجعة كود عن تفضيلاته الجمالية ولا يشعر أحد بملكية قاعدة الكود إلا هو.
هذا ليس Playing Captain. هذا Playing Captain بشكل سيء.
نمط الفشل حقيقي. العلاج ليس التوقف عن البرمجة؛ العلاج هو البرمجة في خدمة الفريق. اسحب التذكرة المخيفة التي يتجنبها الجميع لأن نطاق التأثير كبير، لا التذكرة الممتعة لأنك تريد شحن شيء. راجع معمارياً لا أسلوبياً. زاوج لنقل المعرفة، لا لمشاهدة نفسك تكون مفيداً.
نصيحة “التوقف عن البرمجة” مُضبَّطة أيضاً لشكل فريق محدد — عادةً منظمة كبيرة حيث رافعتك هي كثافة الناس والعملية وسلاسل التفويض. مع 5-15 مهندساً، خاصةً في startup أو مشروع تحديث، هذا الشكل خاطئ. لا تحسّن للعملية؛ تحسّن للتماسك المعماري والتسارع. المصداقية التقنية ليست ميزة حسنة لـPlaying Captain — إنها الأساس كله.
متى يكون Playing Captain خياراً خاطئاً
مارست Playing Captain لوقت طويل كافٍ لأعرف متى يكون خاطئاً.
إذا كنت في 80 مهندساً وتنمو، يبدأ Playing Captain في التراكم السيء. يحتاج الفريق وجودك في الغرف متعددة الوظائف بدوام كامل؛ كل ساعة في مراجعة كود هي ساعة غير مُنفَقة على المشاكل التنظيمية التي تتراكم بشكل أسرع من التقنية. لديك أشخاص يستطيعون حمل الرؤية المعمارية — ربما يحتاجون منك المزيد من توجيه الاتجاه، لا المزيد من جلسات المزاوجة.
إنه أيضاً خاطئ إذا كنت تستخدمه لتجنب الأجزاء من القيادة التي تجدها مزعجة. ضبطت نفسي أمدّ يدي نحو مشكلة تقنية صعبة كنشاط إزاحي حين كانت هناك محادثة أداء كنت أسحبها. هذا ليس Playing Captain. هذا استخدام الكود كبطانية وقاية. الكابتن ما زال يجب أن يقوم بالعمل الشخصي الصعب؛ الكود ليس عذراً.
ما يصيبه بشكل صحيح
ما يصيبه Playing Captain بشكل صحيح هو حلقة الـfeedback. حين تكون في قاعدة الكود، تعرف حين تتسرب المعمارية قبل أن يخبرك الفريق. تعرف أي مهندس يحمل تعقيداً كثيراً في رأسه لأنك رأيت الـPR الذي يُنتجه. تعرف متى حد الخدمة خاطئ لأنك كنت على جانبَي التجريد.
القيادة التقنية الإدارية فقط لديها مشكلة latency. تتلقى معلومات مصفّاة عبر اجتماعات وretros وأشخاص (بشكل صحيح) لا يريدون إحضار كل شيء صغير إليك. بحلول وقت ظهور مشكلة ما كمشكلة، كانت مشكلة لأسابيع.
Playing Captain يضغط تلك الـlatency. الـfeedback من الكود يصلك بسرعة لأنك تقرأ الكود. تستطيع تصحيح المسار مبكراً، مما يعني أنك لا تضطر لتصحيحه بشكل كبير.
مارست هذا عبر أربع شركات، وثلاثة stacks تقنية مختلفة، وأحجام فرق من 4 إلى 30. إنها ليست نظرية شاملة للقيادة التقنية. إنها النظرية التي نجحت بالنسبة لي، وشكل الفرق التي كنت أكثر فائدة بها. الشارة تأتي بمسؤولية. الأحذية تظل على القدمين.