التقدير والمكافآت Recognition: ما الذي يحفز المهندسين؟

في ليلة خميس توقفت قاعدة البيانات Database في شركة ناشئة تبيع نظام نقاط بيع Point of Sale للمطاعم، وكان عمر في المناوبة On-call، فاستيقظ على التنبيه Alert الساعة الثالثة فجراً، وقضى ساعتين حتى وجد أن القرص امتلأ بسبب سجلات Logs لم تنظف منذ أشهر، فحرر المساحة وأعاد الخدمة قبل أن تفتح المطاعم أبوابها للإفطار، ثم كتب تقريراً قصيراً في قناة الفريق Channel ونام. وفي صباح الأحد كتب المدير التنفيذي CEO في مجموعة الشركة: «شكراً للجميع على أسبوع رائع، ومبروك لفريق المبيعات Sales على عقد سلسلة المطاعم الجديدة»، وأعلن في نفس الرسالة مكافأة لمندوب المبيعات الذي أغلق العقد. ولم يذكر أحد عطل الخميس، ولم يعرف أغلب الشركة أنه حدث أصلاً، مع أن العقد الجديد نفسه كان سيتأخر لو فتحت المطاعم صباح الجمعة ونظام الكاشير لا يعمل.

عمر لم يغضب، ولم يشتك، ولكنه في المناوبة التالية ترك هاتفه على الصامت ساعة، وقال لزميله في الغداء: «اللي يشتغل بالليل ما أحد يدري عنه، واللي يبيع ياخذ مكافأة». وبعد شهر جاء المدير التقني CTO الجديد للشركة، وأول ما لاحظه في الاجتماعات الفردية One-on-One أن المهندسين لا يشتكون من الراتب بقدر ما يشتكون من أن أحداً لا يرى ما يفعلونه. وهذا المقال عن ما فعله بعد ذلك، وعن السؤال الذي يواجهه كل قائد تقني: ما الذي يحفز المهندسين فعلاً، وأين يكفي الشكر المحدد، وأين يحتاج الأمر مالاً أو ترقية، وكيف تقدر العمل الذي لا يراه أحد.

وسوف نناقش في هذا المقال ما يلي:

• لماذا لا يكفي الراتب وحده، وما قاله Herzberg عن عوامل الرضا وعوامل التحفيز.
• ما الذي يحرك العمل المعرفي من الداخل، وما وجدته Teresa Amabile عن التقدم اليومي.
• الفرق بين التقدير Recognition والمكافأة Reward، وسلم الخيارات من المجاني إلى المكلف.
• ما تقوله بيانات Gallup عن التقدير، وكيف تكتب تقديراً محدداً يقنع صاحبه.
• تقدير الزملاء Peer Recognition كما تطبقه GitLab، والمكافآت الفورية Spot Bonus وما يقوله نظام العمل عنها.
• الترقية Promotion كتقدير وفخاخها، والعمل غير المرئي Invisible Work، والتقدير العلني والخاص.
• ميزانية التقدير للـ CTO، وثلاث حالات من شركة ناشئة وشركة متوسطة وجهة شبه حكومية، وأداة شهرية تشغلها بنفسك.

لماذا لا يكفي الراتب؟ نظرية العاملين Two-Factor Theory

في الخمسينات والستينات سأل عالم النفس Frederick Herzberg مهندسين ومحاسبين عن أوقات شعروا فيها برضا شديد عن عملهم، وأوقات شعروا فيها باستياء شديد، ثم نشر خلاصة ما وجده في مقال شهير بعنوان «مرة أخرى: كيف تحفز موظفيك؟» في مجلة Harvard Business Review عام 1968، وأعادت المجلة نشره عام 2003 في نسخة لا تزال متاحة. والملاحظة التي جعلت المقال من أكثر ما يقرأ في الإدارة أن الأشياء التي تصنع الرضا ليست عكس الأشياء التي تصنع الاستياء، وإنما مجموعتان مختلفتان.

