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

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

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

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

المشكلة الكلاسيكية: السلم الوظيفي ذو الاتجاه الواحد

في معظم الشركات، المسار الوظيفي للمهندس واضح ومحدد مسبقاً: تبدأ كـ Junior Developer، ثم Mid-level، ثم Senior. وبعدها؟ الطريق الوحيد “للأعلى” هو التحول إلى منصب إداري: Team Lead, Engineering Manager, وهكذا. هذا النموذج، الذي قد يبدو منطقياً على الورق، هو كارثة صامتة في عالم هندسة البرمجيات.

لماذا؟

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

“إجبار أفضل لاعب لديك على أن يصبح مدرباً قد يجعلك تخسر أفضل لاعب وأسوأ مدرب في صفقة واحدة.”

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

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

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

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

  • الألقاب: Engineering Manager, Director of Engineering, VP of Engineering.
  • التركيز: الناس، العمليات، الاستراتيجية.

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

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

  • الألقاب: Senior Engineer, Staff Engineer, Principal Engineer, Distinguished Engineer.
  • التركيز: التقنية، المعمارية، الابتكار.

كيف طبقنا هذا النظام خطوة بخطوة؟

الفكرة جميلة، لكن “اللي إيدو في المي مش زي اللي إيدو في النار”. التطبيق كان هو التحدي الحقيقي. إليكم الخطوات العملية التي اتبعناها:

الخطوة الأولى: الاعتراف والاستماع

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

الخطوة الثانية: تصميم الهيكل وتحديد الكفاءات

جلسنا، فريق الإدارة مع ممثلين عن كبار المهندسين، ورسمنا الهيكل الجديد. كان الهدف الأسمى هو تحقيق “التكافؤ”. أي أن يكون لمنصب “Principal Engineer” نفس الوزن والمكانة والراتب لمنصب “Director of Engineering”.

استخدمنا مصفوفة كفاءات (Competency Matrix) لتوضيح التوقعات في كل مستوى. هذا مثال مبسط جداً لكيفية تنظيمها:


# مثال توضيحي لهيكل المسارات والمستويات

levels:
  - level: L3
    title: Software Engineer II
    track: IC
    
  - level: L4
    ic_track:
      title: Senior Software Engineer
      focus: قيادة المشاريع الصغيرة، توجيه المبتدئين، خبرة عميقة في مجال واحد.
    management_track:
      title: Engineering Manager I
      focus: إدارة فريق (3-5 أشخاص)، تخطيط المشاريع، تطوير الأفراد.

  - level: L5
    ic_track:
      title: Staff Engineer
      focus: قيادة مشاريع معقدة عبر عدة فرق، التأثير على استراتيجية القسم التقنية.
    management_track:
      title: Engineering Manager II
      focus: إدارة عدة فرق أو فريق كبير، المشاركة في التوظيف ووضع الأهداف.

  - level: L6
    ic_track:
      title: Principal Engineer
      focus: حل المشاكل التقنية على مستوى الشركة، ابتكار تقنيات جديدة، توجيه كبار المهندسين.
    management_track:
      title: Director of Engineering
      focus: إدارة قسم كامل، وضع الاستراتيجية طويلة الأمد، إدارة الميزانيات.

لاحظ كيف أن “القيادة” لها معنى مختلف في كل مسار. في المسار الإداري، هي قيادة أفراد. في مسار الـ IC، هي قيادة تقنية وفكرية.

الخطوة الثالثة: المساواة في الأجور والمكانة

هذه هي النقطة الأهم. إذا كان راتب المدير أعلى بكثير من راتب المهندس الخبير في نفس المستوى، فسيفشل النظام بأكمله. يجب أن تكون نطاقات الرواتب (Salary Bands) متداخلة ومتساوية للمستويات المتقابلة. المكانة أيضاً مهمة. يجب دعوة الـ Principal Engineers لاجتماعات الاستراتيجية التقنية، ويجب أن يكون لهم صوت مسموع ومؤثر تماماً مثل المدراء.

الخطوة الرابعة: المرونة في التنقل

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

نصائح عملية من “أبو عمر”

