يا جماعة الخير، السلام عليكم ورحمة الله.
اسمحولي اليوم أحكيلكم قصة صارت معي قبل كم سنة، قصة عن “خالد”. خالد هاد، يا عمي، مش مبرمج، هاد فنان. الزلمة أصابعه بتعزف على الكيبورد زي السيمفونيات. أي مشكلة معقدة، أي bug “ابن حرام” ما حدا عارفله، كنا نرميه على خالد ويرجعلنا بالحل وهو بيشرب كاسة الشاي تبعته. كان هو الساحر التقني تبعنا، والكل في الفريق بيعرف إنه “إذا الشغلة وصلت لخالد، اعتبرها انحلت”.
وكالعادة، لما يكون عندك شخص بهالتميز، الإدارة بتحب “تكافئه”. وهيك صار، خالد ترقى وصار “Team Lead”. كلنا فرحناله وصفقناله. بس بعد شهرين ثلاثة، لاحظت إشي غريب. خالد بطل يكتب كود. خالد صار يقضي يومه كله من اجتماع لاجتماع. وجهه اللي كان يضوي لما يحل معادلة صعبة، صار مطفي. إنتاجيته البرمجية نزلت للصفر، والأسوأ، إن معنوياته نزلت تحت الصفر.
في يوم شفته قاعد لحاله والموبايل بإيده بس مبين إنه مش معه بالمرة. قعدت جنبه وسألته: “خير يا خالد، مالك؟ مش عاجبني حالك هالكم يوم”. تنهد تنهيدة طويلة وحكالي بصوت مخنوق: “يا أبو عمر، أنا كودر، مش مدير. أنا بحب أحل مشاكل وأبني أنظمة. هسا كل يومي رايح تخطيط وتقارير واجتماعات… زهقت، والله زهقت. حاسس حالي بعاقبوني مش بكافئوني”.
هاي الكلمة “بعاقبوني” ضلت ترن في راسي. هاي هي “الترقية العقابية” بعينها. اللحظة اللي بتخسر فيها أفضل موظف تقني عندك لتحوله لمدير متوسط الأداء (أو حتى سيء) وبائس. ومن هداك اليوم، قررنا نغير كل المنظومة عنا.
الترقية التي تقتل الإنتاجية: مأساة “الترقية العقابية”
المشكلة اللي واجهها خالد مشكلة عالمية في عالم التكنولوجيا. إحنا بنفترض بشكل خاطئ إنه المسار الوظيفي الوحيد للنمو هو الصعود في السلم الإداري. بنشوف مبرمج شاطر، وبنحكي “هاد لازم يصير مدير”. هاد هو ما يسمى بـ “مبدأ بيتر” (The Peter Principle)، اللي بحكي إنه الموظف يظل يترقى حتى يصل إلى منصب هو غير كفؤ فيه، وهناك بيضل ثابت.
الحقيقة المرة هي أن المهارات اللي بتخليك مبرمج عظيم (التركيز العميق، التفكير المنطقي، حب حل الألغاز التقنية) مختلفة تماماً عن المهارات اللي بتخليك مدير عظيم (التواصل، التعاطف، التنظيم، إدارة الناس ومشاكلهم).
لما ترقي أفضل مبرمج عندك ليصير مدير، أنت في الغالب بتخسر أفضل مبرمج عندك، وبتكسب مدير سيء. خسارة مزدوجة!
المساران المتوازيان: كيف نفصل بين الإدارة والقيادة التقنية؟
الحل اللي وصلنا إله ما كان اختراع للذرة، بل هو نموذج معمول فيه في كبرى الشركات التقنية، بس للأسف كثير من شركاتنا بتتجاهله. الحل هو خلق مسارين وظيفيين متوازيين ومحترمين بنفس القدر: المسار الإداري والمسار التقني.
المسار الإداري (Engineering Manager)
هذا المسار للأشخاص اللي عندهم شغف في بناء الفرق وتطوير الأفراد. تركيزهم الأساسي هو على “الناس” و “العمليات”:
- تطوير الأفراد: اجتماعات فردية (1-on-1s)، تقييم الأداء، مساعدة أعضاء الفريق على تحقيق أهدافهم المهنية.
- إدارة المشاريع: التخطيط، توزيع الموارد، التواصل مع الفرق الأخرى، والتأكد من أن المشروع يسير في الطريق الصحيح.
- بناء الفريق: التوظيف، إجراء المقابلات، وخلق بيئة عمل صحية ومنتجة.
نجاح المدير الهندسي يُقاس بنجاح فريقه وسعادته وإنتاجيته، مش بعدد أسطر الكود اللي بيكتبها (واللي المفروض تكون قريبة من الصفر).
المسار التقني (Individual Contributor – IC)
هذا المسار للأشخاص اللي شغفهم هو التكنولوجيا نفسها، مثل صاحبنا خالد. هؤلاء يريدون أن يظلوا قريبين من الكود وأن يحلوا أعقد المشاكل التقنية. هذا المسار لا يتوقف عند “Senior Engineer”، بل يستمر إلى:
- Staff Engineer (مهندس فريق/خبير)
- Principal Engineer (مهندس رئيسي)
- Distinguished Engineer (مهندس متميز)
هؤلاء الأشخاص قيادتهم “تقنية”. نجاحهم يُقاس بالتأثير التقني الذي يحدثونه على مستوى الفريق، القسم، أو حتى الشركة كلها.
إعادة تعريف “المهندس القائد”: بطل الكود، لا سجين الاجتماعات
هنا يكمن الحل لمشكلة خالد. بدل ما نحبسه في قفص الإدارة، خلقنا له دور جديد ومسمى جديد يتناسب مع قدراته وشغفه: المهندس الرئيسي (Principal Engineer). هذا الدور ليس دوراً إدارياً، بل هو أعلى مرتبة في المسار التقني.
ماذا يفعل المهندس القائد (Lead/Principal Engineer)؟
المهندس القائد هو “الختيار” الحكيم تبع الفريق من الناحية التقنية. هو المرجعية اللي الكل بيرجعلها في الأمور الصعبة. مسؤولياته تشمل:
- التوجيه والإرشاد (Mentoring): هو الأب الروحي للمبرمجين الجدد. “بقعد مع الشباب وبورجيهم كيف الشغل الصح”. يراجع أكوادهم، يعلمهم أفضل الممارسات، ويساعدهم على النمو التقني.
- بنية الأنظمة (Architecture): هو من يصمم الهياكل الأساسية للمشاريع الكبيرة. يفكر في التوسع (Scalability)، والأمان، والصيانة على المدى الطويل قبل أن يُكتب سطر كود واحد.
- حل المشاكل العويصة: هو الشخص الذي يتصدى للمشاكل التقنية الأكثر تعقيداً وغموضاً، تلك التي قد تشل حركة الفريق بأكمله.
- حارس جودة الكود: يضع معايير الجودة للكود، الاختبارات، وعمليات النشر (CI/CD). قد يقترح ويطبق أدوات أو منهجيات جديدة ترفع من المستوى التقني للفريق كله.
- الناطق التقني: يمثل الفريق في النقاشات التقنية المعقدة مع الفرق الأخرى. هو هناك ليتحدث في صلب التكنولوجيا، لا في الجداول الزمنية والميزانيات.
للتوضيح، شوفوا هذا المثال البسيط لتوزيع المسؤوليات:
// مثال على توزيع المسؤوليات
// Engineering Manager (المدير الهندسي)
- One-on-ones (اجتماعات فردية)
- Performance reviews (تقييم الأداء)
- Career growth planning (تخطيط المسار الوظيفي)
- Hiring & team building (التوظيف وبناء الفريق)
- Project timelines & budget (الجداول الزمنية والميزانية)
// Principal Engineer (المهندس القائد/الرئيسي)
- System architecture design (تصميم بنية الأنظمة)
- Mentoring junior engineers (توجيه المهندسين الجدد)
- Code reviews for critical modules (مراجعة كود الوحدات الحرجة)
- R&D on new technologies (بحث وتطوير تقنيات جديدة)
- Solving the hardest technical bugs (حل أعقد المشاكل التقنية)
نصائح من “الختيار”: كيف تطبق هذا النموذج في فريقك؟
إذا أعجبك هذا الكلام وتريد تطبيقه، إليك بعض النصائح العملية من خبرتي:
- تكلم مع فريقك: اجلس مع كبار المبرمجين عندك واسألهم بصراحة: “وين شايف حالك بعد خمس سنين؟ بتحب تدير فريق ولا بتحب تبني أعقد نظام في الشركة؟”. الإجابة ستفاجئك.
- أنشئ مسارات وظيفية واضحة: اكتبها! وثّق المسارين (الإداري والتقني). حدد المسؤوليات والتوقعات والرواتب لكل مستوى. يجب أن يكون واضحاً للجميع أن راتب “المهندس الرئيسي” يمكن أن يساوي أو حتى يفوق راتب “المدير الهندسي”. القيمة متساوية.
- أعد تعريف “القيادة”: القيادة ليست فقط إدارة الأفراد. المهندس الذي يقود مبادرة تقنية معقدة تؤثر على الشركة بأكملها هو قائد. القيادة بالتأثير والنفوذ التقني، لا بالسلطة الإدارية.
- فرق بين الأدوار والمناصب: قد يكون لديك “Tech Lead” لمشروع معين، وهو دور مؤقت يتولاه مهندس خبير لقيادة الجانب التقني للمشروع. هذا مختلف عن منصب “Engineering Manager” الدائم والمسؤول عن الأفراد.
الخلاصة: حرروا أفضل مبرمجيكم! 🚀
القصة انتهت نهاية سعيدة. بعد أن استحدثنا منصب “المهندس الرئيسي” لخالد، الرجل ازدهر. عاد الشغف إلى عينيه، وعادت أصابعه لتعزف على الكيبورد. أصبح تأثيره أضعافاً مضاعفة، ليس فقط من خلال الكود الذي يكتبه، بل من خلال رفعه للمستوى التقني للفريق بأكمله عبر توجيهه وإرشاده. لقد أنقذنا أفضل مبرمجينا، وبذلك، أصبح فريقنا كله أقوى.
نصيحتي الأخيرة لكل مدير وصاحب شركة: لا تعاقبوا المبدعين بالترقيات الإدارية. لا تطفئوا شعلتهم بحشو أيامهم بالاجتماعات والتقارير. ابنوا لهم مساراً يمكنهم من خلاله النمو والتألق في مجالهم الذي يحبونه.
اسمعوا من مبرمجيكم، أعطوهم المساحة ليبدعوا، وشوفوا العجب. 😉
