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

يا أهلاً وسهلاً فيكم يا جماعة. قبل كم سنة، كان عنا في الشركة شب اسمه “سائد”، الله يسهل عليه وين ما كان. سائد ما كان مجرد مبرمج، كان فنان، “حريقة” زي ما بنحكيها بالعامية. الكود تبعه كان زي الشعر الموزون، نظيف، فعال، ومدروس لآخر نفس. أي مشكلة معقدة كانت تواجهنا، كنا نرميها على سائد ويرجّعلنا إياها محلولة بأناقة ما بعدها أناقة.

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

سائد انتقل من كتابة الكود اللي بعشقه، لاجتماعات لا تنتهي، تقارير أداء، متابعة إجازات، وحل مشاكل بين أعضاء الفريق. شوي شوي، بلش بريق الشغف في عيونه يختفي. صار يفتح الـ IDE تبعه بالليل عشان “يحك إيده” ويكتب كم سطر كود، لكنه كان يرجع تعبان ومرهق من “شغل الإدارة”. بعد أقل من سنة، مهندسنا الفنان اللي كان يبني أنظمة، صار مدير متوسط الأداء، والأهم من هيك، صار إنسان تعيس. النهاية كانت متوقعة: سائد قدم استقالته وراح على شركة ثانية عرضت عليه منصب “مهندس برمجيات رئيسي” (Principal Software Engineer)، منصب بخليه يكتب كود ويحل مشاكل تقنية معقدة، وبراتب وامتيازات أعلى من منصب المدير اللي كان فيه عنا. وقتها، خبطت على راسي وقلت: “شو اللي عملناه؟ خسرنا أفضل مبرمج عنا لأنه ما عرفنا كيف نرقيه صح!”.

هذيك الحادثة كانت جرس إنذار هز الشركة كلها، وخلتنا نعيد التفكير في كل مفهوم النمو الوظيفي للمهندسين.

ليش الترقية التقليدية كانت كابوس لأحسن المبرمجين؟

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

هذا النموذج التقليدي يخلق عدة مشاكل كارثية:

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

“المسار الوظيفي المزدوج”: الحل اللي أنقذنا

بعد قصة سائد وغيره، جلسنا كقيادة تقنية في الشركة، وقررنا أنه “خلص، بكفي هالحكي”. لا يمكن أن نستمر في خسارة أفضل عقولنا بهذا الشكل. الحل كان بتبني مفهوم أصبح الآن أساسيًا في شركات التكنولوجيا الكبرى: المسار الوظيفي المزدوج (The Dual Career Path).

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

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

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

• قائد فريق (Team Lead): يركز على إدارة المهام اليومية لفريق صغير وتوجيههم تقنيًا.
• مدير هندسة (Engineering Manager): يركز على إدارة الأفراد (People Management)، نموهم الوظيفي، التوظيف، والمواءمة مع أهداف الشركة. عادة ما يكون أقل انخراطًا في الكود اليومي.
• مدير قسم الهندسة (Director of Engineering): يدير عدة مدراء هندسة، ويركز على الاستراتيجية طويلة الأمد لعدة فرق أو قسم كامل.

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

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

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

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

كيف طبقنا هالحكي على أرض الواقع؟

الكلام النظري جميل، لكن الشيطان يكمن في التفاصيل. تطبيق هذا النظام تطلب منا خطوات عملية وواضحة:

1. بناء مصفوفة الكفاءات (Competency Matrix)

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

مثال مبسط جدًا للشكل العام:

| المستوى | المسار التقني (IC)           | المسار الإداري (Management)      |
|----------|------------------------------|----------------------------------|
|    1     | Junior Engineer              | -                                |
|    2     | Software Engineer            | -                                |
|    3     | Senior Software Engineer     | Team Lead (أحيانًا)              |
|    4     | Staff Engineer               | Engineering Manager              |
|    5     | Principal Engineer           | Senior Engineering Manager       |
|    6     | Distinguished Engineer       | Director of Engineering          |

هذه الوثيقة أصبحت المرجع للجميع في تقييم الأداء، الترقيات، وتحديد الأهداف.

2. تعريف نطاق التأثير (Scope of Impact)

أهم فارق بين المستويات العليا في المسار التقني ليس فقط “كتابة كود أفضل”، بل “نطاق التأثير”.

• المهندس الأول (Senior): تأثيره على مستوى المشروع أو الخدمة التي يعمل عليها.
• المهندس الرئيسي (Staff): تأثيره على مستوى عدة فرق أو أنظمة متكاملة. (مثال: “مسؤول عن استراتيجية الـ Caching في الشركة كلها”).
• المهندس الخبير (Principal): تأثيره على مستوى الشركة ككل أو حتى على الصناعة. (مثال: “يقود مبادرة الانتقال إلى بنية Microservices على مستوى الشركة”).

3. نصيحة من أخوكم أبو عمر

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

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

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

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

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

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