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

أذكر “سالم” جيداً. شاب يافع، “شعلة” كما نقول في فلسطين، عيناه تبرقان ذكاءً وشغفاً. كان أفضل مبرمج لدينا بلا منازع، “الجوكر” الذي نلقي به في أعقد المشاكل التقنية فيعود بالحل. كان يكتب الكود كما يكتب الشاعر قصيدته، بجمال وكفاءة وإتقان. بعد خمس سنوات من العمل الدؤوب، وصل سالم إلى منصب “مهندس برمجيات أول” (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. اليوم هي تقود واحدة من أهم مبادراتنا التقنية، وهي أسعد وأكثر إنتاجية من أي وقت مضى. لم نخسرها، بل وضعناها في المكان الذي تتألق فيه.

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

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

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

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

أبو عمر

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

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

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

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

آخر المدونات

التكنلوجيا المالية Fintech

كانت عمليات الاحتيال تسبقنا بخطوة: كيف أنقذتنا ‘نماذج اكتشاف الشذوذ’ من جحيم القواعد الثابتة؟

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

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

كانت بنيتنا التحتية قصرًا من ورق: كيف أنقذنا Terraform من جحيم التغييرات اليدوية وانحراف الإعدادات؟

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

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

كانت اختباراتنا تنهار عشوائياً: كيف أنقذنا Playwright من جحيم الاختبارات المتقشرة (Flaky Tests)؟

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

14 مايو، 2026 قراءة المزيد
أدوات وانتاجية

كانت طرفيتي سجناً: كيف أنقذنا ‘الباحث التقريبي’ (Fuzzy Finder) من جحيم البحث في الـ History؟

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

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

كانت عمليات النشر كابوساً: كيف أنقذتنا “خطوط أنابيب CI/CD” من جحيم “يوم النشر” اليدوي؟

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

14 مايو، 2026 قراءة المزيد
خوارزميات

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

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

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