A comprehensive resource distribution model for Duplo's 24 engineers that balances technical excellence with delivery velocity.
Architecture Context: Dashboard and Atlas are customer-facing solutions. Both rely on Core for all money movement operations (wallet, ledger, business accounts, payout fulfillment, inflow processing).
Engineers report to discipline leads for standards, career growth, and hiring decisions
Project leads own sprint delivery, technical decisions, and application-specific work
20% sprint flexibility allows reallocation based on business priorities
| Person | Discipline Role | Project Role | Allocation Responsibility |
|---|---|---|---|
| Adeolu Osunsami | Head of Engineering | All Projects | Strategy, escalations |
| Abuchi Ndinigwe | Tech Lead Backend | Core Project Lead | Core + Mock Server BE |
| Ezekiel Turaki | Tech Lead Frontend & Mobile | Atlas Project Lead | All FE engineers + Atlas BE (Laravel) |
| Emmanuel Bodunde | Senior Backend Engineer | Dashboard Project Lead | Dashboard BE engineers |
| Olusegun Folorunsho | Lead Quality Assurance | All Projects | Quality Assurance + Manual Testing + Automation |
| Responsibility | Discipline Lead Owns | Project Lead Owns |
|---|---|---|
| Standards | Code standards, architecture patterns | Application-specific decisions |
| Career | 1:1s, skill growth, promotions | — |
| Hiring | Hiring decisions | Input on candidates |
| Delivery | — | Sprint planning, shipping |
| Code Reviews | Cross-cutting patterns | Application code |
| Performance Reviews | 50% weight | 50% weight |
| Incidents | — | On-call, resolution |
| BE Allocation | — | Each project lead allocates their own BE |
| FE Allocation | Ezekiel assigns all FE engineers | Project Leads request FE support |
| Support Engineer | — | Mubarak shared across all projects |
Abuchi (Backend Lead + Core Project): Adetola handles Core day-to-day sprints
Ezekiel (FE/Mobile Lead + Atlas Project): FE pool model allows flexibility; Atlas BE is small
When work spans multiple projects (e.g., Dashboard feature requiring Core API changes), these coordination rules apply:
| Type | Example | Coordination Method | Lead Time |
|---|---|---|---|
| API Dependency | Dashboard needs new Core endpoint | Requesting Project Lead raises at Weekly Project Leads Sync | 1 sprint ahead |
| Shared Resource | FE engineer needed for Atlas + Dashboard same sprint | Ezekiel allocates at Sprint Start FE Allocation | Sprint start |
| Schema/DB Change | Core DB migration affecting Atlas queries | Ibrahim + affected Project Leads coordinate; announce in #dp-product-engineering | 2 sprints ahead |
| Infrastructure | New service deployment, environment changes | Johnmary coordinates with affected Project Leads | 1 sprint ahead |
| Rule | Policy |
|---|---|
| Contract First | API contracts (OpenAPI spec) must be agreed before implementation begins |
| No Silent Dependencies | All cross-project dependencies must be logged in JIRA with linked tickets |
| Blocking Escalation | If dependency blocks sprint work for >2 days, escalate to HoE |
| Shared Ownership | Admin app changes require consensus from all Project Leads (async approval in Slack) |
The following resources are distributed across all projects based on demand and sprint priorities.
| Person | Function | Allocation Model |
|---|---|---|
| Johnmary Odenigbo | DevOps + SRE | Request-based across all projects |
| Ibrahim Olubiyi | Database Admin & Data Engineering | 60% DBA (request-based) + 40% Data/Metrics projects |
| David Ekete | Technical Writing | Request-based across all projects |
| Mubarak Tijani | Support Engineer | Request-based across all projects, reporting to Leads |
Leads who code are counted with their discipline, not separately as "Leadership".
All 24 engineers in the Duplo Engineering organization.
| Engineer | Role | Status |
|---|---|---|
| Adeolu Osunsami | Head of Engineering | Leadership |
| Abuchi Ndinigwe | Tech Lead Backend / Core Project Lead | Leadership |
| Ezekiel Turaki | Tech Lead Frontend & Mobile / Atlas Project Lead | Leadership |
| Emmanuel Bodunde | Senior Backend / Dashboard Project Lead | Leadership |
| Olusegun Folorunsho | Lead Quality Assurance | Leadership |
| Adetola Onasanya | Backend Engineer (Core Deputy) | Senior |
| Cynthia Owolabi | Backend Engineer (Fullstack) | Senior |
| Rasheed Raji | Backend Engineer (Dashboard) | Senior Contract |
| Njoli Patrick | Backend Engineer (Dashboard) | Mid Contract |
| Boluwatife Ajileye | Backend Engineer (Atlas - Laravel) | Senior Contract |
| Oluwadare Samuel | Backend Engineer (Atlas - Laravel) | Mid |
| Kelvin Kamau | Frontend Engineer (React) | Senior |
| Wisdom Ossai | Frontend Engineer (React) | Senior |
| Samuel Airehrour | Frontend Engineer (React) | Senior |
| Oluwaseun Odeyemi | Frontend Engineer (Fullstack) | Senior |
| Raneh Egbe | Frontend Engineer (React) | Intern |
| Christian Esomnofu | Mobile Engineer (Flutter) | Senior |
| Mumin Abubakar | QA Engineer | Senior |
| Orinami Kure | QA Engineer | Senior |
| Tosan Gbiaye | QA Engineer | Senior |
| Ibrahim Olubiyi | Database Admin & Data Engineer | Senior |
| Johnmary Odenigbo | DevOps Engineer | Senior Contract |
| Mubarak Tijani | Support Engineer | Junior |
| David Ekete | Technical Writer | Mid Contract |
| Person | Role | Function |
|---|---|---|
| Akindehin Adedolapo | vCISO | Security & Compliance |
| Charles Ahubelem | Compliance Officer | Security & Compliance |
| Application | Tech Stack | Project Lead | Backend Engineers | Frontend Engineers |
|---|---|---|---|---|
| Dashboard | React + NestJS | Emmanuel | Emmanuel, Rasheed, Njoli | Shared (Ezekiel assigns) |
| Sendfirst | React + NestJS | Emmanuel | Shared with Dashboard | Shared (Ezekiel assigns) |
| Mobile | Flutter | Emmanuel | Emmanuel, Rasheed, Njoli | Christian |
| Atlas | React + Laravel | Ezekiel | Boluwatife, Oluwadare | Shared (Ezekiel assigns) |
| Checkout | React | Ezekiel | Boluwatife, Oluwadare | Shared (Ezekiel assigns) |
| Docs | React | Ezekiel | No BE required | David |
| Core | NestJS (API only) | Abuchi | Abuchi, Adetola, Cynthia | No FE required |
| Admin | React + NestJS | Shared | Shared (All BE NestJs) | Shared (Ezekiel assigns) |
| Mock Server | NestJS | Abuchi | Shared from Core BE | No FE required |
Each project team's sprint capacity is divided into named buckets to ensure all work types are covered without needing new headcount. Percentages are adjustable quarterly at Resource Allocation Planning.
| Capacity Bucket | % Per Sprint | What Goes Here | Owner |
|---|---|---|---|
| Planned Roadmap | 60% | Product roadmap features, epics | Project Leads |
| Customer & Sales Requests | 15% | Customer modifications (via PM), Sales feature requests (via PM) | PM triages → Project Leads execute |
| Tech Debt & Reliability | 15% | Refactoring, upgrades, monitoring, incident follow-ups | Discipline Leads propose → Project Leads plan |
| Data & Metrics | 10% | Metabase dashboards, reports, data exports, analytics | Ibrahim owns; pulls BE support as needed |
In a 10-day sprint, this roughly means: 6 days roadmap · 1.5 days customer/sales · 1.5 days tech debt · 1 day data support
Each project applies the 60/15/15/10 split to their own team. Engineers stay on their assigned projects.
| Project | Team | Roadmap (60%) | Cust/Sales (15%) | Tech Debt (15%) | Data (10%) |
|---|---|---|---|---|---|
| Dashboard | ~5 (3 BE + 2 FE*) | 3 eng | 0.75 | 0.75 | 0.5 |
| Atlas | ~4 (2 BE + 2 FE*) | 2.4 eng | 0.6 | 0.6 | 0.4 |
| Core | ~3 (BE) | 1.8 eng | 0.45 | 0.45 | 0.3 |
| Dev Total | ~12 | ~7.2 | ~1.8 | ~1.8 | ~1.2 |
*FE from shared pool — sprint allocation, not permanent assignment. Ezekiel assigns FE engineers each sprint based on project needs.
| Group | Size | Allocation Model |
|---|---|---|
| Platform | 3 | Johnmary (DevOps), Mubarak (Support), David (Docs) — request-based |
| QA | 4 | Olusegun + 3 — work across all projects |
| Data | 1 | Ibrahim — 60% DBA / 40% Data projects |
| HoE | 1 | Adeolu — strategy, escalations (leads code with their teams) |
No one changes teams. Sprint planning just becomes more intentional about which bucket each ticket falls into.
When multiple items compete for the same capacity bucket:
Project Leads submit requests at sprint start; HoE approves reallocation between buckets.
Work is only considered "Done" when it meets all applicable criteria below. This applies to all capacity buckets.
| Criterion | Requirement | Enforced By |
|---|---|---|
| Code Review | At least 1 approval from team member; 2 approvals for critical paths (payments, auth) | GitHub PR rules |
| Tests | Unit tests for new logic; integration tests for API changes; no test regressions | CI pipeline |
| Documentation | API changes require OpenAPI spec update; user-facing changes require release notes | PR checklist |
| No Lint Errors | Code passes ESLint/Prettier (FE) or equivalent (BE) | CI pipeline |
| Criterion | Requirement |
|---|---|
| Functional Testing | All acceptance criteria verified in staging environment |
| Regression Testing | Core flows verified (login, payments, key transactions) |
| Edge Cases | Error states, empty states, and boundary conditions tested |
| Cross-Browser/Device | FE changes tested on Chrome, Safari, Mobile (as applicable) |
| Criterion | Requirement |
|---|---|
| Feature Flag | High-risk changes behind feature flag for gradual rollout |
| Rollback Plan | DB migrations must be reversible; deployment can be rolled back in <15 mins |
| Monitoring | Key metrics/alerts configured for new features (Datadog/equivalent) |
Production incidents operate outside the normal capacity buckets — they interrupt planned work immediately. This section defines response expectations and sprint impact handling.
| Severity | Definition | Response SLA | Resolution Target | Who Responds |
|---|---|---|---|---|
| P1 — Critical | Site down, money stuck, data loss, security breach | 15 minutes | 4 hours | Project Lead + available engineers (all hands) |
| P2 — High | Major feature broken, significant customer impact, degraded performance | 1 hour | 8 hours | Project Lead + 1-2 engineers |
| P3 — Medium | Feature partially broken, workaround exists, limited customer impact | 4 hours | Next sprint | Assigned engineer (normal triage) |
| P4 — Low | Minor bug, cosmetic issue, edge case | Next business day | Backlog | Normal sprint planning |
| Scenario | Sprint Handling | Approval |
|---|---|---|
| P1 Incident | Drops everything. Engineers pulled immediately. Sprint velocity hit is accepted and excluded from metrics. | Project Lead (notify HoE) |
| P2 Incident | Pulled into current sprint. Displaces lowest-priority Planned Roadmap item (moved to next sprint). | Project Lead |
| Escalated Customer Bug | PM fast-tracks into Customer & Sales bucket. If urgent, displaces current sprint item with Project Lead approval. | PM + Project Lead |
| Mid-Sprint Reallocation | Any incident requiring >2 engineer-days mid-sprint requires HoE approval and sprint scope adjustment. | HoE |
P1/P2 incidents require a written RCA (Root Cause Analysis) within 48 hours, reviewed at next Weekly Project Leads Sync.
Follow-up tickets for permanent fixes go into Tech Debt (15%) bucket for next sprint.
First-responder rotation ensures 24/7 coverage for production incidents.
| Layer | Who | Coverage | Responsibilities |
|---|---|---|---|
| Primary On-Call | Rotating BE engineer (1 per project) | Business hours (9am-6pm WAT) | First response, triage, escalate if needed |
| Support Engineer | Mubarak Tijani | Business hours | Customer-reported issues, initial triage, route to on-call |
| Project Lead | Emmanuel / Ezekiel / Abuchi | Always reachable | Escalation point, pull additional engineers |
| After-Hours | Project Lead + Johnmary (DevOps) | Evenings & weekends | P1 incidents only; other issues wait until next business day |
| Project | On-Call Pool | Rotation |
|---|---|---|
| Dashboard | Emmanuel, Rasheed, Njoli | Weekly rotation (Mon-Sun) |
| Atlas | Ezekiel, Boluwatife, Oluwadare | Weekly rotation (Mon-Sun) |
| Core | Abuchi, Adetola, Cynthia | Weekly rotation (Mon-Sun) |
| Infrastructure | Johnmary, Ibrahim | Bi-weekly rotation |
Response time: Acknowledge alert within 15 minutes during on-call hours
Handoff: End-of-week handoff note in #dp-tech-team-private Slack channel
Compensation: On-call incidents outside business hours tracked for comp time
All external and internal work requests flow through defined intake channels to the appropriate capacity bucket. Engineering does not accept direct requests from Sales or CS — Product Manager always mediates.
| Work Source | Intake Channel | Gatekeeper | Routes To | Capacity Bucket |
|---|---|---|---|---|
| Product Roadmap | PM → JIRA Epics | Product Manager | Project backlog | Planned Roadmap (60%) |
| Customer Modifications | CS (any channel) → JIRA "Customer Request" queue | PM reviews weekly | Pod backlog / reject / SP team | Customer & Sales (15%) |
| Sales Feature Requests | Sales → Feature Request Form → PM | PM scores & prioritizes | Pod backlog / SP team / defer | Customer & Sales (15%) |
| Data & Metrics Projects | Requestor → JIRA "Data" type | Ibrahim triages | Self-serve or sprint-planned | Data & Metrics (10%) |
| Bug / Incident | Support → JIRA Bug | Tech Lead (daily triage) | Pod backlog (existing process) | Planned Roadmap (60%) |
| Tech Debt | Engineering → JIRA Tech Debt | Discipline Leads | Pod backlog | Tech Debt (15%) |
| Strategic / Exploratory | Business → SP Team | HoE | SP Team (separate track) | Separate track |
Owner: Ibrahim Olubiyi (Database Admin & Data Engineer)
Ibrahim owns all Metabase dashboards, data exports, reporting queries, and analytics requests. His time is split 60% DBA / 40% Data/Metrics.
| Step | Action | Owner | SLA |
|---|---|---|---|
| 1. Request | Submit via JIRA ticket (type: Data) | Any stakeholder | — |
| 2. Triage | Ibrahim reviews, estimates effort, classifies as Small (<2 days) or Large (>2 days) | Ibrahim | 1 business day |
| 3a. Small Request | Ibrahim self-serves: ad-hoc query, simple Metabase dashboard, data export | Ibrahim | 3 business days |
| 3b. Large Request | Ibrahim submits scoped request to relevant Project Lead for sprint planning. If BE changes needed (new endpoints, data pipelines), Project Lead allocates from 10% Data bucket. | Ibrahim + Project Lead | Next sprint |
Escalation: If data requests exceed Ibrahim's 40% capacity, HoE reviews at Weekly Project Leads Sync and may temporarily pull a BE engineer.
All customer requests — regardless of whether they arrive via Intercom/Zendesk, Slack, or email — must be funneled into a single JIRA intake queue.
| Step | Action | Owner | Timing |
|---|---|---|---|
| 1. Log | CS logs every customer request into JIRA "Customer Requests" board/label, with customer name, request detail, and urgency | Customer Support | Within 24 hours of receipt |
| 2. Review | PM reviews queue weekly and categorizes each item | Product Manager | Weekly (every Monday) |
| 3. Categorize | PM classifies as: Bug → bug triage | Enhancement → pod backlog | New Feature → roadmap consideration | Customization → reject/defer/SP team | Product Manager | Same review session |
| 4. Size | PM presents accepted items at Weekly Project Leads Sync for engineering sizing | PM + Project Leads | Weekly sync |
| 5. Plan | Sized items enter project backlog under the Customer & Sales (15%) capacity bucket | Project Leads | Next sprint planning |
Escalation: High-value customer requests (flagged by CS or Sales) go directly to HoE + PM for expedited triage — outside the weekly cycle.
Sales does NOT go directly to engineering. Product Manager is the single gatekeeper for all Sales-originated feature requests.
| Step | Action | Owner | Timing |
|---|---|---|---|
| 1. Submit | Sales submits via Feature Request Form (JIRA intake or Google Form) with: Customer name, Revenue impact, Competitive context, Requested timeline | Sales Team | Anytime |
| 2. Score | PM evaluates using lightweight RICE: Revenue Impact × Customer Count × Strategic Alignment | Product Manager | Within 5 business days |
| 3. Decide | PM routes to: Accepted → pod backlog (Customer & Sales 15% bucket) | SP Team → if exploratory/POC needed | Deferred → future quarter | Rejected → with rationale | Product Manager | Same scoring session |
| 4. Communicate | PM updates Sales with status and estimated timeline. Monthly: PM presents top requests at Engineering Leads Sync | Product Manager | Within 5 business days |
| 5. Execute | Accepted items enter sprint via Project Leads under the Customer & Sales (15%) capacity bucket | Project Leads | Next available sprint |
Feedback loop: Sales receives one of four statuses — Accepted (estimated quarter), In Progress (current sprint), Deferred (reason + revisit date), or Rejected (rationale + alternative).
Governance rules for maintaining healthy, actionable backlogs across all projects.
| Rule | Policy | Enforced By |
|---|---|---|
| WIP Limit | Max 2 sprints of "Ready" items per project at any time. Prevents over-refinement. | Project Leads |
| 90-Day Flag | Items untouched for 90 days are auto-flagged for review. PM or Project Lead must re-justify or archive. | PM + Project Leads |
| 180-Day Archive | Items untouched for 180 days are archived unless explicitly re-justified with updated business case. | HoE + PM |
| Refinement Cadence | Weekly 60 min refinement session per project. Backlog items must have acceptance criteria before entering "Ready". | Project Leads |
All feature requests are scored using a lightweight RICE model:
| Factor | Definition | Scale |
|---|---|---|
| Reach | How many customers/users are affected per quarter? | 1 (few) — 10 (all) |
| Impact | How much does this move revenue, retention, or compliance? | 0.25 (minimal) — 3 (massive) |
| Confidence | How confident are we in the estimates? | 50% / 80% / 100% |
| Effort | Person-sprints to deliver (1 sprint = 1 engineer × 2 weeks) | 0.5 — 10+ |
RICE Score = (Reach × Impact × Confidence) / Effort
Higher score = higher priority. Bugs continue to use the existing severity/priority matrix.
Added to the existing Quarterly Resource Allocation Planning ceremony (HoE + All Leads, 2 hours). Review includes:
Standardized deployment rhythm ensures predictable releases and reduces risk.
| Environment | Cadence | Window | Approval |
|---|---|---|---|
| Development | On merge to dev branch | Anytime | Automatic (CI/CD) |
| Staging | Daily (end of day) | 4pm-6pm WAT | Automatic (CI/CD) |
| Production | Twice weekly | Tuesday & Thursday, 10am-12pm WAT | Project Lead + QA sign-off |
| Hotfix | As needed (P1/P2) | Anytime | Project Lead + HoE for after-hours |
| Period | Duration | What's Allowed |
|---|---|---|
| Month-End | Last 2 business days of month | Critical hotfixes only (finance reconciliation period) |
| Major Holidays | Dec 20 - Jan 3, Eid periods | Emergency hotfixes only; no feature releases |
| Major Customer Go-Live | 48 hours before/after | Freeze on affected applications only |
How code progresses through environments, especially for cross-project features requiring coordinated releases.
| Environment | Purpose | Deploy Trigger | Retention |
|---|---|---|---|
| Dev | Individual feature branches, local integration | Auto on push to feature branch | Until branch deleted |
| Staging | Integration testing, API contract validation | Auto on merge to main | Continuous (latest main) |
| Beta | Pre-production QA, stakeholder review | Manual promotion from Staging | 48-72 hours max |
| Production | Live customer traffic | Tuesday/Thursday deploy windows | Permanent |
Dev → Staging (auto) → Beta (QA sign-off) → Production (deploy window)
Standard path. QA verifies in Beta, Project Lead approves for production.
When a feature requires work from multiple projects (e.g., Dashboard needs Core API changes):
| Sprint Day | Upstream (Core) | Downstream (Dashboard) | Environment |
|---|---|---|---|
| Day 1-3 | Build API changes | Work on non-blocked items | Dev |
| Day 4 | Merge to main | — | Core → Staging |
| Day 5-7 | Stabilize, fix issues | Integrate against Core Staging | Dashboard Dev → Staging |
| Day 8 | Promote to Beta | Promote to Beta | Both → Beta |
| Day 9 | Joint QA sign-off | Joint QA sign-off | Beta |
| Day 10 | Deploy together | Deploy together | Production |
| Rule | Policy | Enforced By |
|---|---|---|
| Upstream-First | Upstream project must be in Staging ≥24 hours before downstream integrates | Project Leads |
| Coordinated Beta | Cross-project features promoted to Beta together on same day | Both Project Leads |
| Joint Deploy Window | Dependent projects deploy in same Tuesday/Thursday window; upstream deploys first | Johnmary (DevOps) |
| Rollback Scope | If either project fails QA in Beta, both are held until fixed | Project Leads + QA |
| Transition | Maximum Time | Escalation |
|---|---|---|
| Staging → Beta | 48 hours after QA-ready | Project Lead escalates to HoE |
| Beta → Production | Next available deploy window (72 hours max) | Project Lead escalates to HoE |
| Beta Retention | 72 hours max before auto-clear | Johnmary clears stale Beta deploys |
Access: All engineers + QA + PM + select stakeholders
Data: Anonymized production snapshot, refreshed weekly
Owner: Johnmary (DevOps) manages infrastructure; Project Leads own their features
Conflict resolution: If multiple projects need Beta simultaneously, coordinate at Weekly Sync; HoE arbitrates if needed
Key metrics tracked to measure engineering health and delivery effectiveness. Reviewed monthly at Engineering Leads Sync.
| Metric | Definition | Target | Measured By |
|---|---|---|---|
| Sprint Velocity | Story points completed per sprint (per project) | Consistent ±15% variance | JIRA |
| Sprint Commitment | % of sprint scope completed vs. planned | >80% | JIRA |
| Cycle Time | Days from "In Progress" to "Done" | <5 days for standard tickets | JIRA |
| Lead Time | Days from ticket creation to production | <10 days for roadmap items | JIRA |
| Metric | Definition | Target | Measured By |
|---|---|---|---|
| Escaped Defects | Bugs found in production per sprint | <3 P2+ bugs per sprint | JIRA |
| Code Coverage | % of code covered by automated tests | >70% (new code) | CI/CD |
| PR Review Time | Hours from PR opened to first review | <4 hours (business hours) | GitHub |
| Metric | Definition | Target | Measured By |
|---|---|---|---|
| MTTR | Mean Time To Recovery (P1/P2 incidents) | <4 hours (P1), <8 hours (P2) | Incident log |
| Uptime | System availability (Core, Dashboard, Atlas) | >99.5% | Monitoring (Datadog) |
| Deployment Frequency | Production deploys per week | 2+ per project | CI/CD |
| Change Failure Rate | % of deployments causing incidents | <5% | Incident log + CI/CD |
Weekly: Velocity + escaped defects reviewed at Project Leads Sync
Monthly: Full metrics dashboard reviewed at Engineering Leads Sync
Quarterly: Trends analysis at Resource Allocation Planning