هل فريق التطوير عندك محتاج Developers أكتر أم Technical Leadership أقوى؟

Product متأخرة.

Backlog بتكبر.

Engineers مشغولين، لكن Releases لسه بطيئة.

أول رد فعل طبيعي:

محتاجين Developers أكتر.

أحيانًا ده فعلًا القرار الصح.

لكن أحيانًا زيادة Developers تخلي الوضع أسوأ.

لو Bottleneck الحقيقية هي Priorities غير واضحة، Technical Ownership ضعيفة، Architecture غير مستقرة، Work in Progress كثير، Engineering Management ضعيفة أو Technical Debt متراكمة، Developer جديدة هتكون شخص إضافي يحاول يتحرك داخل نفس System المعطلة.

قبل ما تفتح Engineering Positions جديدة، شخّص هل المشكلة Capacity ولا Leadership.

زيادة الناس مش تلقائيًا معناها Throughput أعلى

Software Development شغل Collaborative.

Engineer جديدة تحتاج Context وAccess ومعرفة بالCodebase وفهم للProduct وDecisions من ناس ثانية.

وفي نفس الوقت تضيف Communication Paths جديدة.

لو System حول Team صحية، الاستثمار ده ممكن ينتج Capacity إضافية.

لو System غير صحية، Hiring ممكن تضخم المشاكل.

السؤال مش:

"Developers عندنا Busy؟"

Busy Team ممكن تظل عندها Effective Capacity ضائعة.

السؤال الأفضل:

إيه اللي مانع Valuable Work تتحرك من Idea إلى Production؟

افصل Demand عن Throughput الأول

أي Product Team تقدر تنتج أفكار أكثر من قدرتها على التنفيذ.

Backlog كبيرة وحدها مش دليل إن Team ناقصة Staff.

اسأل إيه اللي بيحصل لـImportant Item بعد ما الشركة تقرر تنفذها.

بتقضي وقت قد إيه:

• مستنية Requirements؟
• مستنية Technical Decision؟
• في Active Development؟
• مستنية Review؟
• مستنية QA؟
• مستنية Deployment؟
• بترجع لأن Requirements اتغيرت؟
• بترجع لأن Defects ظهرت؟

لو أغلب Elapsed Time Waiting مش Implementation، Hiring Implementers أكثر ممكن ما تضربش Constraint أصلًا.

علامة 1: Developers باستمرار مستنية Decisions

تخيل Engineers بيسألوا باستمرار:

• نستخدم أنهي Approach؟
• Feature دي أعلى Priority ولا الثانية؟
• نقدر نغير Service دي؟
• مين يملك Domain دي؟
• Architecture دي مقبولة؟
• نصلح Root Cause ولا نعمل Patch؟

لو الإجابات تتأخر أو تتغير كثير، Developers مش مقيدة أساسًا بـCoding Capacity.

هي مقيدة بـDecision Latency.

Technical Leadership المفروض تقلل Latency دي عن طريق Ownership وDecision Boundaries واضحة.

علامة 2: كل Developer بتحل Architecture لوحدها

Autonomy مهمة.

Uncoordinated Architecture مش Autonomy.

Warning Signs تشمل:

• أكثر من Pattern لنفس المشكلة.
• Duplicate Services.
• Approaches مختلفة للAuthentication أو Authorization.
• Database Conventions غير متناسقة.
• Dependencies جديدة بدون Ownership واضحة.
• Features تشتغل منفردة لكن تتعارض مع بعض.

ده يحصل كثير لما محدش يملك System-level Coherence.

Hiring Developer أخرى تضيف Architect جديدة بالصدفة.

Team قد تحتاج Architecture Leadership قبل Implementation Capacity إضافية.

علامة 3: Founder أو Product Manager أصبح Technical Router

في Early Companies، Founders غالبًا ينسقوا كل حاجة.

وده ممكن يشتغل مع Team صغيرة جدًا.

لكن يصبح Fragile لما كل Technical Question تمر على شخص مسؤول أصلًا عن Sales وProduct وFundraising أو Operations.

Symptoms ممكن تكون:

• Engineers مستنية Founder.
• Founder داخل كل Technical Discussion.
• Priorities تتغير من Private Conversations.
• محدش عارف مين يقدر Approve Technical Trade-offs.
• Founder يقضي وقت متزايد في إدارة Engineering Details.

Missing Role قد لا تكون Developer أخرى.

