مسارنا المهني كان حيط مسدود: كيف أنقذنا ‘السلم المزدوج’ من جحيم فقدان كبار المطورين؟

يا جماعة الخير، السلام عليكم ورحمة الله وبركاته، معكم أخوكم أبو عمر.

قبل كم سنة، كان عندي زميل وصديق اسمه “خالد”، الله يسهل عليه وين ما كان. خالد هاد ما كان مجرد مبرمج، كان فنان، ساحر كود بمعنى الكلمة. كان إذا مسك مشكلة معقدة، يحللها ويفكفكها بطريقة تخليك صافن وتحكي “كيف خطرت بباله هاي؟”. كان هو الشخص اللي كل الفريق يرجعله لما يوصلوا لحيط مسدود في الكود. باختصار، كان العمود الفقري التقني للفريق.

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

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

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

ما هو “الحيط المسدود” في المسار المهني التقليدي؟

في معظم الشركات، المسار المهني للمطور هو خط مستقيم واحد، أو خلينا نحكي “شارع باتجاه واحد”:

  1. مطور مبتدئ (Junior Developer)
  2. مطور متوسط (Mid-level Developer)
  3. مطور خبير (Senior Developer)
  4. — الحيط المسدود —
  5. قائد فريق (Team Lead)
  6. مدير تقني (Engineering Manager)
  7. مدير قسم (Director) وهكذا…

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

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

  • يصبح مديرًا سيئًا: فيفشل في تحفيز فريقه، ويدمر معنوياتهم، ويخلق بيئة عمل سامة.
  • يصاب بالإحباط: يشعر بأنه بعيد عن شغفه الحقيقي، فتقل إنتاجيته ويصبح غير سعيد في عمله.
  • يترك الشركة: كما فعل صديقي خالد، يبحث عن مكان آخر يقدر مهاراته التقنية دون إجباره على الإدارة.

في كل الحالات، الشركة هي الخاسر الأكبر. خسرت خبيرًا تقنيًا لامعًا، وربما كسبت مديرًا فاشلًا. شو الفايدة؟

الحل السحري: السلم الوظيفي المزدوج (Dual-Career Ladder)

تخيل معي أننا بدلًا من هذا الشارع ذي الاتجاه الواحد، بنينا طريقًا سريعًا بمسارين متوازيين. هذا بالضبط هو مفهوم السلم المزدوج.

شو هو السلم المزدوج بالضبط يا أبو عمر؟

ببساطة، هو هيكل وظيفي يوفر مسارين مهنيين متوازيين ومتساويين في القيمة والتقدير والرواتب:

  1. المسار الإداري (Managerial Track): هذا المسار مخصص للأشخاص الذين يجدون شغفهم في قيادة الفرق، وتطوير الأفراد، والتخطيط الاستراتيجي، وإدارة المشاريع. هؤلاء هم قادة المستقبل.
  2. المسار الفردي/التقني (Individual Contributor – IC Track): هذا المسار مخصص للخبراء التقنيين أمثال خالد، الذين يريدون تعميق خبراتهم الفنية، وحل المشاكل الأكثر تعقيدًا، وقيادة الابتكار التقني في الشركة دون تحمل مسؤوليات إدارية مباشرة.

الكلمة المفتاحية هنا هي “متساويين”. هذا يعني أن منصب “Principal Engineer” في المسار التقني يجب أن يكون معادلًا لمنصب “Engineering Manager” في المسار الإداري من حيث الراتب، التأثير في اتخاذ القرار، والاحترام داخل الشركة.

مثال عملي: كيف يبدو السلم المزدوج على أرض الواقع؟

دعنا نرسم الهيكل بشكل أوضح. بعد مستوى الـ “Senior Developer”، يتفرع الطريق:


Junior Developer
      |
Mid-level Developer
      |
Senior Developer
      |
      +-------------------------+-------------------------+
      |                                                 |
  --- المسار التقني (IC) ---                       --- المسار الإداري (Management) ---

Staff Engineer                                    Engineering Manager I
      |                                                 |
Principal Engineer                                Engineering Manager II
      |                                                 |
Distinguished Engineer                            Director of Engineering
      |                                                 |
Fellow Engineer                                   VP of Engineering

ملاحظة مهمة: المسميات تختلف من شركة لأخرى، لكن الفكرة هي نفسها. الأهم هو وجود مسار واضح للنمو التقني يوازي النمو الإداري.

مسؤوليات كل مسار تكون مختلفة ولكن متكاملة. مثلًا:

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

