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

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

والله يا جماعة، شعرت كأن أحدهم سكب عليّ دلواً من الماء البارد. خالد؟ لماذا؟ سألته بهدوء مصطنع: “خير يا خالد؟ شو اللي صار؟”.

أجابني بصراحة قاسية: “أبو عمر، أنا بحب الكود، بحب أحل المشاكل الصعبة، بحب أبني أنظمة. الشركة عرضت عليّ أصير مدير فريق (Engineering Manager). أنا ما بدي أصير مدير، ما بدي أقضي يومي في اجتماعات ومتابعة جداول وتقييم أداء. بدي أكبر تقنياً، بس حاسس إنه الطريق مسدود قدامي. يا بصير مدير، يا بضل مكاني، يا بمشي. وأنا اخترت أمشي”.

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

ما هو جحيم “إما أن تصبح مديراً أو ترحل”؟

في معظم الشركات التقنية التقليدية، يبدو السلم الوظيفي كخط مستقيم للأعلى. تبدأ كمبرمج مبتدئ (Junior)، ثم متوسط الخبرة (Mid-level)، ثم خبير (Senior). وبعدها؟ هنا تقع المشكلة. الطريق الوحيد “للأعلى” هو التحول إلى منصب إداري: مدير فريق، ثم مدير قسم، وهكذا.

هذا النموذج يسبب كوارث حقيقية:

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

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

بعد حادثة خالد (والذي نجحنا في إقناعه بالبقاء بعد أن وعدناه بتغيير حقيقي)، عقدنا العزم على بناء نظام جديد. نظام يعترف بأن “القيادة” لها وجهان: قيادة الأفراد (Management)، وقيادة التقنية (Technical Leadership). وهذا هو جوهر المسار الوظيفي المزدوج.

ببساطة، بعد مستوى المهندس الخبير (Senior Engineer)، يتفرع المسار إلى طريقين متوازيين، متساويين في الأهمية والتقدير والراتب والنفوذ.

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

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

  • إدارة الأفراد (People Management): متابعة الأداء، التطوير المهني، التوظيف.
  • تخطيط المشاريع (Project Planning): تحديد الأهداف، توزيع المهام، ضمان التسليم في الوقت المحدد.
  • التواصل والتنسيق بين الفرق.
  • بناء ثقافة فريق إيجابية ومنتجة.

المسميات الوظيفية: Engineering Manager, Director of Engineering, VP of Engineering.

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

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

  • القيادة التقنية (Technical Leadership): تصميم البنية التحتية للمشاريع الكبيرة والمعقدة (System Architecture).
  • حل المشاكل الأصعب: الغوص في أعقد المشاكل التي لا يستطيع الفريق حلها.
  • الإرشاد والتوجيه (Mentorship): توجيه المهندسين الآخرين تقنياً، ومراجعة أكوادهم، ونشر أفضل الممارسات.
  • البحث والتطوير: استكشاف التقنيات الجديدة وتحديد مدى ملاءمتها للشركة.

المسميات الوظيفية: Staff Engineer, Principal Engineer, Distinguished Engineer.

نقطة مهمة جداً: نجاح هذا النظام يعتمد على أن يكون المساران متساويين تماماً. راتب الـ Staff Engineer يجب أن يكون في نفس نطاق راتب الـ Engineering Manager. تأثيره في القرارات التقنية يجب أن يكون مساوياً أو أكبر. يجب أن يُدعى لنفس الاجتماعات الاستراتيجية. لو شعر الناس أن المسار التقني هو “درجة ثانية”، يفشل النظام بأكمله.

كيف طبقنا المسار المزدوج… خطوة بخطوة

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

1. الاعتراف بالمشكلة وجمع البيانات

بدأنا بعقد جلسات استماع مع كبار المهندسين. سألناهم بصراحة عن طموحاتهم ومخاوفهم. نظرنا في بيانات “مقابلات الخروج” (Exit Interviews) للموظفين الذين غادروا. كانت البيانات واضحة: هناك “وجعة راس” حقيقية تتعلق بالنمو المهني للمبرمجين الخبراء.

2. تصميم المسارات وتحديد المسؤوليات (The Competency Matrix)

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

مثال مبسط جداً لكيفية التفريق بين مدير وفني في نفس المستوى (مثلاً، Level 5):

Level 5: Engineering Manager

  • التأثير (Impact): يضمن نجاح فريقه (4-8 مهندسين) في تسليم المشاريع.
  • القيادة (Leadership): يطور مهارات فريقه، ويدير الأداء، ويوظف مواهب جديدة.
  • التقنية (Tech): يفهم التقنيات التي يعمل عليها فريقه بما يكفي لتسهيل النقاشات واتخاذ القرارات، لكنه لا يكتب الكود يومياً.

