W-04: Cross-Functional Collaboration Playbook¶
| Field | Value |
|---|---|
| Document | W-04 |
| Title | Cross-Functional Collaboration Playbook |
| Status | Draft |
| Owner | CDO |
| Created | 2026-04-05 |
| Review | Quarterly |
| Depends On | STD-GOV-135 (Execution Framework), STD-GOV-137 (Department Mandates & Decision Rights) |
Purpose¶
Define how Simpaisa's four divisions (CDO, COO, CFO, Commercial) work together on cross-functional scenarios. This playbook provides RASCI matrices, handoff protocols, and dependency management rules so that no work falls between the cracks, no handoff is ambiguous, and no conflict festers unresolved.
STD-GOV-137 defines what each department owns. This document defines how they collaborate when work crosses boundaries.
Guiding Principles¶
- Every cross-functional scenario has a single accountable owner. Shared accountability is no accountability.
- Handoffs are explicit. A handoff includes: what is being handed over, what "done" looks like, who receives it, and the deadline.
- Dependencies are flagged early. If you need something from another team, raise it at the earliest point, not when it becomes urgent.
- Conflicts are resolved fast. 24-hour resolution target at department-head level; Leadership Forum if not resolved (per STD-GOV-137 escalation path).
- Written over verbal. All cross-functional agreements, handoffs, and decisions are documented.
RASCI Matrices¶
Legend: - R — Responsible (does the work) - A — Accountable (owns the outcome, one per scenario) - S — Supports (contributes to the work) - C — Consulted (provides input before decisions) - I — Informed (notified of outcomes)
Scenario 1: New Merchant Onboarding¶
TRIGGER: Commercial signs a new merchant agreement.
OUTCOME: Merchant is live, processing transactions, with all compliance satisfied.
Phase Commercial CDO COO CFO
─────────────────────────────────────────────────────────────────────
Merchant acquisition R/A I I C
Commercial agreement R/A C C R
KYC/AML due diligence S I R/A C
Technical integration C R/A S I
API credentials & sandbox I R/A I I
Operational onboarding I S R/A I
Settlement configuration I C S R/A
Go-live sign-off S S R/A S
Post-go-live monitoring I S R/A I
Handoff points: 1. Commercial → COO: Signed agreement + merchant details (within 24 hours of signing) 2. COO → CDO: KYC cleared, ready for technical integration (within 48 hours of KYC completion) 3. CDO → COO: Integration complete, ready for operational testing (upon successful sandbox tests) 4. COO → CFO: Merchant live, settlement configuration required (within 24 hours of go-live)
Scenario 2: New Market Entry¶
TRIGGER: CEO/Board approves entry into a new jurisdiction.
OUTCOME: Simpaisa is licensed, connected to local partners, and processing in the new market.
Phase Commercial CDO COO CFO CEO
──────────────────────────────────────────────────────────────────────────────
Market assessment R C C C A
Regulatory analysis S C S R/A C
Licence application S C S R/A C
Technology localisation C R/A S I I
Partner sourcing R C S C A
Partner integration C R/A S I I
Operational setup I S R/A S I
Compliance framework C S S R/A C
Pilot launch S R R/A S C
Full launch S S R/A S A
Scenario 3: Security Incident¶
TRIGGER: SOC/NOC detects a security event (per incident classification).
OUTCOME: Incident contained, root cause identified, stakeholders informed, remediation complete.
Phase Commercial CDO COO CFO
─────────────────────────────────────────────────────────────────────
Detection & triage I R/A S I
Containment I R/A R I
Impact assessment C R/A S C
Merchant communication R/A S S C
Regulatory notification I S I R/A
Root cause analysis I R/A S I
Remediation I R/A S I
Post-incident review C R/A S C
External communication C S I C
Note: CEO approves all external communications for P1 incidents (per STD-GOV-137). CDO leads technical response; Commercial leads merchant communication.
Scenario 4: Partner Integration¶
TRIGGER: New banking/telco/PSP partner identified for integration.
OUTCOME: Partner integrated, tested, and live in production.
Phase Commercial CDO COO CFO
─────────────────────────────────────────────────────────────────────
Partner identification R/A C C C
Commercial terms R/A C S C
Technical assessment C R/A I I
Contract execution S C I R/A
API integration build I R/A S I
Testing (sandbox) I R/A S I
Testing (UAT) S R R/A I
Operational readiness I S R/A I
Go-live I S R/A S
Performance monitoring I S R/A I
Scenario 5: Product Launch¶
TRIGGER: New product/feature approved via STD-GOV-135 initiative lifecycle.
OUTCOME: Product live, merchants enabled, operations trained, revenue tracked.
Phase Commercial CDO COO CFO
─────────────────────────────────────────────────────────────────────
Product design C R/A C C
Development I R/A I I
QA & testing I R/A S I
Pricing design C C I R/A
Operational readiness I S R/A I
Documentation C R/A S I
Merchant communication R/A S I I
Rollout S R/A S I
Post-launch monitoring S S R/A I
Revenue tracking S I I R/A
Scenario 6: Regulatory Change¶
TRIGGER: Regulator in any market issues new rules, guidance, or licence conditions.
OUTCOME: Simpaisa is compliant within the required timeframe.
Phase Commercial CDO COO CFO
─────────────────────────────────────────────────────────────────────
Regulatory monitoring I C C R/A
Impact assessment C C C R/A
Technical changes I R/A I C
Operational changes I S R/A C
Financial/reporting changes I I I R/A
Merchant communication R/A C I C
Compliance evidence I S S R/A
Regulator submission I C C R/A
Scenario 7: Settlement Issue¶
TRIGGER: Settlement discrepancy, delay, or failure detected.
OUTCOME: Discrepancy resolved, merchants/partners made whole, root cause fixed.
Phase Commercial CDO COO CFO
─────────────────────────────────────────────────────────────────────
Detection I I R R/A
Root cause diagnosis I S R/A S
Merchant impact assessment R/A I S S
Technical fix (if needed) I R/A S C
Manual settlement (if req.) I I R R/A
Merchant communication R/A I S C
Partner escalation I I R/A C
Process improvement I C R/A S
Scenario 8: Data Breach¶
TRIGGER: Confirmed or suspected unauthorised access to personal or financial data.
OUTCOME: Breach contained, affected parties notified, regulators informed, remediation complete.
Phase Commercial CDO COO CFO
─────────────────────────────────────────────────────────────────────
Detection & confirmation I R/A S I
Containment & isolation I R/A R I
Scope assessment I R/A S C
Regulatory notification I S I R/A
Affected party notification R/A S S C
Forensic investigation I R/A I I
Remediation I R/A S I
Post-breach review C R/A S C
Process/control improvement I R/A S C
Note: Data breach triggers regulatory notification obligations in all six jurisdictions. CFO leads regulatory notification; CDO leads technical response. CEO approves all external communications.
Scenario 9: Feature Request from Merchant¶
TRIGGER: Merchant requests a new feature or enhancement.
OUTCOME: Request evaluated, prioritised, and either built or declined with rationale.
Phase Commercial CDO COO CFO
─────────────────────────────────────────────────────────────────────
Request capture R/A I I I
Feasibility assessment S R/A C I
Revenue/business case R/A I I C
Prioritisation C R/A C C
Development I R/A I I
Testing I R/A S I
Merchant communication R/A S I I
Rollout S R/A S I
Rule: All merchant feature requests go through Commercial first. Commercial evaluates the business case before passing to CDO for technical assessment. CDO prioritises against the product backlog. No direct merchant-to-engineering requests.
Scenario 10: Pricing Change¶
TRIGGER: Need to change pricing for a corridor, product, or merchant tier.
OUTCOME: Pricing updated across all systems, merchants notified, revenue impact tracked.
Phase Commercial CDO COO CFO
─────────────────────────────────────────────────────────────────────
Pricing proposal R I I R/A
Impact modelling S I I R/A
Technical implementation I R/A I C
System configuration I R/A S C
Merchant notification R/A I I C
Contract amendment S I I R/A
Revenue monitoring S I I R/A
Decision authority: CFO decides on pricing changes (per STD-GOV-137). Non-standard pricing requires CEO approval.
Handoff Protocols¶
Every handoff between divisions follows this structure:
HANDOFF PROTOCOL
───────────────────────────────────────────────────────────────
FROM: [Sending division/team]
TO: [Receiving division/team]
WHAT: [Specific deliverable being handed over]
WHEN: [Deadline or trigger event]
DONE: [Acceptance criteria — how the receiver knows it is complete]
HOW: [Channel — Jira ticket, Slack thread, email, or meeting]
SENDER responsibilities:
□ Deliver all required artefacts
□ Confirm handoff in writing (not verbal)
□ Remain available for questions for 48 hours after handoff
RECEIVER responsibilities:
□ Acknowledge receipt within 4 business hours
□ Raise blockers or missing information within 24 hours
□ Do not begin work until all acceptance criteria are met
CDO ↔ COO Handoffs¶
This is the most frequent cross-division boundary. CDO builds; COO runs.
| Handoff | Direction | Trigger | Deliverables | SLA |
|---|---|---|---|---|
| New feature release | CDO → COO | Release review sign-off | Release notes, runbook updates, monitoring alerts, rollback plan | 48 hours before production release |
| Incident escalation (technical) | COO → CDO | Ops team cannot resolve within 30 min | Incident ticket with symptoms, timeline, affected transactions | Immediate (P1), 1 hour (P2), 4 hours (P3) |
| Infrastructure change | CDO → COO | Change approved via change management | Change record, impact assessment, rollback plan | 72 hours before scheduled change |
| New partner integration | CDO → COO | Integration testing complete | Integration documentation, monitoring dashboards, escalation contacts | 1 week before go-live |
| Bug report (production) | COO → CDO | Production issue confirmed | Reproduction steps, affected transactions, business impact | Within 2 hours of confirmation |
CDO ↔ CFO Handoffs¶
CDO builds the platform; CFO governs the financials flowing through it.
| Handoff | Direction | Trigger | Deliverables | SLA |
|---|---|---|---|---|
| Settlement system changes | CDO → CFO | Development complete | Technical specification, reconciliation impact, testing evidence | 2 weeks before go-live |
| Financial data extracts | CDO → CFO | Month-end / ad-hoc request | Data in agreed format, completeness certification | Per agreed schedule |
| Budget request (technology) | CDO → CFO | New initiative or unplanned spend | Business case, cost breakdown, timeline | 2 weeks before budget cycle |
| Regulatory technical evidence | CDO → CFO | Audit or regulatory request | Technical compliance evidence, system documentation | Within 5 business days |
Commercial ↔ COO Handoffs¶
Commercial acquires merchants; COO operationally supports them.
| Handoff | Direction | Trigger | Deliverables | SLA |
|---|---|---|---|---|
| New merchant onboarding | Commercial → COO | Agreement signed | Merchant profile, KYC documents, expected volumes, go-live target | Within 24 hours of signing |
| Merchant escalation | COO → Commercial | Operational issue affecting merchant relationship | Issue summary, impact assessment, proposed resolution | Within 4 hours for key merchants |
| Merchant churn risk | COO → Commercial | Volume decline >20% or repeated complaints | Transaction data, complaint history, risk assessment | Within 48 hours of detection |
Commercial ↔ CDO Handoffs¶
Commercial brings requirements from the market; CDO builds solutions.
| Handoff | Direction | Trigger | Deliverables | SLA |
|---|---|---|---|---|
| Feature request | Commercial → CDO | Validated merchant need | Business case, revenue estimate, merchant commitment | Via product backlog (reviewed fortnightly) |
| Technical capability brief | CDO → Commercial | New feature or API available | Feature documentation, merchant-facing materials, limitations | 1 week before merchant communication |
| Integration support request | Commercial → CDO | Merchant needs technical help | Merchant details, integration requirements, timeline | Within 48 hours |
| Market intelligence | Commercial → CDO | Competitive threat or opportunity | Competitor analysis, market data, recommended response | Via fortnightly product review |
Dependency Management¶
How Teams Flag Dependencies¶
DEPENDENCY LIFECYCLE
───────────────────────────────────────────────────────────────
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│IDENTIFIED│───▶│ AGREED │───▶│ TRACKED │───▶│ RESOLVED │
└──────────┘ └──────────┘ └──────────┘ └──────────┘
│ │
▼ ▼
┌──────────┐ ┌──────────┐
│ REJECTED │ │ ESCALATED│
└──────────┘ └──────────┘
Step 1 — Identify: Any team member who discovers a cross-functional dependency raises it immediately. Dependencies are not something to "sort out later."
Step 2 — Agree: The dependent team and the providing team agree on: - What is needed - When it is needed by - What "done" looks like - Who the single point of contact is on each side
Step 3 — Track: Dependencies are tracked in the initiative register (per STD-GOV-135). Each dependency has: - A named owner on the providing side - A target date - A status (on track / at risk / blocked)
Step 4 — Resolve or Escalate: If a dependency is at risk, the owning team must raise it at the next relevant standup or Leadership Forum. Do not wait for it to become blocked.
Dependency Conflict Resolution¶
| Situation | Resolution | Who Decides | Timeframe |
|---|---|---|---|
| Two teams need the same resource | Department heads negotiate directly | Relevant department heads | 24 hours |
| Timeline conflict (Team A needs X from Team B, but Team B's priority is Y) | Reprioritisation discussion | Leadership Forum | Next scheduled forum (or ad-hoc if blocking) |
| Architectural dependency (new feature requires platform change) | ARB review | CDO via ARB | Next ARB meeting (monthly) or ad-hoc |
| Budget conflict | CFO adjudicates within approved envelope | CFO | 48 hours |
| Unresolvable conflict | CEO decides | CEO | 24 hours after escalation |
Dependency Visibility¶
Dependencies are made visible through: 1. CDO Division Weekly Standup (Tuesday) — Engineering, Product, Security, Data dependencies 2. Leadership Forum (fortnightly) — Cross-division dependencies and blockers 3. Initiative Register — All active initiative dependencies tracked centrally 4. Weekly Planning — Engineering teams identify external dependencies at cycle start
Joint Working Sessions¶
When to Convene¶
Not everything needs a meeting. Joint working sessions are for situations where asynchronous communication is too slow or too ambiguous.
| Trigger | Format | Who Convenes | Duration | Participants |
|---|---|---|---|---|
| New merchant onboarding (complex) | Kick-off meeting | Commercial | 60 min | Commercial + COO + CDO + CFO |
| New market entry planning | Working group (recurring) | CEO | 90 min weekly | All four divisions |
| P1 incident (active) | War room (virtual) | CDO | Until resolved | CDO + COO + Commercial (as needed) |
| Partner integration kick-off | Kick-off meeting | COO | 60 min | COO + CDO + Commercial |
| Regulatory change (material) | Impact assessment session | CFO | 90 min | CFO + CDO + COO + Commercial |
| Quarterly partner review | Review meeting | COO + Commercial | 60 min per partner | COO + Commercial + CDO (as needed) |
| Product launch preparation | Launch readiness review | CDO | 60 min | CDO + COO + Commercial + CFO |
| Settlement dispute (material) | Resolution session | CFO | 60 min | CFO + COO + CDO |
Joint Session Rules¶
- Written pre-read circulated 24 hours before. No cold starts.
- Clear agenda with decision points. Sessions without decisions are status updates — use async instead.
- One facilitator, one note-taker. The convening division provides both.
- Actions documented within 4 hours. Each action has an owner and a deadline.
- No recurring joint sessions without review. Every recurring session is reviewed quarterly. If it does not produce decisions, it is cancelled.
- Time zone respect. All joint sessions within the 10:00-14:00 Dubai time overlap window (per W-01).
Cross-Functional Initiative Ownership¶
Per STD-GOV-135, every initiative has a single owner. For cross-functional initiatives:
CROSS-FUNCTIONAL INITIATIVE STRUCTURE
───────────────────────────────────────────────────────────────
┌──────────────────────────────────────────────┐
│ INITIATIVE OWNER (single person) │
│ - Accountable for outcomes │
│ - Reports to Leadership Forum │
│ - From the division with the largest stake │
└──────────────┬───────────────────────────────┘
│
┌────────────┼────────────┬────────────┐
▼ ▼ ▼ ▼
┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐
│ CDO │ │ COO │ │ CFO │ │Comml.│
│ Lead │ │ Lead │ │ Lead │ │ Lead │
└──────┘ └──────┘ └──────┘ └──────┘
Division leads: responsible for their
division's contribution to the initiative.
Owner Assignment Rules¶
| Initiative Type | Default Owner Division | Rationale |
|---|---|---|
| New product / feature | CDO | CDO owns product architecture (STD-GOV-137) |
| New market entry | CEO (delegated to appointed lead) | Cross-cuts all divisions equally |
| Partner integration | COO | COO owns partner management (STD-GOV-137) |
| Regulatory compliance programme | CFO | CFO owns regulatory compliance (STD-GOV-137) |
| Merchant growth initiative | Commercial | Commercial owns merchant acquisition (STD-GOV-137) |
| Platform migration / tech programme | CDO | CDO owns technology architecture (STD-GOV-137) |
| Security remediation | CDO | CDO owns security posture (STD-GOV-137) |
| Settlement process change | CFO | CFO owns settlement policy (STD-GOV-137) |
Reporting¶
Cross-functional initiative owners report status at the fortnightly Leadership Forum per STD-GOV-135. Status format:
INITIATIVE STATUS (for Leadership Forum)
───────────────────────────────────────────────────────────────
Initiative: [name]
Owner: [name, division]
Status: [Green / Amber / Red]
Progress: [1-2 sentences on what was delivered since last report]
Next milestone: [what, when]
Blockers: [none, or specific blocker with proposed resolution]
Dependencies: [none, or specific dependency with status]
Decision needed: [none, or specific decision for the forum]
Rule: Green status = no air time at the forum. Only Amber and Red are discussed. Written status submitted 24 hours before the forum.
Conflict Resolution¶
Per STD-GOV-137, the escalation path is:
CONFLICT RESOLUTION PATH
───────────────────────────────────────────────────────────────
STEP 1: Direct resolution (24 hours)
──────────────────────────────────────
Department heads discuss directly.
Must produce a written proposal, not just "we disagree."
│
┌────┴────┐
│Resolved?│──── Yes ──▶ Document decision. Done.
└────┬────┘
│ No
▼
STEP 2: Leadership Forum (next scheduled, or ad-hoc if urgent)
──────────────────────────────────────
Both parties submit written positions:
"Department A proposes X because Y."
"Department B proposes W because Z."
│
┌────┴────┐
│Resolved?│──── Yes ──▶ Document decision. Done.
└────┬────┘
│ No
▼
STEP 3: CEO decides (within 24 hours)
──────────────────────────────────────
CEO's decision is final and documented.
Implementation begins immediately.
Conflict Types and Resolution Owners¶
| Conflict Type | First Attempt | Escalation |
|---|---|---|
| Resource contention (who works on what) | Department heads | Leadership Forum |
| Priority disagreement (what is more important) | Department heads | Leadership Forum → CEO |
| Technical approach disagreement | ARB (CDO chairs) | CDO decides |
| Commercial terms disagreement | Commercial + CFO | CEO |
| Operational process disagreement | COO + affected division | Leadership Forum |
| Data ownership disagreement | CDO (Data Lead) | CDO decides |
| Timeline disagreement | Department heads | Leadership Forum |
Rules for Healthy Conflict¶
- No back-channel escalation. Do not go around someone. Go to them first.
- No passive resistance. If you disagree with a decision, say so in the meeting. Silent disagreement followed by non-compliance is worse than open conflict.
- Disagree and commit. Once a decision is made (by consensus or escalation), everyone executes it fully. Revisit only if new information emerges.
- Written positions. "We disagree" is not an escalation. Written proposals with rationale are required (per STD-GOV-137).
- Speed over perfection. A good decision made quickly beats a perfect decision made slowly. Most decisions are reversible.
Compliance¶
All divisions are expected to follow this playbook. The CDO is responsible for maintaining and updating it. Deviations from the RASCI matrices or handoff protocols should be raised at the Leadership Forum for review.
This document is reviewed quarterly alongside STD-GOV-135 and STD-GOV-137.