본문으로 건너뛰기

Governance

누가 책임지는가? 어떤 규칙을 따르는가?

Governance at Kyndof means clear accountability, transparent decision-making, and systematic processes that ensure every choice has an owner, every action has authorization, and every outcome can be traced to its origin. Good governance doesn't slow down execution—it accelerates it by eliminating ambiguity about decision rights and approval paths.

Understanding Kyndof's governance model helps you know when you can act independently, when you need approval, whose input matters for which decisions, and how to escalate when stuck. This clarity transforms governance from bureaucratic overhead into execution infrastructure.

Governance Philosophy​

Kyndof's governance balances two critical tensions:

Speed vs. Control: Teams need autonomy to move fast, but organizations need coordination to prevent chaos. We push decision authority as low as possible while maintaining appropriate oversight for consequential choices.

Accountability vs. Collaboration: Every decision needs exactly one owner (Accountable party) to prevent diffusion of responsibility, yet most meaningful decisions benefit from multiple perspectives. RABSIC framework provides both clear accountability and structured collaboration.

The governance system codifies these balances through explicit frameworks (RABSIC), systematic workflows (approvals), and transparent tracking (decision log). Governance rules apply equally to everyone regardless of seniority—authority derives from role assignment and approval matrices, not organizational politics.

Governance Framework Overview​

Kyndof governance rests on four interconnected pillars:

1. RABSIC Accountability Framework​

Every decision assigns six potential roles—Responsible (does the work), Accountable (owns the outcome), Backup (covers for Responsible), Support (helps Responsible), Informed (notified after), Consulted (provides input before). The iron rule: exactly ONE Accountable per decision.