المجموعة الأولى سماها Herzberg عوامل الصحة Hygiene Factors، وهي الراتب وسياسة الشركة والإشراف وظروف العمل والعلاقة مع المدير والأمان الوظيفي. وهذه العوامل إذا ساءت صنعت استياء، وإذا تحسنت أزالت الاستياء، ولكنها لا تصنع حماساً. والمجموعة الثانية سماها المحفزات Motivators، وهي الإنجاز والتقدير على الإنجاز والعمل نفسه والمسؤولية والتقدم والنمو. وهذه العوامل هي التي تصنع الرغبة في العمل، وغيابها لا يصنع غضباً بالضرورة، وإنما يصنع فتوراً.

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

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

ما الذي يحرك العمل المعرفي؟ الدافع الداخلي Intrinsic Motivation

في محاضرته المعروفة في TED عام 2009 عرض الكاتب Dan Pink فكرة كتابه Drive: أن المكافآت المشروطة من نوع «إذا فعلت كذا تأخذ كذا» تعمل جيداً في المهام البسيطة المحددة، ولكنها في المهام التي تحتاج تفكيراً وإبداعاً قد لا تساعد، بل قد تضر، لأنها تضيق تركيز الإنسان على المكافأة. واستند في ذلك إلى تجارب في علم النفس، أشهرها تجربة الشمعة Candle Problem، التي احتاج فيها المشاركون حلاً غير مباشر، وكان أداء من وعدوا بمكافأة مالية فيها أبطأ في بعض نسخها. واقترح Pink ثلاثة عناصر للدافع الداخلي: الاستقلالية Autonomy، أي أن تتحكم في كيف تعمل، والإتقان Mastery، أي أن تتحسن في شيء يهمك، والهدف Purpose، أي أن تعرف لماذا تعمل.

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

والدليل الأقرب للعمل اليومي جاء من Teresa Amabile وSteven Kramer، اللذين طلبا من 238 موظفاً في فرق تعمل على مشاريع إبداعية ومعرفية أن يكتبوا يوميات عن يومهم في العمل، وجمعا قرابة 12 ألف مدخل، ونشرا الخلاصة في مقال «قوة الانتصارات الصغيرة» The Power of Small Wins في Harvard Business Review عام 2011. ووجدا أن أهم ما يرفع حماس الناس ومشاعرهم في يوم العمل هو أن يحرزوا تقدماً في عمل له معنى، حتى لو كان التقدم صغيراً، وسميا ذلك مبدأ التقدم Progress Principle. وأهم من ذلك، كما يروي ملخص البحث في موقع Harvard Business School، أنهما طلبا من 669 مديراً أن يرتبوا خمسة عوامل تحفز الموظفين، فوضعوا التقدير على العمل الجيد في المرتبة الأولى، وجاء دعم التقدم في آخر القائمة، ولم يضعه في المرتبة الأولى إلا 35 مديراً، أي نحو 5%.

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

التقدير Recognition أم المكافأة Reward: ما الفرق؟

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

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

والشكل أعلاه يرتب الخيارات من الأقل تكلفة إلى الأعلى، والفكرة أن تستخدم كل درجة لما يناسبها. فالدرجات الثلاث الأولى، أي الشكر المحدد في الاجتماع الفردي، والشكر العلني في القناة، والرسالة لمدير المدير Skip-level Manager، هي التقدير اليومي الذي يجب أن يحدث كل أسبوع تقريباً. والدرجة الرابعة، أي الفرصة، من أقوى أنواع التقدير عند المهندسين وأقلها استخداماً، لأن أن تطلب من مهندس أن يعرض عمله في اجتماع الشركة، أو أن يقود التصميم التالي، أو أن يمثل الفريق أمام عميل، تقول له إنك تثق فيه أكثر مما تقوله أي رسالة. والدرجة الخامسة، أي الوقت، مناسبة جداً بعد عمل مرهق، لأن يوم الراحة بعد ليلة المناوبة يعالج التعب نفسه. والدرجتان الأخيرتان للمال والمستوى، ولكل منهما قسم مستقل في هذا المقال.

ماذا تقول بيانات Gallup عن التقدير؟ (Recognition Data)

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

وفي نفس التقرير سؤال أهم للقائد: من أين يأتي التقدير الذي يتذكره الناس أكثر؟ والإجابات، كما يعرضها الشكل التالي، أن أكثر تقدير لا ينسى يأتي من المدير المباشر بنسبة 28%، ثم من قائد في الإدارة العليا أو المدير التنفيذي بنسبة 24%، ثم من مدير المدير بنسبة 12%، ثم من عميل بنسبة 10%، ثم من الزملاء بنسبة 9%، و17% ذكروا مصادر أخرى.

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

