Responsibility Without Authority Is the Oldest PM Trap.
Sprint velocity 33 percent below baseline. Two strong technical leads each accountable for the same gap. The RACI conversation that should have happened in Phase 1.
Two Sprints Below Baseline. Same Cause Both Times.
The microservices platform was the unsung star of Phase 2 until sprint 11. Sprints 7 through 10 had averaged 50 points, slightly above baseline. Sprint 11 closed at 32 points. Sprint 12 closed at 32. Two data points are not yet a trend. They are also not yet a coincidence.
The PM booked forty-five minutes with Priya Raman (Technical Lead) and Jin-ho Park (Development Lead) on 4 August. The conversation did not need to be longer than that. Within fifteen minutes, both engineers had described the same root cause from their two different vantage points.
The Falcon program had no RACI matrix. The charter (Post 02) had named decision authority at program level. The Stakeholder Register (Post 03) had tiered governance. But no artifact spelled out, at the activity level, who is Responsible for executing each piece of cross-cutting work, who is Accountable for the outcome, who must be Consulted, and who must be Informed. For the first ten sprints this had not mattered. By sprint 11 it mattered enough to cost 33 percent of velocity.
One Activity Was Actually Four.
The first instinct was to draft a RACI with one line called “Observability” and assign it to a single team. That was the wrong instinct, and the conversation with Raman and Park made it visible quickly. Observability on a 19-microservice platform is not one activity. It is at least four, and they have different natural ownership.
Logs are service-owned. Each microservice writes its own logs and decides what to log, what to redact, and how long to retain. The platform team can publish logging conventions, but the service team executes.
APM dashboards are platform-owned. Cross-service views require a single source of definitions for SLIs and SLOs. Asking each service team to define its own dashboards produces 19 incompatible dashboards. Platform owns this; services consume it.
Distributed tracing is shared. The platform owns the instrumentation library and the trace collector. Each service is responsible for propagating trace IDs correctly across its calls. Neither owns it alone.
Quality gates are platform-defined, service-enforced. Platform sets the gate thresholds. Each service team is responsible for keeping their service compliant. Platform cannot enforce; services cannot define.
The decomposition was the unlock. Once observability was four lines instead of one, R/A/C/I assignments became obvious. The next morning the PM scheduled a working session with Raman, Park, Hassan, and Volkov to author the matrix.
Volkov’s Team Was Also Writing Microservices.
The integrator team was building several of the 19 services. The question that surfaced in the working session: do they own observability for their own services, or is it a platform-applied responsibility uniform across all services?
Volkov argued for the first. His position was contractual: the integrator scope is what is in the contract; observability for vendor-built services is what was scoped. Alemu argued for the second. His position was operational: Atlas Bank carries the readiness consequence at go-live; uniform observability is a precondition for production support, regardless of which team wrote which service.
Both were correct from where they sat. The resolution was procedural, not commercial. Vendor team gets a named role on the RACI matrix, distinct from Park’s development team. Where the contract scoped a vendor responsibility, the cell carries an explicit contract clause reference. Where Atlas Bank applied responsibility on top, the cell shows it as a platform-uniform requirement with the vendor as Consulted, not Responsible. The RACI did not relitigate the contract; it documented where contract met operational reality.
Platform Team (Raman) · Development Team (Park) · Integrator Team (Volkov, with contract clause references where applicable) · CTO Function (Alemu, Accountable on cross-service concerns) · PMO (Hassan, Informed on operational matters; Consulted on governance changes).
Drafting the RACI
The prompt below uses APE: Action, Purpose, Expectation. Lightest framework used in the series so far. RACI drafting does not need elaborate context, audience segmentation, or worked examples; the activity is bounded (identify activities, assign roles), the structure is fixed (matrix), and the validation is operational (named stakeholders sign or push back). Framework complexity matching task complexity, extended principle: sometimes the right framework is the minimum framework.
RACI Draft, Extract
The AI produced a 12-row matrix. Three flagged items are shown below; the human edits resolved each before the matrix went to working session.
1. “Observability” treated as single row. Decomposition into Logs, APM, Tracing, Quality is correct; single-row treatment loses the ownership distinctions that resolve the velocity issue. Recommend four rows.
2. Accountable column applied to CTO Function across all observability activities. CTO is correctly Accountable for cross-service concerns (APM, Tracing platform layer, Quality gates definition). For per-service concerns (Logs, service-level Quality compliance), Development Lead (Park) is the more accurate Accountable, with CTO as Consulted. Recommend split.
3. C and I distinction soft. Several rows assign C (Consulted) where the actual practice is I (Informed). C means review before decision; I means notify after decision. Soft Cs become bottlenecks because reviewers expect input opportunity that the workflow does not actually provide. Recommend tightening.
The third flag was the one the PM had not seen coming. The instinct in regulated environments is to over-Consult; it feels safer. In practice, over-Consulting produces meetings where the Consulted parties expect to drive decisions they were never going to drive, and the velocity penalty is identical to no RACI at all. Tightening C versus I was the single edit that mattered most for sprint velocity recovery.
RACI Matrix v1.0, Extract
Published 15 August 2025. Eight rows shown across the 12-row matrix, focused on the observability stack and the three other cross-cutting activities where ownership ambiguity had cost velocity.
| Activity | Platform (Raman) |
Development (Park) |
Integrator (Volkov) |
CTO Function (Alemu) |
PMO (Hassan) |
|---|---|---|---|---|---|
| Service log shape and retentionPer-service logging policy and execution | C | R | RPI-2024-11 cl. 4.2 | A | I |
| APM dashboards and SLI/SLO definitionsCross-service performance visibility | R | C | I | A | I |
| Distributed tracing instrumentationTrace collector platform layer | R | C | C | A | — |
| Trace ID propagation per serviceService-level trace continuity | C | R | RPI-2024-11 cl. 4.2 | A | — |
| Quality gate thresholds (SonarQube)Platform-defined coverage, complexity gates | R | C | I | A | — |
| Quality gate compliance per serviceService-level enforcement | I | R | RPI-2024-11 cl. 5.1 | A | — |
| Production deployment release authorityPer-service deploy decisions | C | R | R | A | I |
| Incident response (sev-1 and sev-2)On-call rotation, post-incident reviews | R | C | C | A | I |
- Decomposed Observability into four rows. AI flagged this as a candidate. PM made it the structural decision: Logs (service-owned), APM (platform-owned), Tracing (shared), Quality Gates (platform-defined, service-enforced). One ownership model did not fit all four; four rows resolved the ambiguity that two consecutive sprints could not.
- Split Accountable between Park and Alemu. AI assigned Alemu as A across the matrix. PM kept Alemu as A for cross-service concerns (APM, Tracing platform, Quality definition) but assigned Park as A for per-service concerns (Logs, Quality compliance). Accountability tracks consequence, not seniority.
- Tightened C versus I throughout. AI used C generously where I was operationally accurate. PM converted soft Cs to Is where the workflow did not actually require pre-decision review. Reduced expected meetings per cross-cutting decision from 4 to 2 in the most affected areas.
- Added Integrator Team as a distinct role with contract references. AI bundled vendor team into Development. PM separated, citing contract clauses (PI-2024-11 cl. 4.2 for service log responsibility, cl. 5.1 for quality compliance). Where vendor team carries R, the contract clause is referenced inline; where Atlas Bank applied responsibility on top, the cell shows operational rationale.
- Added quarterly review cadence. AI treated RACI as static. PM made it a living artifact: reviewed at every quarterly risk review (Post 06 governance), disputes escalated to steering. The microservices platform was the first beneficiary; future cross-cutting concerns (security patching, dependency upgrades) will be added as they surface.
Sprint 13 (first sprint after RACI sign-off) closed at 38 story points. Sprint 14 closed at 42. Sprint 15 closed at 44 against the 48-point baseline. Not perfect, but the three-to-four-days-per-sprint ownership argument had gone. The September status report converted the microservices Amber to Green with rationale citing the RACI publication. The full 48-point baseline returned by sprint 17, when teams had internalised the matrix to the point where it stopped being a reference document and started being how they thought about responsibility. The RACI also surfaced in a subsequent vendor scope discussion: Volkov’s senior partner referenced the contract-clause cells when a downstream service was reassigned mid-Phase 2. Because the RACI made vendor scope explicit, the discussion was procedural rather than confrontational. The artifact is doing work the contract was never going to do alone.
A fictional case study for teaching purposes. Atlas Bank, Project Falcon and all named individuals are invented. Technologies are industry-standard and publicly available.