يا الله شو بتذكر هداك اليوم… كان يوم ثلاثاء عادي، الشمس بتضرب بالشباك، وصوت الكيبوردات في المكتب زي معزوفة موسيقية بعرفها منيح. فجأة، الباب خبط خبطة خفيفة ودخل “سالم”. سالم هاد يا جماعة مش أي مهندس، هاد من النوع اللي لما يوقع سيستم كبير والكل صافن، هو الوحيد اللي بكون عارف وين المشكلة بالضبط. كان بمثابة “جوجل” الداخلي تبعنا لأي مشكلة معقدة.
دخل سالم وعلى وجهه نظرة غريبة، وقدم لي ورقة مطوية. فتحتها، وإذا هي استقالته. حسيت كأنو حدا كب عليّ سطل مي باردة. سألته: “ليش يا سالم؟ شو القصة؟ مش مبسوط معنا؟”.
جوابه كان صفعة على وجهي، وعلى وجه كل النظام اللي كنا ماشيين عليه. قال لي بصوت هادئ: “أبو عمر، بحبكم وبحب الشغل هون، بس الشركة المنافسة عرضت علي منصب ‘قائد فريق’ (Team Lead). أنا صار لي 8 سنين بكتب كود، وحاسس إني علقان مكاني. بدي أتقدم بمسيرتي المهنية”.
المصيبة الأكبر؟ إحنا كنا فعلاً بنحضر لترقية سالم… لترقية تخليه “قائد فريق”! لم نكن نعلم أن رغبته في “التقدم” ليست بالضرورة تعني “الإدارة”. هو أراد تقديراً أكبر لخبرته التقنية، ومسؤوليات أعقد، وتأثيراً أوسع، لكنه لم يرد أن يترك الكود ويقضي وقته في اجتماعات وتقييم أداء. لقد أراد أن ينمو كـ “مهندس”، لا كـ “مدير”.
رحيل سالم كان خسارة فادحة، لكنه كان أيضاً أكبر درس تعلمناه. كان جرس إنذار أيقظنا على حقيقة مُرّة: نظامنا التقليدي للترقيات كان يطرد أفضل عقولنا التقنية.
المشكلة الكلاسيكية: السلم الوظيفي ذو الاتجاه الواحد
في معظم الشركات، الطريق الوظيفي للمهندس واضح ومحدد، ولكنه للأسف معيب. يبدو كالتالي:
Junior Developer -> Mid-level Developer -> Senior Developer -> Team Lead -> Engineering Manager -> Director
يبدو منطقياً، أليس كذلك؟ لكن المشكلة تكمن في نقطة التحول الحرجة: من Senior Developer إلى Team Lead. في هذه النقطة، أنت تجبر شخصاً قضى سنوات في صقل مهاراته التقنية على التخلي عنها ليصبح “مدير أشخاص”.
وهنا تحدث إحدى الكارثتين:
- المهندس يرفض ويغادر: تماماً كما فعل سالم، يبحث عن شركة تقدّر خبرته التقنية وتمنحه مساراً للنمو كخبير تقني. (وهيك بتخسر الشركة جوهرتها التقنية).
- المهندس يقبل ويتحول لمدير سيء: يقبل الترقية من أجل اللقب والراتب، لكنه يكره العمل الإداري. والنتيجة؟ تخسر مهندساً لامعاً، وتكسب مديراً فاشلاً يُحبط فريقه بالكامل. خسارة مزدوجة!
كنا نعيش في هذا الجحيم. كل بضعة أشهر، نفقد مهندساً خبيراً أو نرى أحدهم يتحول إلى مدير بائس. كان لا بد من وجود حل آخر.
الحل المنقذ: مسار النمو المزدوج (Dual Career Path)
بعد حادثة سالم، جلسنا كفريق قيادي، وعقدنا العزم على إيجاد حل. وبعد بحث طويل ونقاشات معمقة، تبنينا مفهوم “مسار النمو المزدوج”.
الفكرة بسيطة وعبقرية في آن واحد: بدلاً من وجود سلم وظيفي واحد، نقوم بإنشاء مسارين متوازيين ومتساويين في الأهمية والتقدير والتعويضات المالية بعد مستوى معين (عادةً بعد Senior).
نصيحة أبو عمر: أهم نقطة في نجاح هذا النظام هي أن يكون المساران متساويين تماماً في المكانة والراتب. يجب أن يكون منصب “Principal Engineer” مرموقاً ومجزياً تماماً كمنصب “Director of Engineering”. إذا كان المسار التقني يُنظر إليه على أنه “درجة ثانية”، فسيفشل النظام بأكمله.
المسار الأول: المسار الإداري (Management Track)
هذا هو المسار التقليدي لمن يجدون شغفهم في قيادة الناس وتطويرهم. هؤلاء هم الأشخاص الذين يستمتعون بالاجتماعات الفردية (1-on-1s)، وتوزيع المهام، وحل النزاعات، ووضع استراتيجية الفريق. مهمتهم هي مضاعفة إنتاجية الفريق.
- Team Lead
- Engineering Manager
- Director of Engineering
المسار الثاني: المسار التقني (Individual Contributor – IC Track)
هذا هو المسار الذي أنقذنا! إنه مصمم للخبراء التقنيين الذين يريدون تعميق خبرتهم والتأثير على نطاق أوسع دون إدارة الناس بشكل مباشر. مهمتهم هي حل أعقد المشاكل التقنية وتوجيه الشركة تكنولوجياً.
- Senior Engineer: خبير في مجاله، ومرجع لزملائه في الفريق.
- Staff Engineer: يعمل على مستوى عدة فرق. يحل المشاكل التقنية العابرة للفرق (cross-functional)، ويضع معايير البرمجة، ويقود المشاريع التقنية الاستراتيجية الكبرى.
- Principal Engineer: يعمل على مستوى الشركة بأكملها. يفكر في التحديات التقنية التي ستواجهنا بعد 3-5 سنوات، ويؤثر في القرارات المعمارية الأساسية، ويمثل الشركة في المؤتمرات التقنية. “فريقه” هو قسم الهندسة بأكمله.
كيف طبقنا هذا النظام؟ خطوات عملية من أرض المعركة
الكلام النظري جميل، لكن الشيطان يكمن في التفاصيل. إليكم الخطوات العملية التي اتبعناها لتطبيق هذا النظام بنجاح:
1. تحديد المستويات والمسؤوليات بوضوح (Career Ladder)
أول وأهم خطوة كانت إنشاء وثيقة مفصلة تسمى “سلم التدرج الوظيفي” (Career Ladder). هذه الوثيقة حددت كل مستوى وظيفي في الشركة، وما هي المسؤوليات والتوقعات لكل مستوى في كلا المسارين (الإداري والتقني).
لتقريب الصورة، أنشأنا شيئاً شبيهاً بملف JSON هذا الذي يمثل هيكل البيانات لمستوياتنا الوظيفية. هذا ليس كوداً تشغيلياً، بل مثال على كيفية هيكلة هذه المعلومات لتكون واضحة للجميع.
{
"levels": [
{
"level": "L3",
"title": "Engineer I",
"ic_track": { "description": "يكتسب المهارات الأساسية وينفذ المهام المحددة." },
"manager_track": null
},
{
"level": "L4",
"title": "Engineer II",
"ic_track": { "description": "يمتلك جزءاً من النظام، ويعمل باستقلالية." },
"manager_track": null
},
{
"level": "L5",
"title": "Senior Engineer",
"ic_track": { "description": "يقود مشاريع معقدة داخل فريقه." },
"manager_track": {
"title": "Engineering Manager I",
"description": "يدير فريقاً صغيراً (3-5 مهندسين)."
}
},
{
"level": "L6",
"title": "Staff Engineer",
"ic_track": { "description": "يقود مبادرات تقنية عبر عدة فرق." },
"manager_track": {
"title": "Engineering Manager II",
"description": "يدير عدة فرق أو فريقاً كبيراً."
}
},
{
"level": "L7",
"title": "Principal Engineer",
"ic_track": { "description": "يؤثر على الاستراتيجية التقنية للشركة بأكملها." },
"manager_track": {
"title": "Director of Engineering",
"description": "يدير قسماً هندسياً كاملاً."
}
}
]
}
هذه الهيكلية أوضحت للجميع أن “Staff Engineer” في المستوى L6 له نفس أهمية “Engineering Manager II” في نفس المستوى.
2. الشفافية المطلقة: الكل لازم يكون بالصورة
لم نحتفظ بهذه الوثيقة في الأدراج المغلقة. قمنا بنشرها على الشبكة الداخلية للشركة، وعقدنا اجتماعات لشرحها لكل مهندس. أصبحت هذه الوثيقة هي المرجع للجميع. عندما يسأل مهندس “كيف أترقى؟”، يكون الجواب: “افتح الوثيقة، انظر إلى المستوى التالي، وهذه هي المتطلبات”.
3. المرونة في التنقل بين المسارين
أدركنا أن القرارات المهنية ليست أبدية. قد يجرب مهندس بارع المسار الإداري ثم يكتشف أنه لا يناسبه، أو العكس. لذلك، صممنا النظام ليكون مرناً. الانتقال من مسار لآخر (مثلاً من Engineering Manager إلى Staff Engineer) لا يُعتبر “تخفيض رتبة” (demotion)، بل هو تغيير في طبيعة المسؤوليات بنفس المستوى الوظيفي. هذا شجع الناس على التجربة دون خوف.
النتائج على أرض الواقع: هل نجحنا؟
بعد مرور عامين على تطبيق هذا النظام، كانت النتائج مذهلة:
- 📉 انخفاض هائل في معدل دوران الموظفين (Attrition): توقف نزيف العقول التقنية الخبيرة. لم نعد نخسر مهندسينا الكبار للشركات المنافسة.
- 💡 ازدياد الابتكار: المهندسون في المسار التقني (Staff/Principal) تفرغوا لحل المشاكل التقنية الكبرى التي لم يكن لدى أحد وقت لها في السابق. أطلقوا مشاريع حسّنت أداء أنظمتنا بنسبة 40% وخفضت تكاليف البنية التحتية.
- 😊 تحسن جودة الإدارة: أصبح من يختار المسار الإداري يفعل ذلك عن قناعة وشغف، مما أدى إلى وجود مدراء أفضل وأكثر فعالية، وفرق أكثر سعادة وإنتاجية.
- 🗺️ وضوح الرؤية المهنية: شعر المهندسون بالارتياح والطمأنينة لأنهم يرون مساراً واضحاً للنمو أمامهم، سواء اختاروا قيادة التكنولوجيا أو قيادة الناس.
الخلاصة: استثمر في العقول، لا في المناصب
يا صديقي المبرمج، ويا صديقي المدير، الدرس الذي تعلمناه بالطريقة الصعبة هو أن أكبر أصول أي شركة تقنية ليس الكود، ولا الخوادم، ولا حتى المنتج. أكبر أصل هو العقول التي تقف خلف كل هذا. عندما تفشل في توفير مسار نمو لهذه العقول، فأنت تحكم على شركتك بالفشل البطيء.
لا تفترض أن الجميع يريد أن يصبح مديراً. قدّر الخبرة التقنية حق قدرها، واصنع لها مساراً خاصاً بها، مساراً يكافئها ويعترف بقيمتها. امنح مهندسيك الخيار، وشاهدهم يبنون لك المستقبل.
تذكر دائماً: بناء سلم وظيفي مزدوج قد يبدو عملاً إضافياً، ولكنه استثمار صغير جداً مقارنة بتكلفة خسارة أفضل مهندسيك. 😉
