كنا نخسر أفضل مهندسينا: كيف أنقذنا ‘المسار الوظيفي المزدوج’ من جحيم ‘إما مدير أو لا شيء’؟

قصة “سامر”: الساحر الذي كره العرش

بتذكر منيح “سامر”، شب زي الوردة، كان من أمهر المبرمجين اللي مرقوا عليّ في مسيرتي. لما كان يكتب كود، كنت تحس إنه برسم لوحة فنية، مش مجرد سطور وأوامر. كان عنده قدرة عجيبة على حل المشاكل المستعصية اللي الفرق كلها بتستسلم عندها. كنا نسميه بيناتنا “الساحر”.

بعد سنتين من الإبداع الخارق، قررت الإدارة “تكافئه”. والمكافأة، طبعاً، كانت منصب “قائد فريق” (Team Lead). فرحنا لسامر، وباركنا له، وهو قبل المنصب على مضض، يمكن من باب الحياء أو لأنه حس إنه هاد هو “التقدم الطبيعي” في أي شركة.

وهنا بدأت الكارثة. “الساحر” اللي كان يقضي 8 ساعات في حالة من التركيز العميق والإبداع، صار يقضي وقته في اجتماعات لا تنتهي، وتحديث جداول بيانات، ومتابعة إجازات الموظفين، وحل المشاكل الشخصية بينهم. الكود اللي كان عشقه تحول لذاكرة بعيدة. وجهه اللي كان يضوي لما يحل مشكلة تقنية، صار باهت ومطفي. أداؤه كمدير كان متوسطاً في أحسن الأحوال، لكن أداءه كمبرمج صار صفراً. خسرنا “الساحر”، وكسبنا مديراً تعيساً.

بعد أقل من سنة، استقال سامر. راح لشركة ثانية أعطته لقب “Principal Engineer” وراتب أعلى، وطلبت منه طلب واحد: “ارجع اعمل سحرك”.

هذيك الحادثة، يا جماعة الخير، كانت زي الكف اللي صحّانا. أدركنا إنه سياستنا في “الترقية” كانت بتقتل أفضل مواهبنا. كنا بنخسر “زلم الشغل الصح” لإننا بنجبرهم يقعدوا على كرسي ما بدهم إياه ولا بناسبهم. كان لازم نلاقي حل، وإلا رح نضل في هالجحيم: “إما مدير أو لا شيء”.

جحيم “إما مدير أو لا شيء”: تشخيص المشكلة

المشكلة اللي واجهناها مع سامر ليست حالة فردية، بل هي عَرَض لمرض متجذر في هيكلية الشركات التقليدية. السلم الوظيفي التقليدي يشبه هرماً واحداً: تبدأ كموظف صغير، وتصعد درجة تلو الأخرى، وكلما صعدت، زادت مسؤولياتك الإدارية. القمة الوحيدة المتاحة هي منصب إداري بحت.

لماذا هذا النموذج كارثي للمجال التقني؟

  • إهدار المواهب: يجبر هذا النموذج أفضل العقول التقنية على التخلي عن شغفهم ومهارتهم الأساسية (كتابة الكود، تصميم الأنظمة) من أجل الحصول على ترقية وزيادة في الراتب.
  • خسارة مزدوجة: كما يقول المثل، “عندما ترقي مهندساً عظيماً ليصبح مديراً، فإنك تخسر مهندساً عظيماً وتكسب مديراً سيئاً”. الشركة تخسر من جهتين.
  • مبدأ بيتر (The Peter Principle): ينص هذا المبدأ الإداري على أن الموظفين يميلون إلى الترقية حتى يصلوا إلى “مستوى عدم كفاءتهم”. المهندس الشاطر ليس بالضرورة مديراً شاطراً؛ المهارات مختلفة تماماً.
  • خلق بيئة عمل سامة: المدير الذي لا يستمتع بدوره سيصبح محبطاً، وهذا الإحباط سينتقل حتماً إلى فريقه، مما يؤثر على الروح المعنوية والإنتاجية.

المنقذ: المسار الوظيفي المزدوج (Dual Career Path)

بعد حادثة سامر وبحث طويل، وجدنا الحل في مفهوم إداري حديث نسبياً يُعرف بـ “المسار الوظيفي المزدوج”. الفكرة بسيطة في جوهرها لكنها ثورية في تطبيقها: بدلاً من سلم واحد، نقوم بإنشاء سلمين وظيفيين متوازيين ومتساويين في القيمة والأهمية.

المسار الأول: المسار الإداري (Management Track)