ولاحظ حدود هذه البيانات: هي من موظفين في الولايات المتحدة، ومن استبيانات Gallup، ولا توجد بيانات منشورة بنفس الحجم عن الفرق التقنية في المنطقة العربية. ولكن الملاحظة الأساسية، أن التقدير قليل وأن غيابه يرتبط بنية المغادرة، تتسق مع ما يسمعه أي مدير في الاجتماعات الفردية، وهي سبب كاف لأن تجعل التقدير عادة أسبوعية وليس حدثاً سنوياً.

التقدير المحدد Specific Recognition: كيف تكتبه؟

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

وهذه الرسالة التي كتبها الـ CTO الجديد في قناة الشركة، بعد أن عرف القصة في اجتماعه الفردي مع عمر، بعد شهر من الحادثة:

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

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

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

تقدير الزملاء Peer Recognition: ماذا تفعل GitLab؟

القائد لا يرى كل شيء، والزملاء يرون أكثر منه، فهم من يعرف من شرح لهم الكود القديم، ومن راجع طلب الدمج Pull Request في منتصف الليل قبل الإطلاق، ومن أخذ مناوبة بدل زميل مريض. ولذلك تبني شركات كثيرة قناة لتقدير الزملاء، وأوضح مثال منشور هو دليل GitLab المفتوح، الذي يشرح في صفحة الحوافز Incentives كيف تعمل المكافآت التقديرية Discretionary Bonuses عندهم.

وحسب الصفحة كما قرأناها في أكتوبر 2026، المكافأة التقديرية في GitLab مكافأة من زميل لزميل على عمل استثنائي يتجاوز توقعات الدور، ومبلغها ثابت 1000 دولار بسعر الصرف المحلي. ويستطيع أي موظف أن يرشح أي زميل، حتى من خارج فريقه، ولا يجوز أن يرشح نفسه، ولا أن يرشح مديره أو أحداً في سلسلة إدارته. ويمر الترشيح على المدير المباشر للمرشح ليتأكد أن العمل استثنائي فعلاً وخارج الدور، ثم على مدير المدير، ثم على فريق الموظفين People Operations، ثم ينشر في قناة #thanks في Slack مع ذكر القيمة التي ظهرت في العمل. وتقول الصفحة إن الإرشاد التقريبي أن يحصل عليها قرابة واحد من كل عشرة موظفين في الشهر، وإن هذا ليس حصة مطلوبة، وإن المكافآت يجب أن توزع بتفكير وألا تتركز في نفس الأشخاص. وفيها كذلك مكافأة لمجموعات العمل Working Group Bonus بمبلغ 100 دولار للشخص، وتذكر الصفحة أن قناة #thanks نفسها متاحة لتقدير أي أحد بدون مكافأة.

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

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

المكافأة الفورية Spot Bonus: متى يكون المال صحيحاً؟

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

وهناك ثلاث قواعد تجعل المكافأة الفورية تعمل. الأولى أن تكون لاحقة وغير موعودة، فلا تقل للفريق «إذا سلمنا قبل نهاية الشهر لكم مكافأة»، لأن هذا يحول التسليم إلى صفقة، ويدفع الفريق إلى تجاوز الاختبارات Tests والمراجعة Code Review ليلحق بالموعد، وإنما تأتي المكافأة بعد العمل كمفاجأة تقول «رأينا ما فعلتم». والثانية أن تأتي مع تقدير مكتوب يقول لماذا، فالمبلغ بلا سبب لا يعلم أحداً شيئاً. والثالثة أن توزع بعدل، فإذا أخذها نفس الشخص ثلاث مرات في السنة، فإما أنه يعمل فوق مستواه ويحتاج ترقية، وإما أن نظامك لا يرى غيره.

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

وماذا عن المكافأة السنوية Annual Bonus المرتبطة بأداء الشركة أو بالتقييم؟ هذه أداة تعويض Compensation أكثر منها أداة تقدير، وتصميمها قرار للإدارة العليا والموارد البشرية والمالية، ويجب أن يرتبط بتقييم الأداء Performance Review بطريقة يفهمها الجميع. وكيف يكون التقييم نفسه عادلاً موضوع مقالات تقييم أداء المطورين في المرحلة السابقة، والنقطة هنا فقط أن المكافأة السنوية لا تغني عن التقدير الأسبوعي، لأنها تأتي متأخرة جداً، ولا يتذكر أحد في ديسمبر ما فعله في مارس.

