| name | face-accountability-chart |
| description | 用户在组织架构混乱、职责不清、团队出现"这个事该谁负责"的冲突时；
或在问"我们公司缺什么样的人"/"为什么我们总是找不到对的人"/"领导层有没有在对的位置"时激活。
不适用于：个人岗位描述、基层员工绩效评估、早期2-5人创始团队。
|
| source_book | 《Scaling Up》Verne Harnish |
| source_chapter | 第3章 The Leaders |
| tags | ["organization","accountability","people","leadership","hiring"] |
| related_skills | ["dumbest-in-the-room(depends-on)","leadership-triple(depends-on)","rockefeller-habits(composes-with)","pace-process-chart(composes-with)","right-people-right-things(depends-on)"] |
FACe 功能 Accountability Chart
R — 原文 (Reading)
"The FACe tool provides a list of seats (functions) that all organizations must fill. You want to delegate these functions to people who fit your culture and pass two tests: 1. They don't need to be managed. 2. They regularly wow the team with their insights and output."
— Verne Harnish, Scaling Up, 第3章
I — 方法论骨架 (Interpretation)
FACe（Function Accountability Chart，功能问责表）解决的是"对的人在对的位置上"的问题。
核心逻辑：
Scaling Up的障碍之一是"瓶颈永远在瓶口"——组织顶层的功能如果没有合适的人来填，所有决策都堵在那里。FACe用一页纸列出企业必须填补的职能座位，并为每个座位指派KPIs和结果指标。
FACe的三个组成部分：
- Seats（功能座位） — 企业必须填补的职能清单，包括：战略/创新、销售/市场、产品/服务、运营/交付、客户成功、财务/合规、人力/文化、技术/IT等
- KPIs（关键绩效指标） — 每个功能每天/每周需要追踪的量化指标，让负责人知道自己是否在轨道上
- Results/Outcomes（结果/成果） — 最终需要交付的财务或运营结果（如：Revenue/Gross Margin/Net Profit/Cash等）
两个测试决定谁坐在哪个座位：
- 测试1：他们不需要被管理（自我驱动）
- 测试2：他们经常用洞察和产出让团队惊叹
与组织架构图的区别：
组织架构图告诉你谁向谁汇报（层级）。FACe告诉你谁对什么结果负责（问责）。层级和问责可以不同——矩阵组织中尤其明显。
典型信号：
- "这事我不知道该找谁"
- "我们有重叠的职责"
- "他明明是VP但产出不够"
- "为什么我们总是错过截止日期"
A1 — 书中的应用 (Past Application)
案例1: Infusionsoft的FACe实践
- 问题: Clate Mask需要在快速扩张中保持组织清晰度
- 方法论的使用: 用FACe明确每个高管负责的结果（Revenue/Gross Margin/Cash），而不是头衔
- 结论: 每次会议都对照FACe讨论进展，确保没有遗漏
- 结果: 年度增长53%，获得5400万投资
案例2: 50人坎的FACe设计
- 问题: 企业从50人向100人扩张时，职能部门开始出现重叠和真空
- 方法论的使用: 在这个阶段，CEO需要坐下来画FACe，明确每个VP负责什么结果
- 结论: 矩阵组织中，职能负责人和业务单元负责人之间必须有清晰分工
- 结果: 避免"谁都管但谁都不负责"的状态
案例3: Dell招Shock Absorber
- 问题: Michael Dell在50人时意识到自己成为公司天花板
- 方法论的使用: 招了专门的HR负责人Barbara Kreisman作为他和组织之间的"缓冲器"
- 结论: 创始人需要把自己的职能也列在FACe上，然后找人来填
- 结果: Dell将公司从创始人依赖型变成组织驱动型，最终Scaling到40,000人
A2 — 触发场景 (Future Trigger) ★
用户会在什么情境下需要这个skill？
- 企业在30-50人时出现"谁负责什么"的混乱 — 业务扩张但架构没跟上，经常出现职责真空或重叠
- 招聘新高管时不知道该设什么KPI — 新VP进来后给什么指标衡量他？
- 高管会议变成"汇报表演"而非决策会议 — 因为没有清晰的问责，每个人只说自己想说的
- 团队出现"瓶颈在顶部"的症状 — 所有审批都到CEO那里，CEO成为决策堵点
- 并购或扩张后组织需要重新对齐 — 买了新公司，但不知道如何整合进现有组织
语言信号（用户的话里出现这些就应激活）
- "这事到底该谁负责"
- "我们有太多重叠的职能"
- "他需要被管着才动"
- "VP进来不知道该做什么"
- "我们需要一个组织架构调整"
- "为什么每次都卡在这里"
- "谁是Revenue的负责人"
- "这个KPI该归谁管"
与相邻skill的区分
- 与
pace-process-chart 的区别: FACe是纵向（职能/层级），PACe是横向（跨职能流程）。需要两者结合才能完整覆盖组织。
- 与
topgrading 的区别: FACe解决"谁坐哪个位置"，Topgrading解决"怎么找到对的人坐那个位置"。FACe在前，Topgrading在后。
E — 可执行步骤 (Execution)
为skill被激活后，按以下步骤执行：
-
列出企业必须填补的职能座位（Seats）
- 完成标准: 有8-12个功能清晰列出，包括：CEO(战略/文化)、Sales/Revenue、Marketing/Brand、Product/Service、Operations/Delivery、Finance/Accounting、HR/People、Technology/IT
- 不遗漏: 思考"我们的业务流程中哪些环节有人负责？"——没有列出的意味着真空
-
为每个座位指派KPIs（可量化指标）
- 完成标准: 每个功能有1-2个每周追踪的量化指标
- 指标类型: 时间（Cycle Time）、成本（Cost %）、质量（Defect Rate）、数量（Volume）
- 判停条件: 若某个功能找不到可量化的KPI，说明这个功能的定义不清晰，回去重写功能定义
-
为每个座位指派Results（财务结果）
- 完成标准: 每个功能对应一个或多个财务/运营结果（通常对应P&L上的行项目）
- 例子: CFO→Cash/DSO/Expense %；VP Sales→Revenue/Gross Margin；COO→Delivery Cost/Quality
-
识别"空座"并制定填补计划
- 完成标准: 明确标出哪些座位目前有人坐、哪些是空座、哪些坐的人不对
- 判停条件: 若"坐的人不对"，启动Topgrading流程找对的人替换
-
季度回顾FACe
- 完成标准: 每季度对照FACe复盘，确认每个座位的表现
- 判停条件: 若某个座位连续两个季度表现差，启动替换或培训流程
B — 边界 (Boundary) ★
不要在以下情况使用此skill
- 2-10人早期创始团队 — 每个人都是多面手，FACe的精细分工反而限制灵活性
- 个人岗位描述或绩效评估 — FACe是高管层的组织工具，不适合用于基层员工日常考核
- 试图用它解决所有组织问题 — FACe只解决"谁对什么负责"，不解决"流程怎么跑"（那是PACe的工作）
作者在书中警告的失败模式
- 把FACe做成职位描述清单 — FACe强调的是结果和KPI，不是"每天做什么"
- 不更新的FACe — 市场在变，FACe每季度必须更新一次
- 只有人没有KPIs — "有人坐在那里"不等于"那个功能在运转"，必须有KPI追踪
作者的盲点/时代局限
- 远程/分布式组织: 书中主要讨论的是实体组织，远程团队的功能分工可能有不同逻辑
- 平台型组织: 平台+生态的模式下，"座位"的定义可能变成"内部创业者"而非传统职能
容易混淆的邻近方法论
- OKR: OKR是个人/团队目标工具，FACe是组织级问责工具。OKR服务于FACe，而非相反
- 组织架构图: 组织图是层级汇报图，FACe是结果问责图。看组织图知道"谁向谁报告"，看FACe知道"谁对什么结果负责"
相关skills（阶段3填充）
- depends-on:
topgrading（找到对的人坐对的座位）
- contrasts-with:
pace-process-chart（FACe纵向vs.PACe横向）
- composes-with:
4d-framework（FACe是People决策的执行工具）
审计信息
- 验证通过: V1 ✓ / V2 ✓ / V3 ✓
- 测试通过率: 待阶段4测试
- 蒸馏时间: 2026-04-26
- 示范批次: 5个示范SKILL.md之一
