| 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之一