الترقية Promotion كتقدير: أين الفخ؟

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

والفخ الثاني أن تكون الإدارة هي الطريق الوحيد للترقية، فيرقى أفضل مهندس في الفريق إلى قائد فريق Team Lead أو مدير هندسة Engineering Manager لأنه لا يوجد مكان آخر يرتفع فيه، فتخسر مهندساً ممتازاً وتكسب مديراً لا يريد الإدارة. والحل المعروف أن يكون في السلم الوظيفي مسار تقني موازي Individual Contributor Track، فيه مستويات مثل مهندس أول ثم مهندس رئيسي Staff Engineer، بنفس الراتب والاحترام الذي يأخذه المسار الإداري. وإذا لم يكن في شركتك هذا المسار، فقبل أن تعرض على مهندس دوراً إدارياً اسأله بصراحة: هل تريد أن تدير أشخاصاً، أم تريد التقدير والراتب؟

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

العمل غير المرئي Invisible Work: من يقدر المناوبة والمراجعة؟

في كل فريق تقني عمل يراه الجميع، مثل ميزة جديدة تعرض أمام العميل أو إطلاق يحتفل به في قناة الشركة، وعمل لا يراه إلا من يقوم به، مثل المناوبة On-call، ومراجعة الكود Code Review، وتوجيه المنضمين الجدد Mentoring، وكتابة التوثيق Documentation، والمشاركة في مقابلات التوظيف Interviews، وإصلاح الدين التقني Technical Debt الذي يمنع الأعطال قبل أن تحدث. والعمل الثاني هو ما يجعل الأول ممكناً، ولكن أنظمة التقدير التي تعتمد على ما يرى في العروض والقنوات تكافئ الأول فقط، فيتعلم الفريق مع الوقت أن الطريق للتقدير هو بناء الميزات، ويترك الباقي لمن لا يستطيع أن يقول لا.

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

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

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

التقدير العلني Public أم الخاص Private؟

التقدير العلني له فائدتان لا يعطيهما الخاص: أنه يبني سمعة الشخص عند من لا يعرفه، وأنه يعلم الفريق ما الذي تقدره الشركة. فحين يكتب الـ CTO في قناة الشركة عن ليلة عمر، يتعلم كل المهندسين أن المناوبة عمل محترم، ويتعلم فريق المبيعات أن الكاشير الذي يعمل صباح الجمعة لم يأت من فراغ. ولكن التقدير العلني له مخاطر كذلك، فبعض الناس يحرجهم أن يذكروا أمام الجميع، وبعضهم يخاف أن يبدو أمام زملائه كأنه «المفضل عند المدير»، وفي بعض الفرق يصنع الشكر العلني لشخص واحد حساسية عند من عمل معه ولم يذكر.

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

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

ميزانية التقدير Recognition Budget: كم يحتاج الـ CTO؟

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

ولاحظ في الجدول ثلاثة أشياء. الأول أن أكبر بند هو التعلم، لأنه يجمع بين التقدير والإتقان الذي تحدث عنه Pink، فقسيمة دورة أو تذكرة مؤتمر بعد مشروع جيد تقول للمهندس «نستثمر فيك»، وهي في نفس الوقت تعود على الفريق بمهارة جديدة. والثاني أن بند الوقت بلا مبلغ، لأنه يكلف الشركة يوم عمل وليس مالاً، ويحتاج فقط أن يكون للقائد صلاحية منحه دون إجراءات طويلة، وأن يتفق مع الموارد البشرية على كيف يسجل. والثالث أن لكل بند صاحباً، حتى لا يحتاج كل صرف صغير إلى الـ CTO، وحتى يعرف كل قائد ما يستطيع أن يفعله بدون أن يسأل.

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

الحالة الأولى: CTO في شركة ناشئة بلا ميزانية (Startup, No Budget)

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

ماذا يحدث عادة، وما الذي يزيده سوءاً؟ (Usual and Worse)

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