الاثنان يعملان معًا جنبًا إلى جنب لتحقيق هدف واحد، كلٌ من زاويته وخبرته.

فوائد السلم المزدوج: ليش لازم كل شركة تقنية تتبناه؟

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

للموظفين: حرية الاختيار والنمو الحقيقي

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

للشركة: الاحتفاظ بالخبرات ومنع “نزيف العقول”

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

نصائح أبو عمر العملية لتطبيق السلم المزدوج بنجاح

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

نصيحة 1: المساواة هي الأساس، من الآخر!

إذا كان المسار التقني يُنظر إليه على أنه “درجة ثانية” أو أن رواتبه أقل، فلقد فشلت بالكامل. يجب أن تكون الرواتب، والمكافآت، والتقدير، والتأثير متساوية تمامًا بين المسارين المتقابلين. الـ Principal Engineer يجب أن يكون له صوت مسموع في القرارات الاستراتيجية تمامًا مثل الـ Director.

نصيحة 2: حدد المسؤوليات بوضوح (ماذا يفعل الـ Staff Engineer طوال اليوم؟)

هذا سؤال مهم جدًا. يجب أن يكون هناك وثيقة واضحة (Career Ladder Document) تشرح بالتفصيل ما هي التوقعات والمسؤوليات لكل مستوى في كل مسار. مثلًا:

  • Senior Engineer: يمتلك نظامًا أو خدمة بالكامل، يقدم حلولًا لمشاكل معقدة داخل فريقه.
  • Staff Engineer: تأثيره يمتد عبر عدة فرق، يقود مبادرات تقنية كبيرة، يحدد المعايير التقنية، ويوجه عددًا من الـ Seniors.
  • Principal Engineer: تأثيره على مستوى القسم أو الشركة كلها، يحل المشاكل التي لا يوجد لها حل واضح، يبتكر، ويضع الرؤية التقنية لـ 3-5 سنوات قادمة.

نصيحة 3: المرونة في التنقل بين المسارين

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

نصيحة 4: ابدأ صغيرًا وتطور تدريجيًا

لست بحاجة لبناء سلم من 10 درجات من اليوم الأول. إذا كانت شركتك صغيرة أو متوسطة، ابدأ بتعريف أول مستوى بعد الـ Senior في المسار التقني، وليكن “Staff Engineer”. عندما تنمو الشركة وتصبح الحاجة ملحة، يمكنك إضافة مستويات أعلى مثل “Principal”. المهم هو أن تبدأ وتضع الأساس.

الخلاصة: لا تجبروا الصقور على السباحة! 🦅

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

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

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

أبو عمر

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

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

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

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

آخر المدونات

أتمتة العمليات

إشعاراتنا كانت ضجيجاً والمهام تتطلب التنقل بين ألف شاشة: كيف أنقذنا ChatOps من جحيم الفوضى التشغيلية؟

أشارككم تجربتي كـ"أبو عمر"، مبرمج فلسطيني، في تحويل فوضى الإشعارات والتنقل بين الأنظمة إلى بيئة عمل منظمة وفعالة باستخدام ChatOps. اكتشفوا كيف أتمتنا عملياتنا، ووفرنا...

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

شروطنا المتشعبة كانت متاهة: كيف أنقذتنا ‘شروط الحماية’ (Guard Clauses) من جحيم الـ if-else المتداخل؟

هل تعاني من تداخل الشروط في الكود؟ أشاركك قصة حقيقية وكيف غيّرت 'شروط الحماية' (Guard Clauses) طريقة كتابتي للكود، محولةً المتاهات المعقدة إلى مسارات واضحة...

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

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

أشارككم قصة حقيقية من تجربتي كـ "أبو عمر" المبرمج، وكيف كانت خدماتنا على وشك الانهيار بسبب التشابك والاعتمادية. اكتشفوا معنا كيف كانت "المعمارية الموجهة بالأحداث"...

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

قرارات نموذجنا كانت صندوقاً أسود: كيف أنقذتنا تقنيات التفسير (XAI) من جحيم التنبؤات الغامضة؟

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

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

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

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

12 أبريل، 2026 قراءة المزيد
تجربة المستخدم والابداع البصري

تطبيقنا كان حصناً منيعاً: كيف أنقذتنا ‘معايير الوصول الرقمي (WCAG)’ من جحيم الإقصاء الرقمي؟

أشارككم قصة حقيقية حول كيف أدركنا أن تطبيقنا "المثالي" كان يقصي شريحة كبيرة من المستخدمين. هذه المقالة هي رحلتنا في فهم وتطبيق معايير الوصول الرقمي...

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