السلام عليكم يا جماعة الخير،
اسمحولي اليوم أحكيلكم قصة صارت معي قبل كم سنة، قصة شب اسمه “سائد”. سائد كان من أشطر المبرمجين اللي مروا عليّ في حياتي المهنية، “ماكينة كود” إذا صح التعبير. أي مشكلة معقدة، أي Bug مستعصي، كنا نبعته لسائد ويرجعلنا بالحل. كان عقله يشتغل بطريقة مختلفة، يشوف الأنماط اللي ما حدا غيره يشوفها، ويكتب كود نظيف ومتقن كأنه قطعة فنية.
بطبيعة الحال، لما فتحنا منصب “قائد فريق” (Team Lead)، كان اسم سائد أول اسم على الطاولة. قلنا “هذا هو! الشب المناسب في المكان المناسب”. ترقية مستحقة، ومكافأة لجهوده. استلم سائد المنصب بحماس… وفي أول شهر، بلشت المشاكل.
سائد، اللي كان يعشق شاشة الكود السوداء، صار يقضي 80% من وقته في اجتماعات وتقارير ومتابعة إجازات ومشاكل شخصية بين أعضاء الفريق. صار يكره الشغل اللي كان يحبه. والأسوأ من هيك، الفريق نفسه بلش يشتكي. سائد، العبقري تقنياً، كان يفتقر لمهارات التواصل والصبر اللازمة للإدارة. كان يتوقع من الجميع يكونوا بنفس سرعته وفهمه، وهذا سبب إحباط كبير للفريق. خلال 6 أشهر، خسرنا مبرمج عبقري… وكسبنا مدير فاشل. وبعدها بفترة قصيرة، استقال سائد وراح لشركة ثانية ليرجع يكتب كود. خسرناه مرتين.
هذيك الحادثة كانت صفعة قوية النا، وخلتنا نسأل حالنا سؤال جوهري: “شو القصة؟ ليش قاعدين بنخسر أفضل كوادرنا بهالطريقة؟”. الجواب كان في نظامنا نفسه، نظام الترقية ذو المسار الواحد الذي لا يرحم.
جحيم “الترقية إلى مستوى عدم الكفاءة”
المشكلة اللي واجهناها مع سائد الها اسم علمي، بسموها “مبدأ بيتر” (The Peter Principle) أو ما أحب أن أسميه “الترقية إلى مستوى عدم الكفاءة”. المبدأ بقول ببساطة إنه في أي هيكل هرمي، كل موظف يميل إلى أن تتم ترقيته حتى يصل إلى مستوى يصبح فيه غير كفء.
في عالمنا التقني، هذا المبدأ يتجلى بوضوح مرعب:
- لدينا مبرمج رائع ومبدع.
- لـ “مكافأته” و “تطويره مهنياً”، نقوم بترقيته ليصبح مديراً.
- مهارات كتابة الكود وحل المشاكل التقنية لا تترجم تلقائياً إلى مهارات إدارة بشر وتخطيط استراتيجي.
- النتيجة: نخسر مبرمجاً رائعاً، ونكسب مديراً سيئاً. خسارة مزدوجة للشركة، وللموظف، وللفريق.
كنا عالقين في حلقة مفرغة: إما أن يبقى المبرمج الخبير في نفس مستواه وراتبه للأبد (مما يدفعه للرحيل بحثاً عن تقدير أفضل)، أو أن نرقيه لمنصب يكرهه ويفشل فيه (مما يدفعه للرحيل أيضاً!). كان لا بد من إيجاد مخرج.
المنقذ: المسار المهني المزدوج (Dual Career Path)
بعد بحث طويل وتجارب مريرة، وجدنا الحل في مفهوم بسيط ولكنه ثوري: المسار المهني المزدوج. الفكرة هي التوقف عن رؤية المسار الوظيفي كسلم واحد يصعده الجميع، والبدء في رؤيته كطريق يتفرع إلى مسارين متوازيين ومتساويين في القيمة والأهمية.
هذان المساران هما:
- المسار الإداري (Management Track): هذا هو المسار التقليدي للأشخاص الذين يجدون شغفهم في قيادة الناس، وتطويرهم، وإدارة المشاريع، ووضع الاستراتيجيات. الأدوار هنا تشمل: قائد فريق (Team Lead)، مدير هندسة (Engineering Manager)، مدير قسم (Director).
- مسار المساهم الفردي/التقني (Individual Contributor – IC Track): هذا هو المسار المخصص للخبراء التقنيين الذين يريدون تعميق معرفتهم وتأثيرهم التقني دون إدارة الناس بشكل مباشر. الأدوار هنا تشمل: مهندس برمجيات خبير (Senior Engineer)، مهندس رئيسي (Staff Engineer)، مهندس استشاري (Principal Engineer).
والنقطة الأهم هنا، يا جماعة، هي أن المسارين متساويان. مهندس رئيسي (Staff Engineer) يجب أن يكون له نفس مستوى التأثير والراتب والتقدير الذي يحظى به مدير الهندسة (Engineering Manager). الفرق ليس في “الأهمية”، بل في “نوعية المسؤوليات”.
المسار الإداري: من مبرمج إلى قائد
هذا المسار مخصص لمن يجد نفسه في خدمة الفريق. مسؤولياتك هنا تتغير جذرياً من “كتابة الكود” إلى “تمكين الآخرين من كتابة أفضل كود”.
- المهام: اجتماعات فردية (1-on-1s) مع أعضاء الفريق، تقييم الأداء، حل النزاعات، التوظيف، التخطيط للمشاريع، التواصل مع الأقسام الأخرى.
- المهارات المطلوبة: التعاطف، التواصل الفعال، الذكاء العاطفي، التفويض، التفكير الاستراتيجي.
نصيحة من أبو عمر: يا جماعة، الإدارة مش تشريف، الإدارة تكليف ومسؤولية. إذا ما بتحب تتعامل مع مشاكل الناس وتساعدهم يطوروا حالهم وتفرح لنجاحهم أكثر من نجاحك الشخصي، هاد الطريق مش إلك. القيادة الحقيقية هي خدمة، وليست سلطة.
المسار التقني (IC): من مبرمج إلى خبير استراتيجي
هذا المسار هو حلم كل من يعشق التكنولوجيا ويريد أن يترك بصمته من خلالها. هنا، أنت لا تدير أشخاصاً، بل تدير “التعقيد التقني” للمنظومة بأكملها.
- المهام: تصميم بنية الأنظمة المعقدة (System Architecture)، حل المشاكل التقنية التي تمتد عبر عدة فرق، الإشراف التقني (Mentorship) على المهندسين الآخرين، البحث والتطوير في التقنيات الجديدة، كتابة الوثائق التقنية الاستراتيجية (RFCs).
- المهارات المطلوبة: عمق تقني هائل، رؤية شمولية للأنظمة، مهارة تبسيط المفاهيم المعقدة، القدرة على الإقناع والتأثير التقني.
مهندس رئيسي (Staff Engineer) قد لا يكون له أي تقارير مباشرة، لكن تأثيره قد يمتد على مستوى القسم بأكمله. هو المرجع التقني الذي يضمن أننا لا نبني فقط ميزات جديدة، بل نبنيها بالطريقة الصحيحة والمستدامة للمستقبل.
كيف طبقنا هذا النظام ونجحنا؟
الكلام النظري جميل، لكن التطبيق هو المحك. إليكم الخطوات العملية التي اتبعناها:
الخطوة الأولى: تحديد المستويات والمسؤوليات بوضوح
أول وأهم خطوة كانت إنشاء “مصفوفة الكفاءات والمسارات المهنية” (Career Ladder Matrix). وثيقة واضحة تحدد كل مستوى وظيفي، وما هي المسؤوليات والتوقعات لكل من المسار الإداري والتقني في ذلك المستوى.
مثال مبسط جداً للمستويات المتقدمة:
| المستوى | المسار التقني (IC) | المسار الإداري (Management) | نطاق التأثير المتوقع |
|----------|--------------------------|-----------------------------|--------------------------------------------------------|
| L5 | Staff Engineer | Engineering Manager | يؤثر على عدة فرق، يحل مشاكل تقنية/إدارية معقدة. |
| L6 | Principal Engineer | Senior Engineering Manager | يؤثر على مستوى القسم بأكمله، يضع استراتيجيات طويلة الأمد. |
| L7 | Distinguished Engineer | Director of Engineering | يؤثر على مستوى الشركة، يعتبر مرجعاً في الصناعة. |
وجود هذه المصفوفة جعل مسارات النمو واضحة للجميع. لم يعد السؤال “متى سأصبح مديراً؟”، بل أصبح “ما هو المسار الذي يناسبني وكيف أصل إلى المستوى التالي فيه؟”.
الخطوة الثانية: تغيير ثقافة “المدير هو الزعيم”
وهذه كانت الخطوة الأصعب. كان علينا محاربة الفكرة المتجذرة بأن الترقية الحقيقية الوحيدة هي أن تصبح مديراً. فعلنا ذلك من خلال عدة أمور:
- المساواة في التقدير: حرصنا على أن يكون راتب ومكافآت الـ Staff Engineer مساوية لراتب ومكافآت الـ Engineering Manager.
- منح السلطة التقنية: أصبح للـ Principal Engineer “حق الفيتو” على القرارات التقنية السيئة، حتى لو كانت مدعومة من مدير. صوته التقني أصبح مسموعاً ومحترماً.
- الاحتفاء بالنجاحات التقنية: بدأنا بالاحتفال علناً بالإنجازات التقنية الكبرى (مثل تصميم نظام جديد أو حل مشكلة أداء معقدة) بنفس الحماس الذي نحتفل به بإطلاق مشروع كبير.
نصيحة من أبو عمر: كنا نعمل اجتماعات قيادة مشتركة، يجلس فيها مدير القسم مع الـ Senior Managers والـ Principal Engineers على نفس الطاولة لاتخاذ القرارات. لما يشوفوا باقي المبرمجين إنه صوت الخبير التقني مسموع ومُقدَّر زي صوت المدير، بتبلش الثقافة تتغير لحالها.
الخطوة الثالثة: المرونة والسماح بالانتقال بين المسارين
أدركنا أن قرار اختيار المسار ليس قراراً أبدياً. قد يجرب مبرمج ما المسار الإداري ويكتشف أنه لا يناسبه، والعكس صحيح. لذلك، صممنا النظام ليسمح بالانتقال الأفقي بين المسارين (خصوصاً في المستويات الأولى) دون أن يعتبر ذلك “تخفيضاً” في الرتبة. هذا أعطى الناس الأمان لتجربة ما يريدون دون خوف.
ثمار التجربة: ماذا جنينا من المسار المزدوج؟
بعد تطبيق هذا النظام، النتائج على أرض الواقع كانت مذهلة:
- الاحتفاظ بالمواهب: أفضل خبرائنا التقنيين توقفوا عن مغادرة الشركة. وجدوا مساراً للنمو والتقدير يسمح لهم بفعل ما يحبونه.
- إدارة أفضل: الأشخاص الذين اختاروا المسار الإداري كانوا فعلاً شغوفين بالقيادة، مما انعكس إيجاباً على فرقهم. أصبح لدينا مديرون يريدون أن يكونوا مديرين!
- جودة تقنية أعلى: وجود خبراء تقنيين متفرغين (Senior ICs) رفع من مستوى الجودة التقنية في الشركة بأكملها، وأصبحوا مرجعاً وموجهاً للجميع.
- معنويات أعلى: اختفت حالة الإحباط والغموض الوظيفي. كل شخص أصبح يعرف ما هو المطلوب منه للتقدم في المسار الذي يختاره.
الخلاصة والنصيحة الأخيرة
نموذج “السلم الوظيفي” الواحد هو نموذج قديم ومُدمِّر في عالم التكنولوجيا. إنه يجبر أفضل العقول التقنية على التخلي عن شغفها مقابل وهم “الترقية”. المسار المهني المزدوج ليس مجرد هيكل تنظيمي جديد، بل هو فلسفة قائمة على احترام التنوع في المهارات والطموحات.
يا صاحبي، سواء كنت مبرمجاً في بداية طريقك أو مديراً تنفيذياً في شركة كبرى، اسأل نفسك بصدق: هل نكرّم الخبرة التقنية العميقة بنفس القدر الذي نكرّم به الخبرة الإدارية؟ هل نسمح لأفضل عازفينا بأن يستمروا في العزف ويصبحوا “مايسترو” في العزف، أم نجبرهم على أن يصبحوا مديري فرقة سيئين؟
إذا كان الجواب “لا”، فاعلم أنك تخسر أفضل كوادركم دون أن تشعر. النمو ليس دائماً “إلى الأعلى”، أحياناً أفضل أنواع النمو يكون “في العمق”. 🚀