قد تكون Tech Lead أو Engineering Manager أو Head of Engineering أو Fractional CTO أو CTO — حسب Scope وStage.

علامة 4: زودت Developers والDelivery ما اتحسنتش

دي من أوضح الأسباب إنك تفحص System.

تخيل Team كبرت من 3 Engineers لـ6، لكن Release Frequency أو Lead Time أو Customer Outcomes ما اتحسنوش بشكل واضح.

ما تستنتجش فورًا إن New Engineers ضعاف.

افحص:

• Onboarding Time.
• Dependencies بين Developers.
• Review Bottlenecks.
• Environment Problems.
• Unclear Requirements.
• Architecture Coupling.
• QA Queues.
• Deployment Constraints.
• Too Much Work in Progress.

Organization قد تكون زودت Headcount بدون ما تزود Capacity الـDelivery System.

علامة 5: Senior Engineers أغلب وقتهم Firefighting

أقوى Engineers ممكن يظهروا Productive جدًا لأنهم بيحلوا كل Emergency.

لكن لو نفس الناس باستمرار:

• تصلح Production Incidents.
• تجاوب Architecture Questions.
• تفك Deployment Blocks.
• تعمل Review لكل Important Pull Request.
• تشرح Undocumented Systems.
• تدير Infrastructure يدويًا.

فهم أصبحوا Human Infrastructure.

Hiring Juniors حولهم ممكن تزود Interruption Load عليهم.

Technical Leadership المفروض تحول Repeated Heroics إلى Systems:

• Documentation.
• Ownership.
• Automation.
• Runbooks.
• Standards.
• Delegation.
• Better Architecture Boundaries.

علامة 6: كل حاجة Priority One

Team عندها 10 Top Priorities فعليًا مفيش عندها Priority.

Engineers تعمل Context Switching.

Features تفضل Half-done.

Urgent Work تقطع Planned Work.

Stakeholders تتجاوز Roadmap.

وبعدين Management تشوف Slow Delivery وتطلب ناس أكثر.

لكن Constraint قد تكون Prioritization.

Technical Leadership لا تقرر Business Strategy لوحدها، لكنها تساعد Leadership تفهم Engineering Trade-offs وتفرض Workable Delivery Sequence.

Team أصغر تخلص Valuable Thing واحدة ممكن تتفوق على Team أكبر تبدأ خمس حاجات.

علامة 7: Technical Debt تتقال لكن لا تتحول لـBusiness Risk

"Technical Debt" ممكن تتحول لعبارة Engineering غامضة.

Leadership تتجاهلها لأن Business Impact مش واضح.

Good Technical Leadership تحول Debt لنتائج مثل:

• Releases تأخذ وقت أطول.
• Incidents تتكرر.
• Subsystem لا تدعم Planned Feature.
• Cloud Cost تزيد بدون داعي.
• Onboarding Engineers تأخذ وقت طويل.
• Security Changes تصبح Risky.
• شخص واحد فقط Safe Operator لـComponent.

لما Debt تتعبر كBusiness Risk أو Delivery Cost، تقدر تعمل لها Prioritization مقابل Product Work.

بدون Translation دي، Team ممكن تفضل تضيف Developers لـSystem كل يوم أصعب في التغيير.

علامة 8: محدش يملك Engineering Quality

مين يملك:

• Code Review Standards؟
• Testing Strategy؟
• Release Process؟
• Observability؟
• Incident Learning؟
• Dependency Upgrades؟
• Security Practices؟
• Architecture Decisions؟

لو الإجابة "كلنا"، Practical Answer ممكن تكون "محدش".

Distributed Responsibility تنجح فقط لما Expectations وMechanisms واضحة.

Technical Leadership مش معناها شخص واحد ينفذ كل المهام دي.

معناها فيه شخص يتأكد إن Organization عندها Functioning System ليهم.

علامة 9: Engineers مش عارفة ليه بتبني الحاجة

Ticket تقول:

Add Export Button.

Developer تقدر تنفذها.

لكن Customer محتاجها ليه؟

أنهي Data مهمة؟

إيه اللي يحصل بعد Export؟

هل Export أصلًا الحل الصح، ولا System ثانية محتاجة Integration؟

لما Engineers تستلم Isolated Tasks بدون Business Context، ممكن تشحن بالضبط المطلوب وتفوت Outcome.

