Hermes Bot
8.2 KiB
Part 1: Discovery, Evidence, and Shura
1. THE SCENARIO
You’re the Product Lead at ZakatPay, a growing fintech startup connecting users to verified charities. The team has grown from 5 to 25 engineers in six months. Silos are forming. The CEO pulls you aside: “Why is the payments squad building a dashboard without talking to the charity onboarding squad? And why do both of them report to me for every decision?” You open your notebook. The Mujtahid in you asks: What is the hukm of organizing the team? What is the maqsad of our structure? The Product Lead in you asks: What’s the smallest change that gives us speed without chaos?
2. DISCOVERY (ISTIQSA’)
PRODUCT_LEAD:
Let’s start with Continuous Discovery. Open your Opportunity Solution Tree. The root opportunity is: “Our team is too slow to respond to user needs because every decision escalates to the CEO.” The parent opportunity is: “Team lacks clear ownership boundaries.” Child opportunities include: “No single point of accountability per feature area,” “Cross-functional dependencies block progress,” “Developers don’t know who to ask for product guidance.”
Now map the Jobs-to-be-Done for the organization itself. The org has three core JTBD:
- Ship validated features weekly – currently failing because of approval bottlenecks.
- Maintain quality and risk compliance – currently handled by CEO-as-gatekeeper, unsustainable.
- Enable team growth and learning – currently zero cross-squad knowledge sharing.
Draw four boxes on your whiteboard: Functional (all PMs together, all engineers together), Cross-functional (squads with PM+Eng+Design), Guild (community of practice across squads), Chapter (discipline-specific sync within squad). Your hypothesis: a squad model with chapters and guilds will unlock speed and preserve alignment.
MUJTAHID:
Istiqsa’ means exhaustive inquiry into the reality of the problem. The maqsad here is Hifz al-Nasl – preservation of the community. The team is a micro-ummah. If its structure fractures, the community (users, charities, donors) suffers delayed aid, broken trust, and wasted mal (wealth).
Ask: How did the Prophet ﷺ organize the Ummah at scale? He used Shura (consultation) for every major decision, appointed wulat (governors) with clear territorial authority, and maintained majlis (councils) for cross-regional coordination. The Sahaba were organized into asabiyyat (clans) but operated as cross-functional squads for expeditions, da’wa, and governance.
Translate to your startup:
- A squad is a jama’a (group) with a clear amir (product lead) and shura council (engineer, designer, QA).
- A guild is a majlis (forum) for a discipline – e.g., all frontend engineers meet biweekly to share maslaha (benefit) practices.
- A chapter is a halaqa (study circle) within a squad for a specific skill (e.g., security practices).
The root illa (cause) of the CEO bottleneck is: lack of defined wilayah (authority boundaries). The hukm is: delegation is wajib (obligatory) when the maqsad (speed, community service) cannot be achieved otherwise. The shart (condition): delegation must have shura built in.
3. EVIDENCE (ISTIDLAL)
PRODUCT_LEAD:
Quantitative evidence:
- Cycle time for a feature from ideation to production: 45 days (target: 10 days).
- Escalations to CEO per week: 12 (target: 2).
- Net Promoter Score from internal team survey: -10 (toxic dependency culture).
Qualitative evidence:
- User interviews: “We asked for a recurring donation feature three months ago – still waiting.”
- Engineering 1:1s: “I don’t know who makes product decisions. I just build what the CEO says.”
- Design retrospectives: “We design in a vacuum; the charity team never sees our prototypes.”
Continuous Discovery also demands outcome-based evidence. The desired outcome is: “A donor can set up a recurring charity donation within two clicks, verified by the charity in real-time.” Currently, that requires 4 handoffs across 3 teams – each handoff adds 1 week delay. The Opportunity Solution Tree shows the highest-impact opportunity: Define squad boundaries by user journey, not by technology.
MUJTAHID:
Istidlal (deduction of evidence) requires classifying daleel (proof) by strength.
Qati’ al-Thubut wa Qati’ al-Dalala (definitive in transmission and meaning): The Prophetic command in Surah Al-Shura (42:38): “And those who have responded to their lord and established prayer and whose affairs are [conducted] through consultation among them…” This is qati’ – Shura is an obligation for collective affairs, not a recommendation. Your team organization must embed consultation.
Zanni al-Thubut, Qati’ al-Dalala (probable transmission, definitive meaning): The hadith: “The hand of Allah is with the jama’a” (Tirmidhi). The jama’a here is the unified squad – a group with shared purpose and mutual consultation.
Qiyas (analogy): The Prophet appointed Mu’adh ibn Jabal as governor of Yemen with clear authority to make ijtihad within his wilayah. Analogy: a squad should have autonomy to make product decisions within its domain without escalating to CEO, provided they consult their shura (squad members).
Sad al-Dhara’i (blocking the means to harm): The current structure (all decisions to CEO) creates a dhari’a (path) to fitna (disorder) – delays, resentment, burnout. Reorganizing into squads is wajib to block this harm.
Maslaha Mursala (unrestricted public interest): The maqsad of Hifz al-Nasl (preserving the team community) is served by squad autonomy. The evidence supports that shura at scale requires structural delegation.
4. SHURA (CONSULTATION)
PRODUCT_LEAD:
Call a cross-functional sync. Invite: CEO, two senior engineers, one designer, one charity operations lead, one customer support lead. Agenda: “How should we organize to ship faster without losing quality?”
Use a Shura Canvas:
- Current state (pain points, bottlenecks).
- Desired outcomes (cycle time <10 days, CEO escalations <2/week).
- Proposed models: squad/chapter/guild (Spotify-inspired, but adapted to Islamic values).
- Risks: autonomy without accountability, duplication of work, loss of shared standards.
Ask each person: “What is your biggest fear about squads? What is your biggest hope?” Record all input. Weight by khibra (expertise) – the senior engineer’s concern about code duplication carries more weight than the designer’s aesthetic worry.
Make dissenting opinions visible: the charity ops lead worries that squads will ignore compliance. Write it on the board. Don’t suppress it – shura requires airing all views.
MUJTAHID:
Shura in Usul al-Fiqh is not a vote; it is a binding consultation when the leader has delegated authority. The mujtahid (here, you as Product Lead) must:
- Identify the ahl al-shura (those qualified to consult). Criteria: adl (integrity), khibra (expertise in their domain), hilm (deliberateness). Exclude those who are biased toward preserving their own power (e.g., the CEO who likes being gatekeeper).
- Frame the question clearly: “What structure maximizes speed, quality, and community preservation?”
- Listen without interrupting – the Prophet ﷺ would listen to all, even the youngest companion.
- Weigh by maslaha – the opinion that best serves Hifz al-Nasl (team unity and user community) and Hifz al-Mal (efficient use of resources) should be preferred.
After the session, write a mahdar (minutes) with:
- All opinions recorded (names anonymized).
- Weight assigned (1-5 scale based on expertise and relevance).
- Dissenting opinions highlighted.
- Your preliminary takhayyur (preferred opinion) – but do not finalize until you have completed the full istidlal above.
Now you have the raw material for the Fatwa – the ruling on how to organize your teams. The Discovery, Evidence, and Shura are done. The decision awaits in Part 2.
End of Part 1. Next: Fatwa (Hukm, Daleel, Maqsad, Shurut, Munkathirat), Protocol, and Muhasaba.