RABSIC prevents both unowned decisions (everyone's responsibility becomes no one's responsibility) and consensus paralysis (requiring everyone's agreement grants everyone veto power). One person owns the outcome; many people contribute to the decision.

2. Approval Workflows​

Not every action requires approval—most day-to-day work proceeds autonomously. Approval requirements trigger based on impact, scope, reversibility, and risk. Approvals fall into tiers: no approval needed, role-based approval, executive approval, or board approval.

Well-designed approval workflows prevent both bureaucratic bottlenecks (approving trivial choices) and reckless execution (acting without necessary authorization). Clear approval criteria eliminate guesswork about when approval is needed and who can grant it.

3. Escalation Mechanisms​

When issues exceed your authority, require cross-functional coordination, or face persistent blockers, escalation paths provide clear routes to higher-level decision-making. Escalation isn't failure—it's recognizing when problems need broader perspective or greater authority.

Effective escalation accelerates resolution by getting the right decision-makers involved at the right time. Poor escalation wastes leadership attention on problems teams should solve independently.

4. Decision Tracking​

Major decisions get documented with context, alternatives, rationale, and expected outcomes. Decision logs prevent organizational amnesia—six months later, teams understand why choices were made even when original decision-makers have moved on.

Decision tracking enables learning through pattern analysis: which decision types succeed or fail, which assumptions prove accurate, and how to improve decision quality over time.

핵심 문서 가이드​

RABSIC Framework​

언제 읽나: 새 프로젝트 시작 시, 의사결정 책임 불명확 시, 팀 협업 구조 설계 시

RABSIC의 6가지 역할(R-A-B-S-I-C) 정의와 실제 적용법을 다룹니다. 모든 의사결정에 적용되는 기본 프레임워크입니다.

핵심 질문 해결:

  • 이 결정에서 누가 최종 책임자인가?
  • 누구의 승인이 필요한가?
  • 누구에게 의견을 물어야 하나?
  • 결정 후 누구에게 알려야 하나?

Decision Types​

언제 읽나: 승인이 필요한지 판단할 때, 결정 수준을 가늠할 때

Kyndof의 결정 유형별 특성, 누가 결정 권한을 가지는지, 에스컬레이션 경로를 설명합니다.

핵심 질문 해결:

  • 이 결정은 어떤 범주에 속하나? (전술적/운영적/전략적)
  • 내가 단독으로 결정할 수 있나?
  • 누구의 승인이 필요한가?
  • 잘못 판단하면 어떤 영향이 있나?

Approval Process​

언제 읽나: 승인 요청할 때, 승인 대기 중일 때, 막혔을 때

실제로 승인을 받는 방법—요청 작성법, 응답 시간 기대치, 막혔을 때 대처법을 다룹니다.

핵심 질문 해결:

  • 승인 요청에 무엇을 포함해야 하나?
  • 응답을 얼마나 기다려야 하나?
  • 승인자가 응답 안 하면?
  • 거절당하면 어떻게 하나?

Approval Workflows​

언제 읽나: 표준 승인 프로세스 이해할 때, 특정 상황별 승인 규칙 찾을 때

세부적인 승인 워크플로우—프로젝트 시작, 예산 지출, 기술 아키텍처, 채용, 정책 변경 등 상황별 승인 규칙을 상세히 설명합니다.

핵심 질문 해결:

  • 이 유형의 결정은 표준 프로세스가 있나?
  • 순차 승인인가 병렬 승인인가?
  • 긴급 상황에서는 어떻게 하나?

Escalation Paths​

언제 읽나: 막혔을 때, 갈등 상황일 때, 빠른 결정이 필요할 때

언제 에스컬레이션해야 하는지, 어떻게 효과적으로 에스컬레이션하는지를 다룹니다.

핵심 질문 해결:

  • 지금 에스컬레이션해야 하나?
  • 누구에게 에스컬레이션하나?
  • 어떻게 요청을 작성하나?
  • 에스컬레이션 안티패턴은 무엇인가?

Decision Log​

언제 읽나: 과거 의사결정 이유 궁금할 때, 유사한 선례 찾을 때

주요 조직 의사결정 기록과 그 배경, 결과를 담고 있습니다. 현재 상태가 "왜" 이렇게 되었는지 이해하는 데 유용합니다.

핵심 질문 해결:

  • 왜 이 기술을 선택했나?
  • 과거에 비슷한 결정은 어떻게 했나?
  • 당시 어떤 대안을 고려했나?
  • 결정 결과는 어땠나?

실전 시나리오별 가이드​

"나는 이 결정을 내릴 권한이 있나?"​

  1. Decision Types에서 결정 유형 확인
  2. RABSIC Framework에서 당신의 역할 확인
  3. 권한 범위 초과 시 → Approval Process 참조

"승인이 필요한데 어떻게 하나?"​

  1. Approval Process에서 요청 템플릿 확인
  2. Approval Workflows에서 해당 상황별 프로세스 확인
  3. 요청 제출 후 타임라인 대로 대기

"승인자가 응답을 안 해요"​

  1. Approval Process의 타임아웃 섹션 확인
  2. 리마인더 시점 도달 시 자동 알림
  3. 2차 타임아웃 시 Escalation Paths 활용

"팀 간 의견 충돌로 막혔어요"​

  1. RABSIC Framework에서 Accountable 확인
  2. Accountable에게 의사결정 요청
  3. 여전히 해결 안 되면 Escalation Paths 참조

"과거에 이런 결정 어떻게 했나?"​

  1. Decision Log에서 유사 사례 검색
  2. 당시 RABSIC matrix 확인
  3. 선례를 현재 상황에 적용

Position별 기본 권한​

Position기본 RABSIC 역할주요 권한
CEOA (최종 의사결정)전략/투자/정책 최종 승인
CTOA (기술), C (비즈니스)기술 아키텍처/보안 최종 승인
Department HeadA (부서 내), C (타 부서)부서 예산/채용/프로젝트 승인
Team LeadR (팀 업무), A (팀 내)팀 내 운영 결정
Individual ContributorR (할당 업무), S (협업)할당된 작업 실행

이 기본 권한은 시작점이며, 구체적인 의사결정마다 RABSIC matrix가 별도로 할당됩니다.

Governance Principles in Practice​

Principle 1: Position > Person​

All governance references use role/position names, never individual names. This ensures organizational continuity when people change. System operates independently of who fills the role.

Example: "CTO approves architecture decisions" not "Sean approves architecture decisions."

Principle 2: Exactly One Accountable​

Every decision must have precisely one Accountable party. Shared accountability becomes no accountability. Multiple people can contribute (Responsible, Support, Consulted), but one person owns the outcome.

Example: Project has one Project Owner (Accountable) even if multiple engineers implement (Responsible).

Principle 3: Trust the Process​

RABSIC framework governs decision flow systematically. Approval rules enforce equally for all requests regardless of seniority. Authority derives from role + approval matrices, not organizational politics.

Example: CEO's budget requests follow same approval process as everyone else's when exceeding single-approver thresholds.

Principle 4: Document Major Decisions​

Significant choices get recorded with context, alternatives, and rationale. Organizations forget reasoning faster than decisions. Documentation prevents organizational amnesia.

Example: Technology selection includes Architecture Decision Record explaining why this choice over alternatives.

Governance Tools and Systems​

RABSIC-Engine Agent​

Determines which roles must be assigned for decisions, generates accountability matrix, enforces the "exactly ONE Accountable" rule, and tracks assignments.

Use: Invoke when setting up new project, complex multi-role decision, or accountability disputes.

Back-Writer Agent​

Publishes decisions and approvals to external systems (Notion boards, Slack channels). Ensures organizational visibility without manual notification overhead.

Use: Auto-invoked after major decisions to broadcast outcomes.

Approval Tracking System​

Maintains records of all approval requests, decisions, timelines, and rationale. Enables pattern analysis and process improvement.

Location: .omc/state/approvals.json (runtime state), world-model/databases/approvals.json (historical record)

Decision Archive​

Structured repository of major decisions using Architecture Decision Record format.

Location: world-model/knowledge/decisions/ (full archive), this decision log (highlights)

데이터 소스​

SourcePathPurpose
Decisionsworld-model/databases/decisions.json의사결정 기록
Approvalsworld-model/databases/approvals.json승인 내역 추적
RABSIC Matrixworld-model/databases/rabsic-matrix.json역할 할당 매트릭스
Positionsworld-model/databases/positions.json조직 역할 정의
Decision Archiveworld-model/knowledge/decisions/ADR 형식 상세 기록

Common Governance Questions​

Q: Do I need approval for this? Check Decision Types to categorize your decision, then Approval Process for specific approval requirements.

Q: Who is the Accountable party for this decision? Check RABSIC Framework for role definitions. If unclear, use RABSIC-Engine agent to generate accountability matrix.

Q: My approver isn't responding. What do I do? See Approval Process timeout section. System auto-escalates after defined periods.

Q: Can I escalate my manager's decision? Yes. See Escalation Paths for guidance on escalating manager decisions professionally.

Q: Where do I find past decisions on similar topics? Check Decision Log for major decisions. Full archive at world-model/knowledge/decisions/.

Q: How do I propose a policy change? Follow Approval Workflows policy change section. Requires stakeholder consultation before approval.

관련 문서​