Strong Technical Leadership تربط Product Intent بـImplementation Choices.

وده يقلل Expensive Rework.

علامة 10: Product وEngineering بيتكلموا لغتين مختلفتين

Product تقول Engineering بطيئة.

Engineering تقول Requirements بتتغير.

Sales تقول Customers محتاجة كل حاجة فورًا.

Operations تقول Bugs محدش مهتم بها.

كل Group ممكن تكون بتوصف جزء حقيقي من المشكلة.

حد لازم يخلي Trade-offs مرئية.

Technical Leadership كثيرًا ما تعمل Translation Layer بين:

Business Goals ↔ Product Decisions ↔ Engineering Constraints ↔ Operational Risk

بدون Layer دي، كل Team تعمل Local Optimization.

إمتى فعلًا تحتاج Developers أكتر؟

مش كل Delivery Problem Leadership Problem.

Engineering Capacity إضافية تكون مبررة لما System صحية بشكل معقول وفيه فعلًا Parallelizable Work أكثر من قدرة Team الحالية المستدامة.

Signals ممكن تشمل:

• Priorities واضحة.
• Architecture لها Defined Ownership.
• Engineers مش Blocked باستمرار.
• Review وDeployment Flow شغالين بشكل معقول.
• Work يمكن تقسيمها بدون Dependencies مبالغ فيها.
• Existing Engineers Sustainably Loaded.
• فيه Clear Role للNew Hire.
• الشركة تقدر تعمل Onboarding بفعالية.

هنا إضافة Capability الصحيحة ممكن تزود Throughput.

الكلمة المهمة هي Capability الصحيحة.

ممكن تحتاج Frontend Engineer أو Platform Engineer أو Data Engineer أو Mobile Developer أو SRE — مش ببساطة "Developer أخرى".

Capacity Problem ممكن تكون Skill-shape Problem

تخيل Team عندها 6 Backend Engineers وMobile Engineer واحدة.

Roadmap فجأة أصبحت Mobile-heavy.

Total Headcount ممكن تبدو كافية، لكن Required Skill Distribution لا.

أو Team فيها Mid-level Developers كثير لكن محدش Experienced في Infrastructure.

دي مش بالضرورة Leadership Gap ولا Total-capacity Gap.

دي Capability Gap.

شخّص Shape الـDemand قبل Hiring.

Leadership مش معناها تزود Manager أخرى

الفرق ده مهم.

Team ممكن يكون عندها Managers أكثر من اللازم ولسه ناقصها Technical Leadership.

Technical Leadership Function، مش لازم Job Title.

تشمل حاجات مثل:

• اتخاذ Hard Technical Decisions.
• Clarifying Ownership.
• Setting Engineering Direction.
• ربط Architecture بـProduct Strategy.
• Managing Technical Risk.
• Creating Standards تقلل Repeated Decisions.
• Developing Other Technical Leaders.

حسب الشركة، Function دي ممكن تكون عند Tech Lead أو Staff Engineer أو Engineering Manager أو Head of Engineering أو CTO أو Fractional CTO.

ما توظفش Title قبل تعريف Missing Function.

Tech Lead وEngineering Manager وCTO مش نفس الحاجة

Boundaries تختلف حسب الشركة، لكن Distinction مفيدة:

Tech Lead

عادة أقرب لـTeam أو Technical Domain: Implementation Direction وDesign Decisions وCode Quality وTechnical Coordination.

Engineering Manager

عادة أقرب للPeople وDelivery Systems: Team Health وPerformance وPlanning وHiring وExecution وOrganizational Processes.

CTO

عادة تعمل على Company Level: Technology Strategy وExecutive Trade-offs وOrganizational Design وMajor Architecture وTechnology Risk.

Startup ممكن تجمع الثلاثة في شخص واحد.

كل ما Organization تكبر، غالبًا Roles تبدأ تنفصل.

المهم مش Title. المهم Responsibilities متغطية ولا لأ.

قِس الـFlow قبل ما تعيد تنظيم Team

مش محتاج Giant Analytics Program.

ابدأ Sample من Recent Meaningful Work.

لكل Item، أعد بناء الرحلة:

Requested → Ready → Started → Reviewed → Tested → Deployed → Verified

وبعدين اسأل:

• استنت فين؟
• ليه رجعت Stage سابقة؟
• مين كان لازم يفك Block؟
• أنهي Dependencies ظهرت؟
• أنهي Failures تكررت؟