Level 5: Staff Engineer

  • التأثير (Impact): يقود النجاح التقني لمشروع كبير يمتد عبر عدة فرق، أو يحل مشكلة تقنية معقدة توفر على الشركة مبالغ طائلة.
  • القيادة (Leadership): يوجه ويرشد (mentors) المهندسين الـ Seniors في عدة فرق، ويقود النقاشات حول البنية التحتية (Architecture).
  • التقنية (Tech): خبير عميق في مجال معين، يكتب أكواداً نموذجية، ويقوم بمراجعات الكود الأكثر حساسية.

هذه الشفافية أعطت الجميع خريطة طريق واضحة لنموهم المهني.

3. تمكين المسار التقني: لا تجعله لقباً فارغاً

أكبر خطأ يمكن أن ترتكبه هو إعطاء شخص ما لقب “Staff Engineer” ثم تتجاهله. لتمكين هذا الدور، قمنا بالتالي:

  • مقعد على الطاولة: أصبح الـ Staff Engineers جزءاً أساسياً من اجتماعات التخطيط الاستراتيجي للمنتجات والتقنية.
  • وقت مخصص للبحث: خصصنا لهم وقتاً (مثلاً 20% من وقتهم) لاستكشاف التقنيات الجديدة وبناء نماذج أولية (prototypes).
  • سلطة تقنية: أصبح لهم حق “الفيتو” على القرارات التقنية السيئة في مجال خبرتهم. كلمتهم مسموعة ومحترمة.

خالد، صديقنا الذي كاد أن يرحل، أصبح أول Staff Engineer لدينا. قاد مشروع إعادة هيكلة قاعدة البيانات بالكامل، وهو مشروع لم يكن ليتم لو أصبح مديراً يقضي وقته في الاجتماعات. لقد ازدهر، وازدهرت الشركة معه.

نصائح من قلب “المعمعة”

بعد سنوات من تطبيق هذا النظام، هذه بعض النصائح العملية التي أقدمها لكم:

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

الخلاصة… والزبدة

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

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

أبو عمر

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

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

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

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

آخر المدونات

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

من أيام لدقائق: كيف أنقذ الذكاء الاصطناعي عمليات KYC من كابوس الانتظار والغرامات؟

كانت عمليات "اعرف عميلك" (KYC) كابوسًا حقيقيًا يستغرق أيامًا ويهدد الشركات الناشئة. في هذه المقالة، أشارككم قصة حقيقية من الميدان، يا جماعة، كيف حوّلنا هذا...

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

مقاييسنا كانت جزرًا معزولة وسجلاتنا صرخة في وادٍ: كيف أنقذنا OpenTelemetry من جحيم تتبع الأخطاء؟

أنا أبو عمر، مبرمج فلسطيني، وأروي لكم حكايتي مع فوضى تتبع الأخطاء في الخدمات المصغرة (Microservices). كانت مقاييسنا وسجلاتنا كالجزر المعزولة، حتى ظهر المنقذ OpenTelemetry...

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

كانت تغطية اختباراتنا 100% لكنها عديمة الفائدة: كيف أنقذنا ‘الاختبار الطفري’ (Mutation Testing) من جحيم الثقة الزائفة؟

كنا نحتفل بتغطية اختبارات تصل إلى 100%، لكنها كانت مجرد وهم جميل انهار عند أول تحديث حقيقي. هذه قصتي مع "الاختبار الطفري" (Mutation Testing)، الأداة...

25 أبريل، 2026 قراءة المزيد
أتمتة العمليات

من تنبيهات منتصف الليل إلى الراحة: كيف أنقذتنا كتيبات التشغيل الآلية (Automated Runbooks) من جحيم المناوبة؟

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

25 أبريل، 2026 قراءة المزيد
نصائح برمجية

كانت حالتنا تتغير بشكل غير متوقع: كيف أنقذتنا ‘اللامتغيرية’ (Immutability) من جحيم الآثار الجانبية الخفية؟

أشارككم قصة من أيام وليالي التصحيح المؤلمة، وكيف كان مفهوم "اللامتغيرية" (Immutability) هو طوق النجاة الذي أنقذ فريقنا من أخطاء تغيير الحالة (state) غير المتوقعة....

25 أبريل، 2026 قراءة المزيد
​معمارية البرمجيات

كان منطق أعمالنا كرة طين عملاقة: كيف أنقذنا ‘التصميم الموجه بالمجال’ (DDD) من جحيم الفوضى التقنية؟

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

25 أبريل، 2026 قراءة المزيد
ذكاء اصطناعي

كان ذكاؤنا الاصطناعي كاذباً واثقاً: كيف أنقذنا ‘الجيل المعزز بالاسترجاع’ (RAG) من جحيم هلوسات النماذج اللغوية؟

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

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