هذا هو المسار التقليدي، وهو مخصص للأشخاص الذين يجدون شغفهم في قيادة الناس وتطويرهم وتحقيق الأهداف من خلال الفريق. المهارات المطلوبة هنا هي التواصل، التعاطف، التخطيط الاستراتيجي، إدارة المشاريع، وتنمية المواهب.

أمثلة على الألقاب:

  • Team Lead (قائد فريق)
  • Engineering Manager (مدير هندسي)
  • Director of Engineering (مدير قسم الهندسة)
  • VP of Engineering (نائب رئيس قسم الهندسة)

المسار الثاني: المسار الفردي/التقني (Individual Contributor – IC Track)

هذا هو المسار الجديد الذي أنقذنا. إنه مخصص للخبراء التقنيين الذين يريدون أن ينموا ويتطوروا ويتركوا بصمة هائلة في الشركة من خلال خبرتهم التقنية العميقة، دون الحاجة لإدارة الناس بشكل مباشر.

أمثلة على الألقاب:

  • Senior Engineer (مهندس أول)
  • Staff Engineer (مهندس خبير)
  • Principal Engineer (مهندس رئيسي)
  • Distinguished Engineer / Fellow (مهندس متميز / زميل)

الأهم في هذا النموذج هو أن المسارين متوازيان. هذا يعني أن الرواتب، والمكانة، والتأثير في القرارات الاستراتيجية يجب أن تكون متكافئة. راتب الـ Principal Engineer يجب أن يكون في نفس مستوى راتب الـ Engineering Director، وصوته في القرارات التقنية يجب أن يكون مسموعاً ومحترماً بنفس القدر.

كيف تبدو المسارات على أرض الواقع؟ (مقارنة عملية)

لنفهم الفرق بشكل أعمق، دعونا نقارن بين دورين متكافئين على السلمين: المدير الهندسي (Engineering Manager) والمهندس الرئيسي (Principal Engineer).

الجانب المدير الهندسي (Management Track) المهندس الرئيسي (IC Track)
التركيز الأساسي قيادة وتطوير الناس. يركز على “من” و “كيف” يتم تنفيذ العمل. قيادة وتطوير التقنية. يركز على “ماذا” و “لماذا” نبني.
مقياس النجاح نجاح الفريق، تسليم المشاريع، نمو أعضاء الفريق. جودة التصميم التقني، قابلية التوسع، حل أعقد المشاكل، التأثير التقني على مستوى الشركة.
توزيع الوقت (تقريبي) 70% اجتماعات وتواصل، 20% تخطيط، 10% مراجعات تقنية. 50% كتابة كود وبناء نماذج أولية، 30% تصميم ومراجعات تقنية، 20% توجيه وتواصل.
نطاق التأثير يؤثر بشكل عميق على فريقه (5-10 أشخاص). يؤثر بشكل واسع على عدة فرق أو على قسم كامل من خلال القرارات المعمارية والتقنية.

نصائح من “أبو عمر” لتطبيق المسار المزدوج بنجاح

تطبيق هذا النموذج ليس مجرد رسم مخطط جديد على الورق. يتطلب الأمر تغييراً حقيقياً في ثقافة الشركة. من خبرتي، هذه أهم النقاط لضمان نجاحه:

1. اجعل المسارين متساويين حقاً (وليس بالاسم فقط)

هذه هي النقطة الأهم. إذا كان المسار التقني يُعتبر “درجة ثانية” من حيث الراتب أو الاحترام، فسيفشل النموذج. يجب أن يكون للمهندس الرئيسي (Principal Engineer) نفس التأثير والراتب والتقدير الذي يحصل عليه المدير. يجب أن يُدعى للاجتماعات الاستراتيجية، ويجب أن يؤخذ رأيه التقني بجدية مطلقة.

2. ضع معايير واضحة للترقية في كل مسار

يجب أن تكون متطلبات الترقية في مسار الـ IC واضحة ومحددة. الانتقال من Senior إلى Staff Engineer لا يعني فقط أنك تكتب كوداً أفضل. بل يعني أن نطاق تأثيرك قد اتسع. مثلاً، من معايير الترقية لـ Staff Engineer:

  • القدرة على قيادة مشاريع تقنية معقدة تمتد عبر عدة فرق.
  • توجيه (Mentoring) عدد من المهندسين الأقل خبرة.
  • تحسين المعايير التقنية والممارسات الهندسية في القسم.
  • امتلاك نظام أو جزء حرج من البنية التحتية للشركة.

3. اسمح بالحركة المرنة بين المسارين

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

4. ابدأ صغيراً ثم توسّع