Patterns غالبًا تظهر بسرعة.

وده أفيد كثيرًا من "Team حاسسها بطيئة".

تابع شوية Engineering Signals بحذر

Metrics لازم تدعم Investigation، مش تتحول Performance Scores للأفراد.

Team-level Signals مفيدة ممكن تشمل:

• Lead Time for Changes.
• Deployment Frequency.
• Change Failure Patterns.
• Time Waiting for Review.
• Unplanned vs Planned Work.
• Incident Recurrence.
• Work in Progress.
• Reopened Work.

Exact Metric أقل أهمية من فهم ليه بتتحرك.

ما تستخدمش Number واحدة علشان تحكم Engineers Productive ولا لأ.

بص على Calendar كمان

أحيانًا Bottleneck واضحة في Meetings.

اسأل:

• Maker Time فاضل قد إيه؟
• كام Recurring Meeting محتاجة كل Engineer؟
• Priorities تتغير Mid-sprint أو Mid-cycle كام مرة؟
• كام شخص لازم Approve Small Decision؟
• Senior Engineers بيتم Interrupt لهم كام مرة؟

Team ممكن تخسر Effective Capacity ضخمة بدون Hiring أو Firing أي حد فقط بسبب Coordination Overhead.

Architecture ممكن تخلق Organizational Bottlenecks

لو كل Feature تحتاج Changes في نفس Central Service، عشر Teams مش هتقدر فعلًا تشتغل Independently.

Bottleneck هنا Architectural Coupling.

وبرضه لو Database واحدة أو Deployment Pipeline أو Person واحدة مطلوبة لكل Release، زيادة Team Count لا تزيل Constraint.

Technical Leadership لازم تحدد فين Architecture تمنع Safe Parallel Work.

الحل ممكن يكون Refactoring Boundaries، مش إضافة Microservices عشوائيًا.

خليك حذر من حل Leadership Problems بـProcess

لما Ownership غير واضحة، Organizations أحيانًا تضيف Ceremonies:

• Status Meetings أكثر.
• Approval Steps أكثر.
• Tickets أكثر.
• Reports أكثر.

Process ممكن تساعد، لكنها لا تستبدل Decision Ownership.

لو محدش يقدر يعمل Architecture Call، Template إضافية مش هتحلها.

لو Priorities متعارضة، Dashboard أخرى مش هتختار بينهم.

استخدم Process لدعم Ownership، مش لإخفاء غيابها.

وخليك حذر من حل Process Problems بالـAI

AI Coding Tools ممكن تزود Individual Implementation Speed.

وده ممكن يكون مفيد جدًا.

لكن لو Bottleneck هي Review أو Requirements أو Architecture أو Deployment، توليد Code أسرع ممكن ببساطة ينقل Queue للمرحلة التالية.

قبل ما تقيس AI Engineering Initiative بعدد Lines of Code أو Generated Pull Requests، اسأل هل بتحسن Complete Path إلى Production.

الهدف مش Code أكثر.

الهدف Better Outcomes بـAcceptable Risk.

Bottleneck Map بسيطة

لما Delivery بطيئة، صنف Constraint.

Demand Problem

Priorities متنافسة أكثر من اللازم.

Response: Product/Business Prioritization.

Decision Problem

Engineers مستنية Technical Direction.

Response: Technical Ownership أوضح.

Architecture Problem

Changes Risky أو Highly Coupled.

Response: Architecture Leadership وTargeted Remediation.

Management Problem

Ownership أوPerformance أوPlanning أوCoordination ضعيفة.

Response: Engineering Management.

Capability Problem

Specific Skill ناقصة.

Response: Hire أوContract أوDevelop الـCapability دي.

Capacity Problem

System صحية لكن Valid Work أكثر من قدرة Team المستدامة.

Response: Add Appropriate Engineering Capacity.

Quality Problem

Rework وIncidents تستهلك Team.

Response: Improve Quality System وحل Root Causes.

أكثر من مشكلة ممكن تكون موجودة في نفس الوقت.

الهدف إنك ما تعاملهمش كلهم كHeadcount Problems.

إيه اللي أفحصه قبل ما أوافق على Engineering Hire جديدة؟

هطلب Evidence حول خمس Areas.

1. Work

أنهي Important Work مستنية، وليه؟

2. Flow

Work بتقضي أغلب وقتها فين؟