بعد تطبيق هذا النظام لسنوات، تعلمت بعض الدروس التي لا تجدها في الكتب:

  • لا تجعلها مجرد وثيقة: يجب أن تؤمن الإدارة العليا بهذا النظام وتدعمه علناً. احتفل بترقية مهندس إلى “Staff Engineer” بنفس الحماس الذي تحتفل به بترقية مدير جديد. الثقافة هي التي تنجح النظام، وليس الورق.
  • التقييم يجب أن يكون شفافاً: يجب أن تكون معايير الترقية في كلا المسارين واضحة ومحددة وقابلة للقياس قدر الإمكان. هذا يزيل الغموض ويمنح الجميع هدفاً واضحاً للعمل من أجله.
  • ابدأ صغيراً: لا تحتاج إلى تصميم نظام من 10 مستويات من اليوم الأول. ابدأ بـ 4 أو 5 مستويات واضحة تغطي غالبية فريقك، ثم قم بتطويره وتحسينه مع مرور الوقت بناءً على التجربة والملاحظات.
  • دور الـ “Staff+” ليس مجرد “مبرمج خارق”: مهندسو المستويات العليا في مسار الـ IC ليسوا مجرد مبرمجين أسرع. دورهم يتضمن التوجيه، والكتابة التقنية، وتحسين العمليات، والتأثير على نطاق أوسع. هم “مضاعِفو القوة” (Force Multipliers) للفرق من حولهم.

الخلاصة: استثمار في أغلى أصولك 💡

ماذا حدث لـ “سامر”؟ بعد تطبيق النظام الجديد، أصبح أول “Staff Engineer” لدينا. قاد مشروع إعادة هيكلة قاعدة البيانات الذي كان يؤرقنا لسنوات، وخفّض زمن الاستجابة بنسبة 70%. أصبح مرجعاً تقنياً للجميع، والأهم من ذلك، عاد شغفه وحماسه أقوى من أي وقت مضى.

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

أبو عمر

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

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

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

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

آخر المدونات

برمجة وقواعد بيانات

تحديثات قاعدة البيانات بدون توقف: كيف أنقذنا نمط التوسيع والتعاقد (Expand/Contract) من جحيم التوقفات المجدولة؟

هل سئمت من إيقاف الخدمة مع كل تحديث لهيكلة قاعدة البيانات؟ أشارككم قصة حقيقية وكيف أنقذنا نمط التوسيع والتعاقد (Expand/Contract) من ليالي النشر الطويلة والمُجهدة،...

4 يونيو، 2026 قراءة المزيد
الشبكات والـ APIs

كانت إعادة المحاولة كارثة: كيف أنقذتنا مفاتيح عدم تكرار العمليات (Idempotency Keys) من جحيم الفواتير المزدوجة؟

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

4 يونيو، 2026 قراءة المزيد
الحوسبة السحابية

من التوقف التام إلى النجاة: كيف أنقذتنا استراتيجية “الضوء المرشد” (Pilot Light) يوم انقطعت السحابة؟

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

4 يونيو، 2026 قراءة المزيد
التوظيف وبناء الهوية التقنية

كانت مهمتي البرمجية للاختبار مجرد كود: كيف أنقذني توثيق القرارات من جحيم الصمت بعد المقابلة؟

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

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

من الانتظار لأيام إلى الدفع في ثوانٍ: كيف أنقذتنا شبكات الدفع الفوري من جحيم التحويلات البنكية؟

أسرد لكم من واقع تجربتي كـ "أبو عمر"، كيف عانينا من بطء وتكلفة التحويلات البنكية الدولية، وكيف جاءت شبكات الدفع الفوري ومعيار ISO 20022 لتكون...

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

كان كل خادم لدينا ‘ندفة ثلج’ فريدة: كيف أنقذنا ‘الكود كبنية تحتية’ (IaC) من جحيم الانجراف اليدوي؟

في هذه المقالة، أشارككم قصة حقيقية من قلب المعركة التقنية مع "خوادم ندفات الثلج" الفوضوية. سنغوص في مفهوم "الكود كبنية تحتية" (IaC) وكيف أن أدوات...

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

كانت تغطية الاختبارات 100% لكن الأخطاء تتسرب: كيف أنقذنا “الاختبار الطفري” من جحيم الثقة الزائفة؟

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

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