以下情境为教学假设,人物与数字不代表经核实的真实案例。
创始人退出日常经营,通常不是因为不想管,而是因为管不动了。客户多了、咨询排期满了、产品订阅要续费、外包要验收、账要收,每一件事都不大,合起来把一天切碎。这时候招一个管理者,看起来是自然答案。但管理者要花多少钱、管多少事、拿到多大权限、向谁汇报,四个问题不回答,招人只会把创始人从「做事」变成「救火」。
这一节用 Nord Studio 做主案例:90 家产品客户、每月 110 小时咨询、年收入 154,320 美元、SDE 34,320 美元、两位合伙人各 50%。目标是回答一个可计算的问题:创始人退出日常经营后,需要几名管理者、成本多少、授权边界画在哪、监督要花多少时间。所有工时、费率、薪资和阈值都是教学假设,不构成法律、税务或投资建议。
工作量从哪来:90 家产品客户与 110 小时咨询
管理者的数量不是按「感觉忙不忙」定的,而是按工作量定的。Nord 的日常经营可以拆成三块:产品客户支持、咨询项目协调、行政与财务。三块都能量化成小时。
| 工作块 | 数量 | 单位工时(教学假设) | 月度小时 |
|---|---|---|---|
| 产品客户支持 | 90 家 | 0.35 小时/家/月 | 31.5 |
| 咨询项目协调 | 110 小时/月 | 0.15 小时/咨询小时 | 16.5 |
| 行政、财务、排期 | 20.0 | ||
| 合计 | 68.0 |
68 小时/月,折 15.7 小时/周,816 小时/年。这个数字的意思是:如果这些工作全部由创始人做,他每周要拿出近两个工作日;如果交给管理者,一个管理者按 120 小时/月的有效产能,负荷是 56.7%,一个人足够。按 60 小时/月的有效产能(含协调、会议、上下文切换损耗),负荷是 113.3%,需要两个人。
| 有效产能(小时/月) | FTE | 管理者人数 | 年度成本(含 20% 雇佣负担) | 占 SDE | 占产品收入 |
|---|---|---|---|---|---|
| 120 | 56.7% | 1 | $66,000 | 192.3% | 156.7% |
| 90 | 75.6% | 1 | $66,000 | 192.3% | 156.7% |
| 60 | 113.3% | 2 | $132,000 | 384.6% | 313.4% |
| 40 | 170.0% | 2 | $132,000 | 384.6% | 313.4% |
表里的成本按管理者年薪 55,000 美元、雇佣负担 20% 算,合计 66,000 美元。55,000 来自案例事实表的「招聘第三人成本」,20% 是教学假设的社保、福利、设备和行政分摊。1 名管理者的成本是 SDE 的 192.3%,是产品收入 42,120 美元的 156.7%,是总收入 154,320 美元的 42.8%。换句话说,管理者不是从利润里「挤」出来的,他必须先带来新增收入,或者把创始人从 68 小时/月里解放出来去做更高价值的事。
这里最容易犯的错,是把「管理者工资」和「新增收入」直接相减。案例设定的门槛是新增收入 75,000 美元才能覆盖工资与税。把 75,000 放回 Nord 的两条收入线,两条路径都不轻:咨询时长要增加 66.8%,产品客户要增加 78.9%。
| 覆盖路径 | 单价 | 需要数量 | 相对现状 |
|---|---|---|---|
| 咨询 | $85/小时 | 882 小时/年(73.5 小时/月) | 咨询时长增加 66.8% |
| 产品订阅 | $39/月 | 161 家 | 客户数增加 71 家(78.9%) |
管理者的成本不是「多一个人」,而是「多一条增长曲线」;新增收入做不到,管理者会先从现金缓冲里拿钱。咨询每月要从 110 小时加到 183.5 小时,产品要从 90 家加到 161 家,净增 71 家;按 3.0% 的月流失,毛新签还要高于 71 家。
需要几名管理者、成本多少
「需要几名」有两个答案:按工作量算是 1 名,按风险分离算是 2 名。1 名管理者可以覆盖 68 小时/月的日常经营,但他同时管客户、交付、财务和外包,任何一项出问题都没有备份。2 名管理者可以把交付与客户/产品分开,代价是成本从 66,000 美元跳到 132,000 美元,占 SDE 的 384.6%。
| 配置 | 人数 | 年度成本 | 覆盖范围 | 主要风险 |
|---|---|---|---|---|
| 1 名运营管理者 | 1 | $66,000 | 客户支持、排期、行政、外包验收 | 管理者休假或离职即断档 |
| 2 名管理者(交付 + 客户/产品) | 2 | $132,000 | 交付与客户分离,互相备份 | 成本超过 SDE 的 3.8 倍 |
对 Nord,最现实的起点是 1 名运营管理者,把咨询排期、产品支持、外包验收和行政财务接过去;两位合伙人保留客户关系、定价和产品方向。管理者的 66,000 美元替换的是创始人投入的 68 小时/月;按咨询费率 85 美元/小时算,机会成本 69,360 美元/年,刚好覆盖。这个等式成立的前提是:创始人真的把这 68 小时拿去做咨询或产品增长,而不是换成另一种忙碌。
授权边界:金额阈值与事项清单
管理者拿到工作,不等于拿到决定权。授权边界要同时写金额和事项:多少钱以内可以自己批,哪些事项无论金额大小都必须上报。只写金额不写事项,会出现「500 美元以下随便花,但 300 美元的律师函也要创始人签字」;只写事项不写金额,会出现「所有采购都上会」。
| 层级 | 金额阈值(教学假设) | 事项范围 | 谁批准 |
|---|---|---|---|
| 自动 | ≤ $500 | 重复采购、常规工具、客户退款 | 管理者直接执行 |
| 管理者 | $500–$5,000 | 单次采购、外包合同、交付变更 | 运营管理者 |
| 创始人 | $5,000–$20,000 | 招聘、定价、重要客户条款 | 合伙人 |
| 保留 | > $20,000 | 资产处置、融资、出售、核心 IP | 董事会或股东 |
事项清单要单独列,不能只靠金额。定价、法律、资产三类事项无论金额大小都留在创始人或股东手里:一次 0 美元的定价调整,可能改变整条收入线;一份 2,000 美元的律师函,可能决定一场纠纷的走向;一次资产处置,可能把公司最值钱的东西卖掉。代码里的 FOUNDER_ONLY 就是这三类。
授权边界画完后,要用真实请求量检验。下表是 Nord 一个季度的 50 笔请求,合计 35,300 美元,包含客户可报销的交付支出;三套阈值给出三种结果。
| 阈值方案 | 自动 | 管理者 | 创始人 | 保留 | 创始人时间/季度 | 自动批准金额 |
|---|---|---|---|---|---|---|
| 基准:$500 / $5,000 / $20,000 | 32 | 13 | 5 | 0 | 1.7 小时 | $7,200 |
| 授权不足:$100 / $500 / $20,000 | 0 | 32 | 18 | 0 | 6.0 小时 | $0 |
| 授权过度:$5,000 / $20,000 / $100,000 | 45 | 0 | 5 | 0 | 1.7 小时 | $29,300 |
基准方案下,创始人一个季度只处理 5 笔,约 1.7 小时;自动批准金额 7,200 美元,占季度收入 38,580 美元的 18.7%。授权不足方案把 18 笔推到创始人,时间从 1.7 小时涨到 6.0 小时,一个季度多出 4.3 小时,一年 17.2 小时;按 85 美元/小时算,监督成本增加 1,462 美元。授权过度方案把 45 笔自动放行,自动批准金额 29,300 美元,相当于季度收入的 76.0%;创始人只看到 5 笔,但其中没有一笔是定价、法律或资产。
两种失败:授权不足与授权过度
授权不足的表现是「所有事都等创始人」。管理者不敢批、不敢签、不敢承诺交付日期,客户在等,外包在等,创始人成了唯一的瓶颈。它的成本可以用创始人时间算:基准方案 1.7 小时/季度,授权不足方案 6.0 小时/季度,差 4.3 小时/季度、17.2 小时/年;如果创始人每小时的机会成本是 85 美元,一年 1,462 美元。这还只是审批时间,没算等待造成的交付延迟和客户流失。
授权过度的表现是「创始人最后一个知道」。管理者可以批 5,000 美元以内的采购、可以改交付范围、可以承诺折扣,创始人只在季度会上看到汇总。它的成本不是审批时间,而是风险暴露:上表里 29,300 美元的自动批准金额,相当于季度收入的 76.0%;如果其中有一笔是错误定价、一次超范围承诺或一份没有责任上限的合同,损失会超过一年省下的审批时间。
| 失败 | 症状 | 可计算成本 | 修正方向 |
|---|---|---|---|
| 授权不足 | 所有请求上移,管理者不敢决策 | 创始人 17.2 小时/年,$1,462 | 提高自动与管理阈值,写清事项清单 |
| 授权过度 | 创始人只在季度汇总看到结果 | 自动批准 $29,300/季度,占收入 76.0% | 降低自动阈值,定价/法律/资产收回 |
| 边界模糊 | 同一类请求有时批有时不批 | 重复沟通、例外审批、审计困难 | 用金额 + 事项双维度写授权矩阵 |
两种失败的共同点,是授权边界没有和业务规模一起更新。Nord 的 90 家客户、110 小时咨询是一个规模;客户到 150 家、咨询到 180 小时/月,阈值和工作量都要重算。授权矩阵不是一年写一次的文件,它应该跟预算一起每年审一次,在客户数、收入或团队人数变化超过 20% 时临时审一次。
KPI 与汇报节奏:监督成本怎么算
授权之后,创始人不能靠「信任」监督,要靠固定的汇报节奏。汇报太密,管理者变成执行者;汇报太疏,创始人失去判断依据。Nord 的教学假设是四层节奏:每周运营会、每月经营复盘、每季度预算与风险复盘、每年审计与薪酬复盘。
| 节奏 | 时长 | 频率 | 年度小时 | 看什么 |
|---|---|---|---|---|
| 每周运营会 | 0.5 小时 | 52 次 | 26 | 现金、排期、支持积压、交付里程碑 |
| 每月经营复盘 | 2 小时 | 12 次 | 24 | 利润表、MRR、流失、利用率、SDE |
| 每季度预算与风险 | 4 小时 | 4 次 | 16 | 预算 vs 实际、客户集中、产品路线、风险登记 |
| 每年审计与薪酬 | 8 小时 | 1 次 | 8 | 审阅、分红、薪酬、保险、传承 |
| 每周一对一 | 1 小时 | 52 次 | 52 | 优先级、障碍、人员与外包问题 |
| 合计 | 126 |
126 小时/年,折 10.5 小时/月。按创始人 85 美元/小时的机会成本,监督时间是 10,710 美元/年。加上管理者的 66,000 美元,职业化管理的全成本是 76,710 美元,占 SDE 的 223.5%。如果招两名管理者,全成本是 142,710 美元,占 SDE 的 415.8%。这个数字说明:职业化管理不是「花 66,000 美元买 68 小时/月」,而是「花 76,710 美元买一套可交接的经营系统」。
KPI 的选择要和卷一的指标口径一致。MRR、毛利率、流失、SDE、runway 的定义见 10.1 五个核心指标 ,不要在管理报表里另起一套。Nord 的产品月流失是 3.0%,咨询续约率 70%,服务收入占比 72.7%;这三个数字应该出现在每月经营复盘的第一页,而不是埋在项目表里。
汇报节奏还要写「谁准备、谁参会、谁决策」。每周运营会由管理者准备,合伙人参加;每月经营复盘由管理者准备财务包,合伙人决策;每季度预算与风险由合伙人主导,管理者提供数据;每年审计与薪酬由合伙人决定,必要时请外部审阅。没有「谁决策」这一列,汇报会变成信息通报,授权会退回创始人。
把管理写成代码:professional-management.ts
下面的 professional-management.ts 把三件事固化成函数。managementLoad 从客户数、咨询小时和行政小时算月度工作量、FTE、管理者人数与全成本;authorityDecision 按金额和事项给出自动、管理者、创始人、保留四级判断;authorityReview 把一组请求汇总成创始人时间、自动批准金额和各层级数量。
// file: src/capital/professional-management.ts
// tier: L1
// verify: node --test test/capital/professional-management.test.ts
import { type Cents } from "../core/money.ts";
import { type Bps, divide } from "../core/rate.ts";
import { type Result, fail, ok } from "../core/result.ts";
export type ManagementInput = {
productCustomers: number;
supportHoursPerCustomerMonth: number;
consultingHoursMonth: number;
coordinationHoursPerConsultingHour: number;
adminHoursMonth: number;
productiveHoursPerManagerMonth: number;
managerSalaryCents: Cents;
employerBurdenBps: Bps;
minimumManagers: number;
sdeCents: Cents;
productRevenueCents: Cents;
};
export type ManagementLoad = {
operatingHoursMonth: number;
operatingHoursWeek: number;
fteBps: Bps;
managersRequired: number;
annualSalaryCents: Cents;
annualCostCents: Cents;
costToSdeBps: Bps;
costToProductRevenueBps: Bps;
};
export type AuthorityCategory =
| "purchase"
| "delivery"
| "pricing"
| "hiring"
| "legal"
| "asset";
export type AuthorityTier = "auto" | "manager" | "founder" | "reserved";
export type AuthorityLimits = {
autoApproveCents: Cents;
managerApproveCents: Cents;
founderApproveCents: Cents;
};
export type AuthorityRequest = {
label: string;
amountCents: Cents;
category: AuthorityCategory;
};
export type AuthorityDecision = { tier: AuthorityTier; reason: string };
export type AuthorityReview = {
totalRequests: number;
autoCount: number;
managerCount: number;
founderCount: number;
reservedCount: number;
founderMinutes: number;
founderHours: number;
autoExposureCents: Cents;
};
const FOUNDER_ONLY: AuthorityCategory[] = ["pricing", "legal", "asset"];
function amountError(value: Cents, label: string): string | null {
return Number.isInteger(value) && value >= 0
? null
: `${label} must be a non-negative integer amount in cents`;
}
function bpsError(value: Bps, label: string): string | null {
return Number.isInteger(value) && value >= 0 && value <= 10000
? null
: `${label} must be between 0 and 10000 bps`;
}
/**
* Load starts from the work that reaches the founder today. Support hours,
* consulting coordination and admin are added first; the manager count is the
* ceiling of that load divided by one manager's productive hours. The minimum
* headcount is explicit because two half-roles still cost two salaries.
*/
export function managementLoad(input: ManagementInput): Result<ManagementLoad> {
const counts = [
input.productCustomers,
input.supportHoursPerCustomerMonth,
input.consultingHoursMonth,
input.coordinationHoursPerConsultingHour,
input.adminHoursMonth,
];
if (!counts.every((value) => Number.isFinite(value) && value >= 0)) {
return fail("workload counts and hours must be non-negative numbers");
}
if (
!Number.isFinite(input.productiveHoursPerManagerMonth) ||
input.productiveHoursPerManagerMonth <= 0
) {
return fail("productive hours per manager must be positive");
}
if (!Number.isInteger(input.minimumManagers) || input.minimumManagers < 0) {
return fail("minimum managers must be a non-negative integer");
}
for (const [value, label] of [
[input.managerSalaryCents, "manager salary"],
[input.sdeCents, "SDE"],
[input.productRevenueCents, "product revenue"],
] as Array<[Cents, string]>) {
const error = amountError(value, label);
if (error) return fail(error);
}
if (input.sdeCents <= 0) return fail("SDE must be positive");
const burdenError = bpsError(input.employerBurdenBps, "employer burden");
if (burdenError) return fail(burdenError);
const operatingHoursMonth =
input.productCustomers * input.supportHoursPerCustomerMonth +
input.consultingHoursMonth * input.coordinationHoursPerConsultingHour +
input.adminHoursMonth;
const managersRequired = Math.max(
input.minimumManagers,
Math.ceil(operatingHoursMonth / input.productiveHoursPerManagerMonth),
);
const annualSalaryCents = input.managerSalaryCents * managersRequired;
const annualCostCents = Math.round(
(annualSalaryCents * (10000 + input.employerBurdenBps)) / 10000,
);
return ok({
operatingHoursMonth,
operatingHoursWeek: (operatingHoursMonth * 12) / 52,
fteBps: divide(operatingHoursMonth, input.productiveHoursPerManagerMonth),
managersRequired,
annualSalaryCents,
annualCostCents,
costToSdeBps: divide(annualCostCents, input.sdeCents),
costToProductRevenueBps: divide(annualCostCents, input.productRevenueCents),
});
}
/**
* Delegation is a ladder, not a switch. The first rung approves small repeats
* without a meeting; the last rung is above the founder's own authority and
* must go to the board or the shareholders. Pricing, legal and asset decisions
* stay with the founder even when the amount is small.
*/
export function authorityDecision(
request: AuthorityRequest,
limits: AuthorityLimits,
): Result<AuthorityDecision> {
const requestError = amountError(request.amountCents, "request amount");
if (requestError) return fail(requestError);
for (const [value, label] of [
[limits.autoApproveCents, "auto approval limit"],
[limits.managerApproveCents, "manager approval limit"],
[limits.founderApproveCents, "founder approval limit"],
] as Array<[Cents, string]>) {
const error = amountError(value, label);
if (error) return fail(error);
}
if (
limits.autoApproveCents > limits.managerApproveCents ||
limits.managerApproveCents > limits.founderApproveCents
) {
return fail("approval limits must increase from auto to manager to founder");
}
if (request.amountCents > limits.founderApproveCents) {
return ok({
tier: "reserved",
reason: "above the founder limit; requires board or shareholder approval",
});
}
if (FOUNDER_ONLY.includes(request.category)) {
return ok({
tier: "founder",
reason: `${request.category} decisions stay with the founder`,
});
}
if (request.amountCents <= limits.autoApproveCents) {
return ok({ tier: "auto", reason: "within the auto-approval limit" });
}
if (request.amountCents <= limits.managerApproveCents) {
return ok({ tier: "manager", reason: "within the manager approval limit" });
}
return ok({ tier: "founder", reason: "above the manager limit" });
}
/**
* Review load is the price of the thresholds. A low auto limit pushes routine
* requests to the founder; a high one leaves more spending outside review.
* Both founder minutes and auto-approved exposure are returned.
*/
export function authorityReview(
requests: AuthorityRequest[],
limits: AuthorityLimits,
minutesPerFounderDecision: number,
): Result<AuthorityReview> {
if (requests.length === 0) return fail("at least one request is required");
if (
!Number.isFinite(minutesPerFounderDecision) ||
minutesPerFounderDecision < 0
) {
return fail("minutes per founder decision must be non-negative");
}
let autoCount = 0;
let managerCount = 0;
let founderCount = 0;
let reservedCount = 0;
let autoExposureCents = 0;
for (const request of requests) {
const decision = authorityDecision(request, limits);
if (!decision.ok) return decision;
if (decision.value.tier === "auto") {
autoCount += 1;
autoExposureCents += request.amountCents;
} else if (decision.value.tier === "manager") {
managerCount += 1;
} else if (decision.value.tier === "founder") {
founderCount += 1;
} else {
reservedCount += 1;
}
}
const founderMinutes = founderCount * minutesPerFounderDecision;
return ok({
totalRequests: requests.length,
autoCount,
managerCount,
founderCount,
reservedCount,
founderMinutes,
founderHours: founderMinutes / 60,
autoExposureCents,
});
}
代码有四个刻意的选择。第一,managementLoad 的工作量从「今天谁在做」出发,不从组织架构出发;它把产品支持、咨询协调和行政分开加总,避免把某一块漏掉。第二,管理者人数用 Math.ceil,56.7% 的负荷也要占一个完整人头;minimumManagers 允许公司为了备份而多配一个人。第三,authorityDecision 先检查金额是否超过创始人上限,再检查事项是否属于定价、法律、资产;金额和事项是两条独立的边界。第四,authorityReview 同时返回创始人分钟数和自动批准金额,前者衡量授权不足,后者衡量授权过度。
把 Nord 代入:90 家产品客户、每家每月 0.35 小时支持;110 小时咨询、每小时 0.15 小时协调;行政 20 小时;管理者产能 120 小时/月;年薪 5,500,000 美分、雇佣负担 2,000 基点;SDE 3,432,000 美分;产品收入 4,212,000 美分。返回月度工作量 68 小时、FTE 5,667 基点、1 名管理者、年度成本 6,600,000 美分,占 SDE 19,231 基点、占产品收入 15,670 基点。数字与上表一致。
小结
- 创始人退出日常经营,先算工作量:Nord 的 90 家产品客户、110 小时咨询和行政合计 68 小时/月,折 15.7 小时/周。
- 按 120 小时/月的有效产能,需要 1 名管理者;按 60 小时/月,需要 2 名;管理者年薪 55,000 美元、雇佣负担 20%,1 人成本 66,000 美元。
- 1 名管理者的成本是 SDE 的 192.3%、产品收入的 156.7%;2 名管理者是 SDE 的 384.6%;新增收入 75,000 美元才能覆盖工资与税,对应 882 小时咨询/年或 161 家产品客户。
- 授权要同时写金额和事项:自动 ≤$500、管理者 $500–$5,000、创始人 $5,000–$20,000、保留 >$20,000;定价、法律、资产无论金额大小都留在创始人手里。
- 授权不足把创始人时间从 1.7 小时/季度推到 6.0 小时/季度;授权过度把 29,300 美元/季度放到自动批准,占季度收入的 76.0%。
- 汇报节奏合计 126 小时/年、$10,710;加上管理者成本,全成本 76,710 美元,占 SDE 的 223.5%。
- KPI 必须和卷一口径一致;汇报要写清谁准备、谁参会、谁决策,否则授权会退回创始人。
阅读导航:上一节:12.1 持有型公司的治理 · 下一节:12.3 家族、合伙与继承 。
常见错误与边界
- 按感觉招管理者。 先算工作量:90 家客户、110 小时咨询、行政合计 68 小时/月;不算工作量,招人只会增加协调成本。
- 把管理者成本当成纯费用。 66,000 美元替换的是创始人 68 小时/月;按 85 美元/小时算,机会成本 69,360 美元,刚好覆盖。
- 忽略雇佣负担。 55,000 美元年薪加 20% 负担是 66,000 美元;只按年薪做预算,现金会差 11,000 美元。
- 只写金额,不写事项。 定价、法律、资产三类事项无论金额大小都要收回;只看金额会把 0 美元的定价调整自动放行。
- 授权不足。 阈值定得太低,18 笔请求推到创始人,时间从 1.7 小时/季度涨到 6.0 小时/季度,一年增加 17.2 小时。
- 授权过度。 自动阈值定到 5,000 美元,45 笔自动放行、29,300 美元/季度无人复核,相当于季度收入的 76.0%。
- 汇报太密。 每天站会加每周复盘,管理者变成执行者;四层节奏合计 126 小时/年已经足够。
- 汇报太疏。 只在季度会看结果,定价错误和超范围承诺会在两次会议之间累积;重大事项要 5 个工作日内通知。
- KPI 另起一套。 管理报表的 MRR、流失、SDE 必须和卷一、月报用同一套定义,否则数字越多,判断越乱。
- 授权矩阵不更新。 客户从 90 家到 150 家、咨询从 110 小时到 180 小时,阈值和工作量都要重算;一年审一次,规模变化超过 20% 时临时审。
边界:本节只处理职业化管理的工作量、成本、授权与汇报节奏,不构成法律、税务或投资建议。管理者的劳动合同、授权书、竞业与保密条款需要当地执业律师起草;KPI 的具体口径要和公司自己的财务与合同系统对齐。代码只算工时、成本和审批层级,不判断某个管理者是否胜任,也不替代实际经营判断。
继续阅读
探索更多技术文章
浏览归档,发现更多关于系统设计、工具链和工程实践的内容。