3. Ownership

مين يعمل Product وArchitecture وDelivery Decisions؟

4. Capability

أنهي Skill فعلًا ناقصة؟

5. Economics

New Hire المفروض تحسن Outcome إيه، وهنعرف إزاي؟

لو Organization مش قادرة تجاوب الأسئلة دي، Hiring ممكن تظل مطلوبة — لكن Role Definition غالبًا Premature.

مثال عملي

تخيل SaaS Engineering Team من 6 أشخاص.

Management عايزة Developer اتنين زيادة لأن Releases تأخذ 6 أسابيع.

تفحص Recent Work وتلاقي:

• Implementation عادة تأخذ أيام قليلة.
• Requirements تتغير بعد بداية Development.
• Pull Requests تنتظر أيام Senior Engineer واحدة.
• QA تحصل Batch كبيرة قبل Release.
• Deployments Manual.
• Production Incidents تقطع Planned Work.

Developer اتنين زيادة يقدروا ينتجوا Code أكثر.

لكن هيعملوا Pull Requests أكثر لنفس Reviewer وChanges أكثر لنفس Release Process.

First Investment أفضل ممكن تكون:

• Clarify Requirements قبل بداية Work.
• Distribute Review Ownership.
• Automate Testing وDeployment.
• Reduce Batch Size.
• Fix Recurring Incidents.

وبعدها Reassess Capacity.

لو Queue لسه حقيقية، Hiring تصبح أسهل في التبرير وNew Engineers تدخل System أكثر صحة.

مثال ثاني: Leadership كويسة وCapacity فعلًا ناقصة

تخيل Team ثانية:

• Product Priorities مستقرة.
• Architecture مفهومة.
• CI/CD شغالة.
• Reviews موزعة.
• Incidents قليلة.
• Engineers تقدر تملك Areas باستقلالية.
• Roadmap فيها Validated Customer Commitments متعددة تقدر تمشي Parallel بأمان.

هنا Additional Engineers قد تزود Delivery Capacity فعلًا.

Diagnosis غيرت الإجابة.

Good Technical Leadership المفروض تحسن إيه؟

ما تحكمش على Leadership بعدد Documents أو Meetings اللي تعملها.

دور على Improvements مثل:

• Faster Decisions.
• Clearer Ownership.
• Fewer Recurring Incidents.
• Less Avoidable Rework.
• Better Roadmap Trade-offs.
• More Predictable Delivery.
• Stronger Technical Leaders داخل Team.
• Architecture تدعم Product Direction.
• Less Founder Dependency.

Leadership المفروض تخلي System أكثر قدرة، مش تخلي كل Decision تعتمد على Leader.

الهدف مش إننا نتجنب Hiring

الهدف إننا نعمل Hiring داخل System Engineer جديدة تقدر فعلًا تخلق فيها Value.

أحيانًا Sequence الصح:

Fix Ownership → Improve Flow → Add Capacity.

وأحيانًا:

Hire Specialist → Remove Bottleneck → Continue.

وأحيانًا Team فعلًا Understaffed ولازم توظف فورًا.

Diagnosis الأول.

قبل ما توظف Developer التالية

اسأل سؤال واحد:

لو ضفت Excellent Engineer بكرة، إيه تحديدًا اللي هيبقى أسرع؟

لو الإجابة واضحة وTeam تقدر Absorb الشخص، ممكن يكون عندك Capacity Case.

لو الإجابة "هتساعد في كل حاجة"، افحص Delivery System الأول.

ممكن تكتشف إن Team مش محتاجة Pair of Hands إضافية، لكنها محتاجة Technical Ownership أوضح.

Engineering Team بتكبر لكن Delivery مش بتتحسن؟

أقدر أساعدك ترسم Bottlenecks عبر Architecture وEngineering Flow وOwnership وTeam Structure وTechnical Strategy، وبعدها نفصل المشاكل اللي تحتاج Leadership عن اللي فعلًا تحتاج Engineering Capacity أكثر.

ناقش Engineering Leadership مع فادى مندي.

الهدف مش إضافة Management لمجرد Management. الهدف بناء Engineering System تعرف تشحن بثبات مع نمو الشركة.

---

مرتبط: Engineering Leadership، Fractional CTO، Engineering Architecture، Product Engineering، Full-Time CTO vs Fractional CTO vs Technical Consultant، وAI & Codebase Audits.