ما الذي ينجح؟ (What Works)

الذي ينجح أن يبدأ القائد بالدرجات المجانية من السلم، وأن يجعلها عادة وليست مبادرة. فخصص الـ CTO عشر دقائق في آخر اجتماع الفريق الأسبوعي لسؤال واحد: «من ساعدك هذا الأسبوع، أو من شفت شغله يستحق يذكر؟»، وبدأ هو أولاً كل أسبوع بمثال محدد. وكتب رسالة شهرية قصيرة للمدير التنفيذي فيها ثلاثة أعمال من الفريق بالأسماء والأثر، وطلب منه أن يرد على واحد منها على الأقل في قناة الشركة، فصار التقدير من الإدارة العليا يصل بدون أي تكلفة. وأعطى عمر الفرصة التي لا تكلف شيئاً: أن يعرض في اجتماع الشركة الشهري ما حدث ليلة الخميس وما تغير بعدها، فعرف الجميع القصة من صاحبها.

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

عبارات تقولها (What to Say)

للمدير التنفيذي، حين يقول إن الميزانية غير متاحة:

«ما أطلب فلوس الحين. أطلب منك شي واحد: كل شهر بأرسل لك ثلاثة أشياء سواها الفريق، رد على واحد منها في قناة الشركة بجملة. ردك يفرق معهم أكثر من أي هدية.»

لعمر، في الاجتماع الفردي، بعد أن عرف القصة:

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

وللفريق، بدل الوعد بمكافآت بعد الجولة:

«ما أقدر أوعدكم بمكافآت الحين، وما أبغى أوعد بشي ما أضمنه. اللي أقدر أوعد فيه إن الشغل الزين بينذكر، وإن أول ميزانية تجينا بتروح للتعلم وتختارونها أنتم.»

الحالة الثانية: موظف الشهر Employee of the Month يأتي بنتيجة عكسية

شركة تقنية متوسطة الحجم فيها قرابة 150 موظفاً، منهم 40 مهندساً في خمسة فرق، أطلقت فيها الموارد البشرية HR برنامج «موظف الشهر»: كل مدير يرشح شخصاً، ولجنة تختار واحداً للشركة كلها، وصورته تعرض على شاشة الاستقبال مع قسيمة بمبلغ جيد. وبعد ستة أشهر لاحظ مدير الهندسة Engineering Manager أن البرنامج صار موضوع سخرية في قنوات المهندسين، وأن خمسة من الستة الذين فازوا كانوا من فرق تعمل على المنتج الظاهر للعملاء، وأن فريق البنية التحتية Infrastructure لم يرشح منه أحد، وأن مهندساً قوياً في ذلك الفريق قال في اجتماعه الفردي: «الجائزة لمن يطلع في العرض، مو لمن يشغل النظام».

ماذا يحدث عادة، وما الذي يزيده سوءاً؟ (Usual and Worse)

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

ما الذي ينجح؟ (What Works)

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

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

عبارات تقولها (What to Say)

لمسؤول الموارد البشرية:

«البرنامج فكرته زينة، والمشكلة إن الهندسة شغلها جماعي وكثير منه ما ينشاف. هذي أسماء الفائزين من أول السنة، وهذا اللي يقوله فريق البنية. أقترح نجرب معاه نظام ترشيح بين الزملاء في الهندسة ثلاثة أشهر، ونرجع نشوف الأرقام سوا.»

للمهندس الذي قال إن الجائزة لمن يظهر في العرض:

«معك حق في جزء كبير، وأنا ما كنت أشوف شغل فريقكم زين. اللي سويته في ترحيل قاعدة البيانات الشهر الماضي يستحق يذكر، وبرشحك أنا أول واحد في النظام الجديد. وأبغى رأيك في نموذج الترشيح قبل ما نطلقه.»

الحالة الثالثة: جهة شبه حكومية برواتب ثابتة (Fixed Pay Scales)

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

ماذا يحدث عادة، وما الذي يزيده سوءاً؟ (Usual and Worse)

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

ما الذي ينجح؟ (What Works)

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

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

عبارات تقولها (What to Say)

للمهندستين:

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

لمدير الإدارة، عند طلب التوقيع:

«الخدمة طلعت في الموعد اللي طلبته الإدارة العليا، وهذا بسبب ثلاثة أسابيع شغل متواصل من المهندستين. توقيعك على الخطاب يوصل لهم إن الإدارة شافت اللي سووه، وهذا أهم شي نقدر نعطيه لهم الحين.»

أخطاء شائعة Common Mistakes

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

الأداة: خطة التقدير وفحص التوزيع (Recognition Plan)

الأداة العملية في هذا المقال جزءان. الأول ملف lab/recognition-plan.md، وفيه ميزانية السنة بالبنود كالجدول السابق، وصيغة التقدير المحدد، ونموذج ترشيح زميل بقواعده، وأسئلة المراجعة الشهرية، وقائمة تحقق قبل أي ترقية. والثاني سكربت Python صغير، lab/recognition_check.py، يقرأ سجل التقدير من ملف CSV ويعرض من يأخذ التقدير، وعلى أي نوع من العمل، ومن مصدره، ومن لم يقدر منذ فترة. والفكرة أن القائد لا يستطيع أن يرى توزيع التقدير من ذاكرته، لأن الذاكرة تتذكر من يتحدث في الاجتماعات، فيحتاج سجلاً بسيطاً يكتب فيه سطراً عن كل تقدير، ثم يراجعه كل شهر.

والسجل ملف CSV فيه ستة أعمدة: التاريخ، ومن أخذ التقدير، ومن أعطاه، ونوع المصدر (زميل أو مدير أو قائد أعلى)، ونوع العمل، وملاحظة قصيرة. وهذا جزء من السجل الذي كتبه الـ CTO في الشركة الناشئة لثلاثة أشهر، والأسماء فيه أمثلة:

date,to,from,kind,category,note
2026-07-02,سارة,خالد,peer,feature,أنهت شاشة الطلبات قبل العرض للعميل
2026-07-09,فهد,نورة,peer,review,راجع 14 طلب دمج Pull Request في أسبوع الإطلاق
2026-07-20,عمر,المدير,manager,oncall,أصلح عطل قاعدة البيانات في المناوبة On-call الساعة 3 فجراً
2026-08-03,نورة,فهد,peer,mentoring,دربت المتدربين على كتابة الاختبارات

وملف team.txt فيه أسماء الفريق، اسم في كل سطر، لأن السكربت يحتاج أن يعرف من في الفريق حتى يجد من لم يذكر في السجل أصلاً، وهذا أهم ما يبحث عنه. وشغلناه بـ Python 3.13 بهذا الأمر:

python -I recognition_check.py recognition-log.csv team.txt 2026-09-30

واستخدمنا الخيار -I لأنه يشغل Python في وضع معزول لا يقرأ ملفات من مجلد السكربت ولا متغيرات البيئة. وهنا ظهرت أول مشكلة: في أول تشغيل على Windows توقف السكربت بخطأ UnicodeEncodeError: 'charmap' codec can't encode characters عند أول اسم عربي. والسبب أن طرفية Windows تستخدم ترميز cp1252 افتراضياً، والحل المعتاد أن تضبط المتغير PYTHONIOENCODING=utf-8، ولكن الوضع المعزول -I يتجاهل متغيرات البيئة التي تبدأ بـ PYTHON، فلم ينفع. ولذلك أضفنا في أول السكربت سطراً يضبط ترميز المخرجات بنفسه، sys.stdout.reconfigure(encoding="utf-8")، فصار يعمل في أي طرفية. وهذا ما طبعه:

recognitions: 13 from 2026-07-02 to 2026-09-22

per person:
  سارة    7   54%  #######
  خالد    2   15%  ##
  عمر     2   15%  ##
  فهد     1    8%  #
  نورة    1    8%  #
  ريم     0    0%

warning: سارة has 54% of all recognition

per category:
  feature     9
  oncall      2
  review      1
  mentoring   1
  docs        0   <- never recognised
  interviews  0   <- never recognised

by source:
  peer      7
  manager   4
  leader    2

no recognition since 2026-08-01: فهد, ريم

ولنقرأ المخرجات جزءاً جزءاً:

