المسار الوظيفي المزدوج: كيف أنقذنا خيرة مهندسينا من جحيم الاختيار بين الإدارة والكود؟

أذكر “سالم” جيداً. شاب يافع، “شعلة” كما نقول في فلسطين، عيناه تبرقان ذكاءً وشغفاً. كان أفضل مبرمج لدينا بلا منازع، “الجوكر” الذي نلقي به في أعقد المشاكل التقنية فيعود بالحل. كان يكتب الكود كما يكتب الشاعر قصيدته، بجمال وكفاءة وإتقان. بعد خمس سنوات من العمل الدؤوب، وصل سالم إلى منصب “مهندس برمجيات أول” (Senior Software Engineer).

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

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

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

ما هو الجحيم الذي كنا نعيش فيه؟ سلم التقدم التقليدي

قبل أن نتحدث عن الحل، دعونا نفصّل المشكلة. المسار الوظيفي التقليدي في معظم الشركات يشبه هرماً واحداً. تبدأ كمبرمج مبتدئ، ثم مبرمج، ثم مهندس أول. وبعدها؟ الطريق الوحيد للأعلى هو عبر الإدارة. تصبح مدير فريق، ثم مدير قسم، ثم مدير تنفيذي… وهكذا.

هذا النموذج كارثي في عالم التقنية لسببين رئيسيين:

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

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

طوق النجاة: المسار الوظيفي المزدوج (Dual Career Ladder)

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

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

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

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

التركيز هنا ينصب على نمو الأفراد ونجاح الفريق.

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

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

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

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

كيف طبقنا هذا النظام عملياً؟ قصة من داخل المطبخ

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

الخطوة 1: تحديد المستويات والكفاءات بوضوح

كانت هذه أصعب خطوة. جلسنا كأسابيع نحدد ماذا يعني بالضبط أن تكون “Staff Engineer”؟ ما الفرق بينه وبين “Senior Engineer”؟ وماذا يفعل “Principal Engineer”؟

الخلاصة كانت أن الفرق ليس في “كمية” الكود، بل في “نطاق التأثير” (Scope of Impact).

  • Senior Engineer: يمتلك ميزة أو نظاماً داخل فريقه. تأثيره على مستوى الفريق.
  • Staff Engineer: تأثيره يمتد عبر عدة فرق. يحل المشاكل التي لا يملكها فريق واحد، مثل تحسين أداء قاعدة البيانات التي تستخدمها 5 فرق.
  • Principal Engineer: تأثيره على مستوى القسم أو الشركة بأكملها. يقود المبادرات التقنية الاستراتيجية، مثل الانتقال إلى بنية الخدمات المصغرة (Microservices) أو تبني منصة سحابية جديدة.

نصيحة أبو عمر: وثّق هذه المستويات في مصفوفة واضحة (Career Matrix). لتسهيل الأمر، يمكنك تمثيلها كهيكل بيانات بسيط. هذا يساعد المهندسين على فهم ما هو متوقع منهم في كل مستوى.

كمثال، يمكن أن يبدو جزء من ملف التوصيف (مثلاً بصيغة YAML) هكذا:


# Individual Contributor (IC) Track
- level: "Senior Engineer (L5)"
  scope: "Owns complex features/components within a single team."
  competencies:
    - "Technical Execution: Delivers high-quality, complex projects independently."
    - "Mentorship: Mentors junior engineers within the team."
    - "Influence: Influences technical decisions within the team."

- level: "Staff Engineer (L6)"
  scope: "Impacts multiple teams or a large, complex system."
  competencies:
    - "Technical Strategy: Solves ambiguous, cross-team technical problems."
    - "Mentorship: Mentors senior engineers and leads tech guilds."
    - "Influence: Influences technical roadmap for a group of teams."

# Management Track
- level: "Engineering Manager (L6)"
  scope: "Manages a team of 4-8 engineers."
  competencies:
    - "People Growth: Responsible for hiring, performance, and career growth of reports."
    - "Project Execution: Ensures team delivery and execution on roadmap."
    - "Influence: Represents the team to stakeholders and aligns with product."

لاحظ أن Staff Engineer (L6) و Engineering Manager (L6) في نفس المستوى (Level 6). هذا هو جوهر المساواة.

الخطوة 2: المساواة في الرواتب والتقدير

وهنا يقع الكثيرون في الفخ. لا يمكنك أن تقول إن المسارين متساويان ثم تدفع للمدير راتباً أعلى بكثير من المهندس الرئيسي. قمنا بمواءمة نطاقات الرواتب (Salary Bands) بحيث يكون راتب الـ Principal Engineer مكافئاً لراتب الـ Senior Manager أو Director. التقدير لا يقتصر على المال، بل يشمل أيضاً:

  • المسمى الوظيفي: أصررنا على أن تكون المسميات مثل “Principal Engineer” ذات هيبة واحترام.
  • صناعة القرار: يشارك كبار المهندسين في اجتماعات وضع الاستراتيجية التقنية جنباً إلى جنب مع المديرين.
  • الظهور: نشجعهم على التحدث في المؤتمرات، وكتابة المدونات التقنية، وقيادة ورش العمل الداخلية.

الخطوة 3: السماح بالمرونة والتجربة

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

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

الخلاصة يا جماعة الخير ✅

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

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

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

أبو عمر

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

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

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

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

آخر المدونات

تجربة المستخدم والابداع البصري

كان المستخدمون يقاتلون واجهاتنا: كيف أنقذتنا ‘قوانين تجربة المستخدم’ من جحيم التصميم غير البديهي؟

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

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

كنا ندفع ثمن الخوادم حتى وهي نائمة: كيف حررتنا الحوسبة بدون خوادم (Serverless) من جحيم التكاليف الخاملة؟

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

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

كانت قاعدة بياناتنا تتوسل الرحمة: كيف أنقذتنا استراتيجية التخزين المؤقت الجانبي (Cache-Aside) من جحيم الاستعلامات؟

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

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

كابوس التحقق اليدوي من الهوية: كيف أنقذنا الـ eKYC من جحيم الاحتيال وتجربة المستخدم السيئة

أشارككم قصة من قلب المعاناة في شركتنا الناشئة، وكيف انتقلنا من التحقق اليدوي الكارثي من هويات العملاء إلى نظام آلي (eKYC) قائم على الذكاء الاصطناعي....

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

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

أشارككم قصة حقيقية من قلب المعركة التقنية، عن ليلة كاد فيها "الانجراف التكويني" أن يدمر مشروعنا. اكتشفوا كيف كانت "البنية التحتية كشيفرة" (IaC) طوق النجاة...

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