CSO / SL / IC — RACI

Purpose: Make the role seams explicit for every recurring delivery decision. This is the single reference for “who owns what” at the intersection of CSO, SL, and IC responsibilities. It is the operational companion to the roles overview.

Use this when:

• a decision is falling through the cracks between roles
• accountability is unclear at a handoff point
• onboarding a new CSO or SL pairing

---

RACI key

Symbol	Meaning
R	Responsible — does the work / drives to resolution
A	Accountable — single owner; the buck stops here
C	Consulted — must weigh in before decision is final
I	Informed — notified when decision or output is complete

One A per row. Multiple R/C/I are fine.

---

1. Planning & plan integrity

Decision / Activity	HoD	CSO	SL	IC
Author SOW ↔ project plan §§2–4 (initiatives, projects, milestones)	I	A/R	C	I
Author §5 technical approach and effort estimate	I	C	A/R	C
Resolve open questions (§6) before sign-off	C	A	R	C
Sign off on plan before PRM	A	R	R	—
Present plan at Project Review Meeting	A (reviewer)	R (presenter)	C	—
Approve or send back plan	A/R	I	I	—
Trigger re-gate when technical assumptions shift materially	C	A	R	C
Trigger re-gate when client scope changes materially	C	A/R	C	I

---

2. Client routing & communication

Decision / Activity	HoD	CSO	SL	IC
Own external client narrative	I	A/R	C	—
Maintain daily client touchpoint cadence and weekly summary	I	A/R	C (optional)	I
Communicate timeline changes to client	I	A/R	C	—
Communicate scope changes to client	C	A/R	C	—
Communicate technical risks to client	I	A/R	R (drafts framing)	—
Respond to sponsor relationship escalation	C	A/R	I	—
Capture expansion or renewal signals	I	A/R	C	I
Side-channel commitments or scope shifts to client	—	A (must own)	prohibited	prohibited

---

3. Quality handoffs & technical delivery

Decision / Activity	HoD	CSO	SL	IC
Own deliverable quality on the build	—	I	A	R
Technical sign-off before client-visible output	—	I	A/R	C
Code review / artifact review	—	—	A	R
IC unblock (technical decisions, design choices)	—	I	A/R	R
Scope creep decision — accept new build work	C	A	R (technical cost)	I
Flag quality risk that affects client timeline	I	R (tells client)	A/R (flags first)	C
Allocation and roster accuracy for IC team	I	I	A/R	—
Playbook authorship and codification	I	I	A/R	C

---

4. Escalation & risk

Decision / Activity	HoD	CSO	SL	IC
Surface delivery risk internally (first to act)	—	A (client risk)	A (tech risk)	R (escalate up)
Escalate technical blocker	—	I	A/R	R
Escalate sponsor-visible timeline risk	C	A/R	R (provides data)	I
Escalate repeated IC performance misses	A	I	A/R	—
Escalate CSO/SL deadlock	A/R	R (presents options)	R (presents options)	—
Escalate systemic cross-engagement risk	A/R	R	R	I
Decide when re-plan is required	A	R	R	—

---

5. IC management & team health

Decision / Activity	HoD	CSO	SL	IC
Set IC technical direction	—	I	A/R	C
Assign IC to tickets	—	C (priority/context)	A/R	—
Coach IC on execution quality	—	I	A/R	—
Coach IC on communication standards	C	A/R	C	—
Raise IC performance concern	C	C	A/R	—
Linear hygiene pass (when PM-focused IC assigned)	I	C	A (technical board truth)	R
Linear hygiene pass (when no PM-focused IC assigned)	I	C	A/R	C

---

6. The hard seam: where CSO and SL must align

These are the situations that break most often when the pairing is not working:

Situation	What must happen
Client asks for something new mid-engagement	CSO captures request, SL estimates cost, CSO communicates back — no unilateral commitment either direction
Build is behind but client narrative says on track	SL surfaces the gap, CSO resets narrative — same story, same day
SL says a date is technically impossible	CSO does not override; they partner to find options, then present a choice to HoD if needed
CSO makes a client commitment without SL input	SL flags immediately; CSO acknowledges and aligns or escalates — no silent carry
IC escalates to CSO directly on a technical question	CSO routes to SL; does not answer in isolation

---

7. Scenario rules

Use these rules when the RACI matrix is not enough and the team needs to know what happens in the messy version of the situation.

7.1 Client asks for new work midstream

Scenario: Client asks for an extra dashboard, feature, report, automation, or analysis during an active sprint / delivery cycle.

Rule:

1. CSO responds first to acknowledge the ask and set expectation: Brainforge will evaluate it, not automatically take it on.
2. CSO immediately gets SL estimate for technical cost, delivery risk, and whether current sprint capacity can absorb it.
3. No implicit commitment. CSO should not say or imply “yes” until the SL has estimated and the CSO has decided whether to trade off existing scope.
4. CSO decides client priority tradeoff after SL estimate: add it, defer it, decline it, or swap it for something already in the cycle.
5. Linear artifact required within 24h: the ask must be logged as a ticket, backlog item, scope note, or declined request with rationale.

Accountability if it goes wrong:

• CSO miss if the client hears a commitment before SL estimate / tradeoff.
• SL miss if estimate is not provided quickly enough for CSO to route the ask.
• Pairing miss if the ask sits in Slack without a clear route.

7.2 SL blocks a client promise or demo

Scenario: CSO has told the client a demo / milestone is coming, but SL says the work is not technically ready.

Rule:

1. SL can stop the demo if delivery quality or trust risk is real.
2. SL must provide an alternative path, not just “no”: e.g. smaller demo, delayed demo, internal preview, or a specific path to readiness.
3. CSO owns client reset because the external narrative is CSO-owned.
4. HoD should be looped in when the demo miss is material, sponsor-visible, or indicates poor planning.
5. PM-focused IC documents the miss in the project record: what was promised, what was incomplete, why it was not ready, and what changed.

Accountability if it goes wrong:

• SL miss if the project was poorly scoped, capacity was misread, or technical readiness was not surfaced early.
• CSO miss only if the CSO ignored known technical risk or overpromised against SL input.
• IC miss only if assigned work was not executed to standard and that contributed to the readiness failure.

Documentation required: project note or Linear comment that names the miss, root cause, owner, revised date, and client reset plan. This should not become a he-said/she-said issue.

7.3 IC gets conflicting direction

Scenario: CSO says “prioritize client-facing polish” while SL says “fix the data model first.”

Rule:

1. IC follows SL by default for technical sequencing and execution order.
2. IC flags the conflict to both CSO and SL in the shared channel or Linear thread.
3. CSO and SL must resolve the tradeoff; IC should not be forced to adjudicate between client optics and technical order.
4. Final decision must be written in Linear or the shared account thread.

Accountability if it goes wrong:

• If IC follows SL and client expectation is missed because CSO/SL did not align, this is a CSO-SL alignment failure.
• Both CSO and SL can be marked down if the conflict was visible and unresolved.
• IC should not be penalized for following SL direction when technical sequencing was the issue.

7.4 Client asks IC for technical detail or timing

Scenario: Client tags an IC directly and asks for implementation details, technical status, or timeline.

Rule:

1. IC may answer with helpful factual context when they know the answer and it does not create a commitment.
2. Timeline, priority, or scope questions loop in CSO.
3. Implementation detail, feasibility, or technical-quality questions loop in SL.
4. IC should avoid client-facing commitments about “when” or “what we will do” unless CSO / SL has already aligned.

Acceptable IC response:

“I can share context on what I’m seeing. Looping in [SL] for technical confirmation and [CSO] for timing / priority so we do not give you a half-answer.”

Anti-pattern: IC becomes the de facto account lead in the client channel, answering scope/timeline/commitment questions while CSO and SL are unaware.

7.5 Done ticket gets reopened

Scenario: IC marks ticket done, SL signs off, client finds an issue two days later.

Rule:

1. Treat it as rework unless there is clear evidence it is a new client request or changed expectation.
2. SL owns the quality gate; IC owns execution quality.
3. If SL approved the handoff, SL accepted that the work was ready.
4. PM-focused IC owns the postmortem / playbook update workflow after root cause is agreed.

Accountability if it goes wrong:

• IC miss if the work failed agreed acceptance criteria.
• SL miss if the quality gate failed to catch the issue.
• CSO miss only if they rushed the handoff against known SL / IC quality concerns.

Documentation required: reopen reason, whether it was a bug/rework vs new request, owner, fix path, and playbook / checklist update if the failure is repeatable.

7.6 Combined CSO / SL on small clients

Scenario: One person holds both CSO and SL for a small client.

Rule:

1. Combined CSO/SL is only acceptable for small clients where the deal size and complexity do not justify separate role coverage.
2. HoD is the check on the combined owner’s work.
3. The PM-focused IC / project manager must understand that the same person is wearing both hats and should help keep the project record clear.
4. The combined owner should document client narrative decisions and technical readiness decisions separately when the distinction matters.

Bonus note: A combined CSO/SL can qualify on both tracks for that client only if the client is large enough and the work is material enough to assess both functions. For very small clients, the bonus impact may be too small to assess cleanly at a client-by-client level.

7.7 Founder intervention

Scenario: Client pings founder directly because they are confused, concerned, or frustrated about progress.

Rule:

1. Default classification is CSO miss unless there is evidence the CSO had already escalated clearly and intentionally.
2. Weekly operating review should inspect whether relationship map, escalation path, and client communication cadence were understood.
3. The review should focus on early signals: client coming to the wrong person, new stakeholder bypassing CSO, unclear escalation channel, or relationship friction that should be handled before a founder ping.
4. PM-focused IC helps maintain the review record and flags patterns where client requests / escalations are not entering the system cleanly.

Accountability if it goes wrong:

• CSO miss if client confusion should have been prevented by daily touchpoint cadence or clearer expectation-setting.
• Pairing miss if the root cause is client narrative diverging from technical reality.
• HoD intervention if the escalation channel or account map is structurally unclear.

7.8 First-touch routing

Scenario: Client asks a blended question: “Is this in scope, and does the data pipeline quality issue affect launch?”

Rule:

1. CSO owns first response.
2. CSO handles scope / timeline framing.
3. SL supplies technical-quality answer.
4. A call is appropriate only when async answer would be misleading, when CSO and SL need alignment before response, or when the client needs live reassurance.
5. Founder escalation on first-touch routing is a CSO miss unless CSO had already escalated intentionally with options.

First-touch success: Client receives a clear owner, clear answer path, and next step without needing a second call just to figure out who owns the request.

Anti-pattern: Optimizing for “no call needed” by sending overconfident async answers before CSO and SL are aligned.

---

Related

• Roles overview
• CSO role definition
• SL role definition
• IC escalation path
• Project ownership guide
• Delivery KPI dictionary

---

Last updated: 2026-04-27