本文面向种子轮、A 轮的产品/技术管理者，拆解早期工程团队最常见的管理反模式，重点是少花力气「管人」，把精力用在产品、用户和招聘上。
很多创始人都会经历类似的一天：
产品刚有一点起色，团队有 6、7 个工程师，大家各自忙着写代码。你刷了一圈飞书、钉钉、Jira，看到没人「熬夜上线」、「周末加班」，心里开始打鼓：
我是不是该「管一管」了？
要不要设周末站会？
要不要赶紧招个工程经理？
在早期，绝大多数你以为的「管理问题」，本质上都不是管理问题，而是产品和招聘问题。
对种子轮、A 轮阶段的产品/技术管理者来说，最值得警惕的，是那些听上去很「负责」、实际上却严重分散注意力的管理动作。
下面，我们把这些反模式拆开讲清楚。
一、问题：为什么你总觉得「需要管理」？
在早期工程团队里，创始人最常见的一种焦虑是：
- 工程师好像没那么「拼」，没人自发熬夜
- 项目进展不够「可见」，看不到随时可展示的进度条
- 组织结构还很扁平，感觉「不像一家真正的公司」
这时，很容易滑向一个直觉：
我需要更多的管理：更多会议、更多流程、更多角色。
但如果你还在找产品/市场匹配点（PMF），事情恰好相反：
- 你最需要的是把所有可用的精力，放到产品和用户身上
- 任何与此无关、但会占用创始人和工程师时间的管理创新，都是巨大的机会成本
所以，真正的问题不是「缺不缺管理」，而是：
在这个阶段，哪些「看上去像管理」、但其实只会拖慢团队的动作，应该被坚决避免？
二、误区：三种常见的管理反模式
误区一：试图靠「打鸡血」激励工程师
很多创始人一看到团队不够「燃」，就开始想办法「激励」工程师：
- 鼓励甚至默认 996 式的长时间工作文化
- 把原本可以异步的事情，塞进周末或晚上的会议
- 各种形式的微观管理：频繁要进度、要截图、要「证明你很努力」
问题在于，优秀的工程师，要么一开始就自带动力，要么很快会被这种文化劝退。
记住这个重要结论：
动力是招聘进来的，不是管理出来的。
当你花大量心思去「点燃」团队时，往往说明有两个地方出了问题：
- 招聘时，没有足够重视候选人的内在驱动力、韧性和好奇心
- 环境没有给这些本来就很自驱的人，足够的空间和意义感
可执行建议： 把「是否自驱」当作硬标准写进招聘评分表，而不是事后靠文化口号来补课。
误区二：过早引入管理者和头衔
另一个常见做法是：一到十几个人，就开始「像大公司一样」搭管理架构：
- 给团队划小组、设组长、甚至招全职工程经理
- 安排定期的一对一、绩效评估、晋升路径设计
- 为了「有条不紊」，大规模引入流程、里程碑、报表
听上去都很负责任，但在早期，这往往意味着：
- 你还在搞清楚到底该做什么产品，却已经请来一个「负责把事做对」的人
- 管理者不得不创造各种「管理工作」 —— 安排会议、管理 Jira、评估绩效，以证明自己有价值
- 很难判断问题出在产品、在工程师，还是在管理者身上
下面给出一个简单的分阶段视角：
- 5–6 人（含技术创始人）：阶段太早，不需要管理者。创始人主要做两件事：招人和（在极端情况下）开人，其余让团队自组织。
- 10–15 人、2–3 个子团队：所有工程师依然可以向一个人汇报（通常是 CTO），这是打磨工程文化的关键窗口期。
- 20–50 人：这时才是引入更多组织架构和管理层的阶段，此时团队规模扩大带来了混乱，开始真实限制产出。
可执行建议： 在 20 人之前，慎重对待任何「全职只做管理、不写代码」的角色设计。
误区三：照抄大厂的「先进管理实践」
还有一种更隐蔽的反模式，是把大厂的管理实践，当成早期团队的模板：
- 全套 Scrum 仪式：每日站会、迭代回顾、燃尽图
- 复杂的绩效体系、胜任力模型、晋升委员会
- 花哨的反馈机制、同行评审流程
问题不在于这些方法本身，而在于阶段错配：
大厂管理的是一台已经运转起来的机器；
你在早期时，还在造发动机。
早期团队的管理栈，应该像「Node + Postgres」—— 普通、稳妥、被无数人试过，不会成为公司失败的原因。
换句话说，在管理这件事上，越无聊越好。
可执行建议： 每当你想引入一个「很新」「很酷」的管理做法时，先问一句：如果不用，我们真的做不出产品吗？
三、方法：少做管理，多做这几件事
如果说上面三种是「别做」，那早期工程团队到底该「做什么」？有一个很实用的思路：
用「不情愿的管理者」心态，去做那一小撮真正必要的事。
1. 把精力放在「招对人」上
- 招聘时，刻意寻找那些有真正动力的人：主动加班、愿意为难题投入超预期精力，但不是被逼出来的
- 关注候选人经历里的「挫折时刻」 —— 遇到过什么困难？怎么扛过来的？
- 是否有持续的好奇心：愿意聊某个技术、某个兴趣时会「眼睛发光」
一旦招到这样的人，不需要做什么管理，更多的是别把他们的热情消耗在无意义的流程上。
2. 用最轻量的方式对齐方向
- 状态更新尽量异步完成：文字周报、短更新，而不是天天站会
- 对需求和优先级，用几篇共享文档就够了，没必要一上来就搭一整套系统
- 把「为什么做这件事」讲得非常清楚，比「怎么做、按什么节奏做」重要得多
当方向清晰、上下文透明时，优秀工程师自然会自己填补细节。
3. 保护工程师的注意力，而不是占用
- 钉钉、飞书是刚需，但要警惕演变成「注意力黑洞」
- 少 @ 全员、少搞临时化同步会议，多用异步文档和评论
- 鼓励大块、不被打断的深度工作时间，而不是随时在线的「响应速度」
真正的「高效」，往往体现在有多少时间被保护下来，而不是被填满。
4. 让一对一和反馈「有事可谈」
- 不做为了「保持关系」而开、却没有明确议题的例行 1:1
- 更鼓励基于具体问题、具体项目的临时对话
- 当有人真的有卡点、困惑或情绪时，再打开深入的沟通空间
这类关系，是在一起解决问题的过程中自然生长出来的，而不是靠日历上固定的时间段培养出来的。
可执行建议： 让「时间块」成为支撑深度工作的精简模块，而不是塞满整周日历的主角。
四、清单：给早期产品/技术管理者的对照表
如果你正在带一个 5–20 人的工程团队，可以用这份清单自查：
[ ] 最近一个月花在招人和面试上的时间，是否明显多于花在设计新管理流程上的时间？
[ ] 是否在试图用流程和制度，去「拯救」一个本就不合适的招聘决策？
[ ] 团队大部分状态更新，是否可以通过异步文档就能完成？
[ ] 团队会议是否都有清晰议程和产出，而不是为了「看起来在管理」？
[ ] 工程师是否能直接接触完整的业务上下文（用户反馈、营收数据、产品决策），而不是只拿到被筛选过的片段信息？
[ ] 你是否依然亲自参与关键的产品和技术决策，而不是过早把这些权力和判断交给「管理层」？
[ ] 当你觉得「需要更多管理」时，是否先问过自己：是不是该先多去几次用户访谈？
可执行建议： 每季度用这份清单做一次复盘，把那些「想不到不做也没关系」的管理动作，都列入精简候选。
五、总结：当你觉得需要「管理」，往往应该回到产品
在种子轮、A 轮阶段，如果你觉得自己有很严重的「工程管理问题」，九成的正确解法是暂时什么都不做，先去找用户、做产品、招对人。
早期工程团队最重要的管理决策，往往只有三件：
- 招谁进来 —— 是否真的自驱、好奇、愿意为问题多走一步
- 给他们怎样的环境 —— 信息是否透明、目标是否清晰、是否能安心做事
- 在什么时刻引入管理 —— 坚持「能用 Node + Postgres，就别造新数据库」式的朴素标准
如果说传统管理在乎的是「把机器调得更顺」，
那早期管理更像是：守住几条简单的边界，让真正重要的工作自己长出来。
当你下次忍不住想「多管一点」时，不妨先问自己：
我现在做的这件事，真的会让我们更快找到产品/市场匹配吗？
如果答案是否定的，那也许最好的管理动作，就是先按下暂停键。
Hi，我是俞凡，一名兼具技术深度与管理视野的技术管理者。曾就职于 Motorola，现任职于 Mavenir，多年带领技术团队，聚焦后端架构与云原生，持续关注 AI 等前沿方向，也关注人的成长，笃信持续学习的力量。在这里，我会分享技术实践与思考。欢迎关注公众号「DeepNoMind」，星标不迷路。也欢迎访问独立站 www.DeepNoMind.com，一起交流成长。