لست بحاجة لبناء هيكل من 10 مستويات لكل مسار من اليوم الأول. يمكنك البدء بتعريف منصب واحد رفيع في المسار التقني (مثل Staff Engineer) كبديل لمنصب قائد الفريق (Team Lead). راقب كيف تسير الأمور، اجمع الملاحظات، ثم قم ببناء بقية المستويات تدريجياً.

الخلاصة: لا تخسروا “سامر” مرة أخرى! 💡

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

لما تعطي المبرمج المبدع مساحة ليبدع في مجاله اللي بحبه، ولما تعطي القائد الفطري فرصة ليقود الناس، بتكون كسبت ولاء الاثنين، وبنيت فريقاً لا يُقهر. وهاد يا جماعة الخير، أغلى من أي راتب أو منصب.

الله يوفق الجميع في مساراتهم اللي بختاروها.

أبو عمر

سجل دخولك لعمل نقاش تفاعلي

كافة المحادثات خاصة ولا يتم عرضها على الموقع نهائياً

آراء من النقاشات

لا توجد آراء منشورة بعد. كن أول من يشارك رأيه!

آخر المدونات

التوظيف وبناء الهوية التقنية

كان ملفي على GitHub مقبرة للمشاريع: كيف أنقذتني المصادر المفتوحة من جحيم “ليس لديك خبرة عملية”؟

هل ملفك على GitHub مليء بالمشاريع غير المكتملة؟ في هذه المقالة، أشارككم تجربتي الشخصية كأبو عمر، وكيف حولتني المساهمة في المصادر المفتوحة من مبرمج يواجه...

26 مايو، 2026 قراءة المزيد
التوسع والأداء العالي والأحمال

خدماتنا كانت تنتظر في طابور طويل: كيف أنقذتنا ‘طوابير الرسائل’ من جحيم ‘الرجاء الانتظار’؟

أشارككم قصة حقيقية من تجربتي كمبرمج، وكيف كاد مشروعنا أن يفشل بسبب بطء الاستجابة. اكتشفوا معنا كيف غيّرت "طوابير الرسائل" (Message Queues) طريقة عملنا، وحوّلت...

26 مايو، 2026 قراءة المزيد
التكنلوجيا المالية Fintech

من كابوس “أرسل هويتك مجدداً” إلى التحقق الفوري: كيف أنقذنا الذكاء الاصطناعي في عالم الـFintech

كان التحقق من هوية العميل (KYC) عملية يدوية مرهقة تسببت في إحباط العملاء والموظفين. في هذه المقالة، أسرد لكم قصة واقعية من تجربتي كمطور وكيف...

26 مايو، 2026 قراءة المزيد
البنية التحتية وإدارة السيرفرات

كانت تطبيقاتنا تموت بصمت في الليل: كيف أنقذنا Kubernetes من جحيم ‘إعادة التشغيل اليدوية’؟

أشارككم قصتي كـ"أبو عمر"، مبرمج فلسطيني، وكيف انتقلنا من ليالي الرعب وإعادة تشغيل السيرفرات يدوياً إلى عالم الأتمتة والشفاء الذاتي للتطبيقات باستخدام Kubernetes. مقالة عملية...

26 مايو، 2026 قراءة المزيد
ادارة الفرق والتنمية البشرية

كان كل خطأ كارثة شخصية: كيف أنقذتنا ‘السلامة النفسية’ من جحيم ‘إخفاء الأخطاء’؟

أنا أبو عمر، مبرمج فلسطيني، وأروي لكم كيف انتقلنا من بيئة عمل كان فيها الخطأ البرمجي وصمة عار، إلى ثقافة "السلامة النفسية" التي حولت الأخطاء...

26 مايو، 2026 قراءة المزيد
اختبارات الاداء والجودة

كان إطلاقنا رهاناً محفوفاً بالمخاطر: كيف أنقذتنا اختبارات التحمل (Load Testing) من جحيم ‘هل سيصمد الخادم؟’

أشارككم قصة حقيقية من قلب المعركة التقنية، حيث كان إطلاق منتجنا الجديد على المحك. لولا اختبارات التحمل (Load Testing) وأدوات مثل k6، لكنا غرقنا في...

26 مايو، 2026 قراءة المزيد
أتمتة العمليات

كانت خطوط بياناتنا هشة وتعمل بالدعاء: كيف أنقذنا Apache Airflow من جحيم ‘شغّل هذا السكريبت يدوياً’؟

أشارككم قصة حقيقية من قلب المعاناة مع خطوط البيانات اليدوية، وكيف كانت أداة Apache Airflow هي المنقذ الذي نقلنا من فوضى تشغيل السكريبتات يدوياً إلى...

26 مايو، 2026 قراءة المزيد
البودكاست