المسار المزدوج: كيف تحتفظ بأفضل مبرمجيك وتتجنب كارثة الإدارة؟

حكاية “سالم”.. المبرمج العبقري الذي كره الإدارة

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

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

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

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

من هداك اليوم، بدأ مسارنا الحقيقي نحو فهم وتطبيق ما يسمى بـ “المسار الوظيفي المزدوج”.

المعضلة الكلاسيكية: طريق واحد نحو القمة (الإدارية!)

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

“إذا أردت راتبًا أعلى ومنصبًا أرفع، عليك أن تتوقف عن فعل ما تجيده (البرمجة) وتبدأ بفعل شيء قد لا تجيده أبدًا (إدارة الناس).”

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

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

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

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

تخيل أن المسار الوظيفي ليس سلمًا واحدًا، بل طريق سريع بمسارين:

المسار الأول: مسار القادة (Management Track)

هذا هو المسار التقليدي المألوف. هو مخصص للأشخاص الذين يجدون شغفهم في قيادة الفرق، تطوير الأفراد، التخطيط الاستراتيجي، وإدارة المشاريع. تأثيرهم يتمثل في مضاعفة قوة فريقهم (Force Multiplier).

  • الأدوار: Team Lead, Engineering Manager, Director of Engineering, VP of Engineering.
  • المهارات الأساسية: التواصل، التوظيف، تقييم الأداء، إدارة المشاريع، التخطيط والميزانية، حل النزاعات.
  • مقياس النجاح: نجاح الفريق، رضا الموظفين، تحقيق أهداف المشروع.

المسار الثاني: مسار الخبراء التقنيين (Individual Contributor – IC Track)

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

  • الأدوار: Senior Engineer, Staff Engineer, Principal Engineer, Distinguished Engineer.
  • المهارات الأساسية: تصميم الأنظمة (System Design)، البرمجة المتقدمة، تحليل المشاكل المعقدة، التوجيه التقني (Mentorship)، الريادة في تبني التقنيات الجديدة.
  • مقياس النجاح: جودة التصميم التقني، حل المشاكل الحرجة، التأثير على خارطة الطريق التقنية للمنتج.

كيف نبني مسارًا مزدوجًا ناجحًا في شركتنا؟

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

1. تحديد المستويات والتوقعات بوضوح (Leveling & Expectations)

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

يمكنك استخدام ملف بسيط لوصف هذه المستويات. إليك مثال مبسط جدًا على شكل الهيكل:


# مثال على هيكل المستويات الوظيفية (Career Ladder)

tracks:
  - name: Management
    levels:
      - level: L5
        title: Engineering Manager I
        scope: إدارة فريق واحد (5-8 أشخاص)، مسؤول عن تسليم المشاريع وتطور أفراد الفريق.
        compensation_band: 5
      - level: L6
        title: Engineering Manager II
        scope: إدارة عدة فرق أو مديرين، مسؤول عن قسم كامل.
        compensation_band: 6

  - name: Individual Contributor (IC)
    levels:
      - level: L5
        title: Staff Engineer
        scope: قيادة تقنية لمشروع كبير يمتد عبر عدة فرق، خبير في مجال معين، توجيه المهندسين الآخرين.
        compensation_band: 5  # لاحظ التوازي في الراتب مع المدير
      - level: L6
        title: Principal Engineer
        scope: تحديد التوجه التقني لقسم كامل، حل أعقد المشاكل التقنية في الشركة، التأثير على استراتيجية المنتج.
        compensation_band: 6  # التوازي مع المدير الأعلى

2. تحقيق المساواة في الرواتب والمكانة (Parity in Compensation & Respect)

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

3. تسهيل الانتقال المرن بين المسارين

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

نصيحة من أبو عمر

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

ثمار المسار المزدوج: لماذا يستحق كل هذا العناء؟

بعد تطبيق هذا النظام، النتائج كانت مذهلة:

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

الخلاصة: ابنِ جسورًا، لا جدرانًا 🚀

في النهاية، المسار الوظيفي التقليدي الذي يجبر الجميع على السير في طريق الإدارة هو بمثابة جدار يعترض طريق المبدعين التقنيين. المسار المزدوج، في المقابل، يبني جسرًا يسمح لهؤلاء المبدعين بالنمو والازدهار في المجال الذي يحبونه، مع منحهم التقدير المادي والمعنوي الذي يستحقونه.

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

أبو عمر

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

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

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

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

آخر المدونات

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

كانت بيانات عملائنا المصرفية سجينة: كيف أنقذتنا ‘المصرفية المفتوحة’ (Open Banking) من جحيم الأنظمة المغلقة؟

أشارككم قصة حقيقية من قلب المعركة البرمجية، كيف انتقلنا من كابوس "كشط الشاشة" والأنظمة المصرفية المغلقة إلى عالم من الإمكانيات بفضل ثورة المصرفية المفتوحة (Open...

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

كانت بنيتنا التحتية تُبنى بالنقرات والأدعية: كيف أنقذنا Terraform من جحيم الإعداد اليدوي؟

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

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

كانت تغطية اختباراتنا 100% لكنها كذبة: كيف أنقذنا “الاختبار الطفري” من جحيم الثقة الزائفة؟

كنا نظن أن تغطية اختبارات بنسبة 100% هي درعنا الواقي، لكنها كانت ثقة زائفة. أشارككم قصة كيف كشف "الاختبار الطفري" (Mutation Testing) ضعف اختباراتنا وأنقذ...

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

كانت بيئة التطوير لدينا كلاً في وادٍ: كيف أنقذتنا ‘حاويات التطوير’ (Dev Containers) من جحيم ‘إنها تعمل على جهازي’؟

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

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

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

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

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

كانت نماذج بياناتنا في حرب أهلية: كيف أنقذ نمط CQRS نظامنا من جحيم تضارب القراءة والكتابة؟

في عالم البرمجيات، تتصارع عمليات القراءة والكتابة على نفس البيانات، مما يخلق فوضى في الأداء والتعقيد. أشارككم قصة حقيقية حول كيف استخدمنا نمط CQRS لفصل...

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