• السطر الأول يقول إن في السجل 13 تقديراً خلال قرابة ثلاثة أشهر، أي قرابة تقدير واحد مسجل في الأسبوع لفريق من ستة، وهذا أقل بكثير من توصية Gallup بتقدير لكل شخص كل سبعة أيام تقريباً، وهو أول ما يجب أن يلاحظه القائد.
• قسم per person يرتب الفريق حسب عدد مرات التقدير، مع النسبة وشريط بسيط. وسارة أخذت 7 من 13، أي 54%، وريم لم تذكر مرة واحدة. والسكربت يطبع تحذيراً إذا أخذ شخص واحد أكثر من 35% من كل التقدير، وهذا الحد اختيار منا يمكنك تغييره، والفكرة أنه في فريق من ستة، إذا كان التوزيع متساوياً، يأخذ كل شخص قرابة 17%.
• قسم per category يعد أنواع العمل، ثم يذكر أنواع العمل غير المرئي التي لم تقدر أبداً. وهنا 9 من 13 تقديراً على ميزات، والتوثيق Documentation ومقابلات التوظيف Interviews صفر. وهذا بالضبط جبل الجليد الذي رأيناه في الشكل السابق.
• قسم by source يقول من أين يأتي التقدير: 7 من الزملاء، و4 من المدير المباشر، و2 من القيادة. وهذا توزيع جيد نسبياً، لأن التقدير لا يأتي من القائد وحده.
• السطر الأخير يذكر من لم يقدر خلال آخر 60 يوماً، وهما فهد وريم. وفهد قدر مرة في يوليو على مراجعة 14 طلب دمج، ثم لم يذكر، وريم لم تذكر أبداً، مع أنها هي من كانت تجري أغلب المقابلات التقنية.

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

وماذا يحدث إذا قصرنا النافذة إلى 30 يوماً؟ السكربت يقبل عدد الأيام كمعامل رابع اختياري، فشغلناه مرة ثانية بـ 30 يوماً:

python -I recognition_check.py recognition-log.csv team.txt 2026-09-30 30

no recognition since 2026-08-31: فهد, نورة, ريم

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

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

قائمة تحقق Checklist

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

دليلكيف تقيم أداء المطورين Developer Performance دون قياس الأشياء الخطأ؟ماذا تقيس في أداء المطور والفريق، ولماذا تضلل أرقام مثل عدد الأسطر وطلبات الدمج، وكيف تقلل تحيز من يقيم.دليلدورة تقييم الأداء Performance Review Cycle: متى وكيف تقيم؟كيف ترتب تقييم فريقك على مدار السنة، من اجتماع 1:1 والأهداف إلى المعايرة وخطة تحسين الأداء، مع قوالب جاهزة.دليلمدير يحبطك: الإدارة الدقيقة Micromanagement والتجاهلكيف تتعامل مع مدير يراقب كل سطر أو يتجاهلك أو ينتقدك أمام الفريق، بعبارات تقولها ومذكرة أسبوعية تعيد لك قراراتك.دليلالاحتراق الوظيفي Burnout عند المبرمجين: العلامات والأسبابما تقوله منظمة الصحة العالمية عن الاحتراق الوظيفي، ومن أين يأتي في الفرق التقنية، وما يفعله المهندس لنفسه وقائد الفريق لفريقه.دليلالأمان النفسي Psychological Safety: ما وجدته Googleما معنى الأمان النفسي كما عرفته Edmondson، ولماذا كان أهم عامل في فعالية فرق Google، وكيف تقيسه في فريقك وتبنيه بسلوك يومي.دليلتقييم أداء تراه ظالماً Performance Review: كيف تعترض؟ماذا تفعل في الأيام الأولى بعد تقييم لا يعكس سنتك، وكيف تعترض بالأدلة دون أن تخسر علاقتك بمديرك، ومتى يكون التقييم عادلاً.

الخلاصة (Summary)

وصلنا لنهاية الموضوع، وأهم ما فيه:

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

سجل التحديثات (Changelog)

• أكتوبر 2026: كتابة المقال، والتحقق من مقال Herzberg في Harvard Business Review، ومحاضرة Dan Pink في TED، ومقال Amabile وKramer عن الانتصارات الصغيرة، وتقرير Gallup عن التقدير، وصفحة الحوافز في دليل GitLab، وتعريف الأجر الفعلي في المادة الثانية من نظام العمل، وتشغيل أداة فحص توزيع التقدير بـ Python 3.13، بتاريخ 31 أكتوبر 2026.