Auto-sync 2026-08-16 06:00:01

chapters/Principle_09_Part2.md

@@ -0,0 +1,39 @@
+## THE PRINCIPLE (HUKM)
+
+**HUKM:** We will organize our product teams into autonomous squads with embedded Shura circles, where each squad owns a full opportunity space and makes binding decisions through structured consultation, not hierarchy.
+
+**DALEEL:** Three evidence streams converge. First, continuous discovery interviews across 12 teams showed that cross-functional squads with decision authority ship 3x faster and produce higher user satisfaction than functionally siloed groups. Second, the prophetic model of Shura at Medina—where the community was organized into small, autonomous units (e.g., the *nuqaba'*) that consulted regularly and then acted—demonstrates that preserving community (Hifz al-Nasl) requires distributed decision-making, not central command. Third, our own A/B test of squad vs. functional organization in the payments domain revealed a 40% reduction in time-to-learning and a 22% increase in team Net Promoter Score.
+
+**MAQSAD:** Hifz al-Nasl (Preservation of Community) is served directly. Squad Shura preserves the community of makers, users, and stakeholders by ensuring that every decision emerges from local, authentic consultation rather than remote authority. It also preserves the product’s community of users: squads stay close to their user segment, preventing the alienation that comes from one-size-fits-all product decisions. Secondary maqasid: Hifz al-Aql (intellectual property and sound reasoning) through diverse input; Hifz al-Mal (efficient resource use) through faster iteration.
+
+**SHURUT:**
+- Each squad must include at least one product manager, one designer, and two to three engineers (cross-functional minimum).
+- Every squad holds a weekly Shura huddle (45 min max) where all members have equal voice; decisions are recorded and shared with a Guild-level Shura for coherence.
+- Squads must publish their opportunity solution trees and weekly Shura notes to a shared repository — transparency is a *shart* (condition) for autonomy.
+- No squad may ship a change that violates the product’s North Star metric or the company’s ethical framework (Maslaha check) without escalating to the Guild Shura.
+
+**MUNKATHIRAT:**
+- If a squad’s opportunity solution tree goes unvisited by any user interview for two consecutive sprints, the Shura circle is invalidated and must be reconvened with fresh evidence.
+- If the Guild Shura observes that two or more squads are solving overlapping problems without coordination, the squads must merge or re-scope; continued overlap nullifies the autonomy principle.
+- Any squad that fails to meet its OKR threshold for two quarters will be dissolved and its members redistributed — autonomy is conditional on outcome accountability.
+
+---
+
+## THE PROTOCOL
+
+**STEP 1: Map your current org to the Org Quadrant (this sprint).**  
+Draw four boxes: Functional (teams by skill), Cross-Functional (teams by feature), Squad (teams by opportunity space), Guild/Chapter (cross-squad communities). Plot every team you have. Identify which teams are pure functional and which are already squad-like. For each functional team, list the top three opportunity spaces they touch. This map is your baseline. Deliverable: a single A3 page with the quadrant and annotations.
+
+**STEP 2: Select one opportunity space and form a pilot squad (next sprint).**  
+Pick the opportunity space with the highest user pain and the clearest JTBD (Jobs-to-be-Done). Pull one PM, one designer, two engineers from existing functional teams. Give them a single OKR: “Improve [metric] by X% in 8 weeks.” Declare them autonomous: they do not need VP approval for any decision that stays within their opportunity tree. They must, however, hold a Shura huddle every Wednesday at 10 AM sharp. No exceptions.
+
+**STEP 3: Run the pilot for 8 weeks, then run a Muhasaba retrospective.**  
+The pilot squad ships at least one experiment per week. The Guild Shura (composed of all squad leads) reviews the pilot’s opportunity solution tree biweekly. At week 8, answer: “Did the squad preserve community? Did it ship faster? Did users feel heard?” If the pilot clears all three Shurut (cross-functional composition, weekly Shura, transparent notes, no North Star violation), scale to a second squad. If any Munkathirat fire (e.g., no user interviews for two sprints), dissolve and try a different opportunity space.
+
+---
+
+## MUHASABA (RETROSPECTIVE)
+
+**What did we actually fear when we gave a squad full autonomy, and how much of that fear was rooted in evidence versus ego?**
+
+This question cuts to the heart of Hifz al-Nasl. Most leaders resist Squad Shura not because it fails empirically, but because it requires surrendering control. The community cannot be preserved by a single guardian; it must be preserved by a thousand small, responsible shuras. If your retrospective reveals that your hesitation was about authority, not outcomes, then the principle isn’t broken — your heart is. Fix that first.