新晋工程经理与表现不佳员工首次1on1模板
一句话总结
首次1on1的核心不是为了指出错误，而是为了诊断表现背后的系统性因素，并在此基础上共同制定可测量的改进路径。正确的做法是先倾听员工的工作情境和资源限制，再用具体数据点明确期望差距，最后把改进目标分解为可观察的行为里程碑。只有把对话变成双向问题解决而非单向指责，才能真正提升团队绩效和员工敬业度。
适合谁看
这篇指南适合刚刚升任或刚刚接手新团队的工程经理，尤其是那些在第一次面对表现不均的成员时感到不知如何切入的人。如果你之前主要做个人贡献者，现在需要从“解决技术问题”转向“诊断人与过程的匹配度”，这篇文章能提供可操作的框架。
同时，正在准备内部晋升或外部面试的高级工程师也能从中学习如何在1on1中展现领导力而不失技术可信度。最后，HR业务伙伴和技术教练可以把这里的模板作为辅导新经理的参考素材。
第一次1on1的目标是什么？
第一次1on1的目的不是当场给出绩效评级或制定惩戒计划，而是先建立信任基线，再把模糊的“表现不好”转化为可观察的具体行为差距。在硅谷的工程团队里，经常看到经理因为缺乏具体例子而陷入“你总是拖延”的泛谈，导致员工产生防御心理，反而掩盖了真实阻碍。正确的做法是先花10‑15分钟了解员工最近两周的工作流程：他们使用的任务追踪工具、参加的例会频率、收到的需求变更情况。
例如，一位后端工程师在debrief会上提到，他每天要处理三次临时的数据库schema变更，这导致原定的feature开发被迫中断。通过这种具体情境的还原，经理能够判断是任务分配不均、需求不明确还是个人技术短板导致的低效。只有把问题定位在“流程或资源”上，才能避免把个人能力简单等同于表现不佳，进而为后续的改进计划奠定事实基础。
> 📖 延伸阅读：ServiceNowPM晋升时间线和评审标准深度解读2026
如何收集客观数据而非主观印象？
客观数据的收集要围绕三个维度：产出量、质量指标和过程合规性。产出量可以看Jira中已关闭的故事点数、每周提交的PR数量或平均周期时间；质量指标包括代码审查中被要求修改的次数、生产环境的缺陷率以及监控告警的频率；过程合规性则考察是否参加每日站会、是否及时更新文档、是否遵循分支策略。在一次真实的hiring committee讨论中，面试官曾指出一位候选人在系统设计环节只给出了高层方案，却无法说明具体的读写延迟测试方案，这实际上是过程合规性缺失的表现。
同样的原则也适用于在职员工：经理可以拉取过去六个月的代码审查记录，统计被要求重做的PR比例；如果这个比例超过30%，就有充分理由怀疑是代码质量或审查流程的问题，而不是单纯的“马虎”。此外，还可以匿名调度团队成员对该员工的协作满意度，用Likert量表得到一个可比较的数值。只有把这些指标摆在桌面上，才能避免“你总是不靠谱”这种无法证实的指责，把对话聚焦在可以改进的具体行为上。
怎样设定可测量的改进里程碑？
改进里程碑必须遵循SMART原则：具体（Specific）、可测量（Measurable）、可达成（Achievable）、相关（Relevant）、时限（Time-bound）。以之前提到的后端工程师为例，如果问题在于频繁的临时schema变更导致开发中断，那么一个合适的里程碑是：“在未来四周内，将临时schema变更的平均频率从每周三次降低到每周一次，并在每次变更后更新对应的数据库迁移文档，文档更新及时率达到100%。”这里的具体行为是“更新迁移文档”，可测量的指标是“频率降幅”和“及时率”，四周的时限提供了检查点。另一个常见场景是代码审查延迟：目标可以设定为“未来两周内，所有PR的审查响应时间从平均48小时缩短到24小时内，且逾期审查的比例不超过10%。
”这样的目标不仅明确了期望，还给出了检验的方法——经理可以在Jira中拉取PR的创建时间和第一次审查时间的差值。在每周的1on1中，经理和员工一起回顾这些数字，如果进展滞后，则一起分析阻碍（比如需求不明确导致频繁返工），而不是简单地说“你还没做好”。通过这种数据驱动的里程碑设定，绩效改进变得可视化、可追溯，也更容易获得团队其他成员的支持。
> 📖 延伸阅读：ToastPM晋升时间线和评审标准深度解读2026
如何在对话中保持心理安全与直接性？
心理安全不是指回避冲突，而是让员工感到即使承认不足也不会因此受到惩罚或边缘化。直接性则是指不绕弯子、明确指出期望与现状的差距。在一次实际的debrief会上，经理曾这样开场：“我注意到最近三个Sprint中，你的任务完成率只有60%，而团队平均是85%。我想先了解你看到的阻碍是什么，这样我们才能找到解决办法。”这句话同时做到了两件事：先给出具体数据点（完成率60% vs 85%），再把话题转向员工的视角，避免了“你总是拖后腿”的指责。
随后，员工提到他经常被拉去参加临时的安全审查会议，这占用了他原本的编码时间。经理接着用“如果我们能把这些会议的频率从每周两次降到每周一次，并把会议纪要同步到共享文档，你看是否能把可用编码时间提升到之前的水准？”这种表述既没有掩盖问题，又给出了可行的调整方案，让员工感到被尊重且有参与决策的空间。相反，错误的做法是直接说“你在这段时间里太不专业了，需要立刻改进”，这会触发防御机制，员工往往会把注意力放在如何自我辩解上，而不会真正思考改进路径。因此，保持心理安全与直接性的关键在于：先陈述事实，再邀请员工解释背景，最后共同探讨可行的调整方案。
后续跟进的节奏和工具是什么？
后续跟进的节奏应该是短频次、高透明度的循环，以确保里程碑不会被遗忘。推荐的节奏是：每周一次15‑20分钟的快速检查（可以立刻在站会后进行），每两周一次30‑40分钟的深度复盘，以及每月一次的正式绩效对话。在快速检查中，经理只需确认两件事：员工是否完成了当周约定的具体行为（比如更新了迁移文档），以及是否遇到了新的阻碍。如果出现偏离，当场讨论调整方案，而不是等到两周后才发现偏差。在深度复盘中，可以拉出Jira的燃尽图、代码审查延迟报告以及文档更新率，让双方基于同一套数据看进度。
例如，一次深度复盘显示，虽然文档更新率已经达到90%，但临时schema变更的频率仍然是每周两次，这时候经理和员工一起审查变更的来源，发现是某个产品经理在需求评审阶段经常临时改动数据模型，于是决定在产品需求评审 checklist 中加入“数据影响评估”这一项。每月的正式对话则可以把这些改进点与更大的职业发展目标挂钩，比如“如果你能在接下来的两个月里把审查响应时间稳定在24小时内，我们可以考虑让你主导下一个跨团队的平台项目。”工具方面，除了Jira和Confluence之外，还可以使用简单的共享Google Sheet来记录每周的里程碑完成情况，颜色标记绿黄红让进度一目了然。关键是让跟进机制轻量且可见，避免因为过程繁琐而导致执行变形。
准备清单
- 收集最近四到六周的客观数据：Jira故事点完成率、PR平均审查时间、代码缺陷率、文档更新率。
- 整理具体发生的事件或会议记录，比如debrief会议中提到的临时需求变更、安全审查会议频率或跨团队依赖会议。
- 明确员工目前的角色期望（比如L5后端工程师需要每周完成8个故事点、代码审查延迟<24小时、文档及时率100%），并和职级矩阵对照。
- 预先准备好两到三个可测量的里程碑草案，确保它们符合SMART原则并能在两到四周内观察到变化。
- 设定跟进节奏表：每周快速检查（15分钟）、每两周深度复盘（30分钟）、每月正式对话（45分钟），并在日历上预留时间。
- 练习开场白：先说出具体数据点，再邀请员工解释背景，最后共同探讨调整方案，避免直接指责或模糊表述。
- 阅读PM面试手册中的“系统性拆解面试结构”章节（手册里有完整的行为面试实战复盘可以参考），把类似的结构化思维应用到1on1的准备中，确保不遗漏关键信息点。
- 准备好笔记本或电子文档，用来记录员工的陈述、达成一致的里程碑以及后续的行动项，以便在下次复盘时对照。
常见错误
错误一：用泛泛的印象代替具体数据。
BAD：经理说：“你最近总是把事情拖到最后一刻，团队都在等你。”
GOOD：经理说：“根据Jira的数据，过去三个Sprint你平均只完成了5个故事点，而团队L5的基准是8个。我想了解你看到的哪些因素导致了这个差距。”
错误二：在对话中混合评价和指令，让员工无法分辨重点。
BAD：经理说：“你的代码质量不够好，而且你还经常迟到站会，这两个问题都要尽快改。”
GOOD：经理先分开谈代码质量：“上个月你的PR被要求修改的平均次数是2.4次，团队平均是1.2次。我们可以一起看看哪些地方容易出错。”随后再谈参与度：“站会迟到的次数在过去四周是三次，团队平均是0.5次。你觉得是什么原因导致你经常错过开始时间？”
错误三：后续没有明确的检查点，导致里程碑变成虚设。
BAD：经理说：“你下次要尽量提高效率，我会在月底再看看情况。”
GOOD：经理和员工一起写下：“未来两周内，PR审查响应时间从平均36小时缩短到24小时内，逾期审查比例不超过10%。我们将在每周二的快速检查中更新这一数字，并在两周后的深度复盘中评估是否达到目标。”
FAQ
问：如果员工在第一次1on1时表现得很防御，甚至否认问题存在，我该如何推进对话？
答：防御往往源于员工感到被评判而不是被帮助。此时不要继续堆砌数据，而是先暂停对话，询问员工对最近工作的感受。例如，可以说：“我注意到你对刚才提到的完成率数据有些惊讶，我想先了解你在这段时间里觉得最有成就感的是什么工作，或者哪些让你觉得特别吃力。”通过先确认员工的正面体验或痛点，再把话题拉回到数据上，可以降低威胁感。一位曾在华为内部担任技术领导的经理分享过一个案例：一位后端工程师在被告知代码审查延迟高时立刻反驳说“我每天都在加班，怎么可能是效率问题”。
经理于是把话题转向：“你最近在加班的那些任务里，哪些是因为需求变更导致的返工？我们可以一起看看这些变更的来源。”员工于是提到产品经常在评审后临时加字段，这才把问题定位在需求流程上，而不是个人努力不足。关键是把防御转化为共同解决问题的线索，而不是把它看作需要被克服的障碍。
问：我应该在1on1里给出多少具体的改进建议？太多会不会让员工觉得被微管理？
答：建议的数量应以“能在两周内可观察到变化”为准则，通常一到两个最关键的行为改动就足够了。超过三个会让员工难以聚焦，也容易被视为微管理。例如，针对代码审查延迟问题，经理可以只提出两个行动项：一是把PR的描述模板补充好，确保审查者能在五分钟内理解目的；二是设置个人的日程提醒，在PR提交后的两个小时内主动发起审查请求。
其余的细节（比如如何写好描述、提醒用什么工具）可以在后续的快速检查中根据员工的反馈再做微调。一次在某SaaS公司的内部复盘中，经理曾试图一次性给出五项改进措施（包括提交频率、分支策略、单元测试覆盖率、文档更新和跨团队同步），结果员工在两周后只完成了一项，其余因为缺乏优先级而被搁置。反而在另一次只聚焦“PR提交后两小时内发起审查请求”和“每天上午十点检查一次未审PR列表”的两项上，团队的平均审查时间从36小时下降到了22小时，员工也觉得目标明确且可达成。
问：如果在跟进过程中发现员工确实没有达到里程碑，我该如何避免让谈话变成责备循环？
答：此时的目标不是判断对错，而是诊断为什么偏离发生。先把数据摆出来，再问员工他们在执行过程中遇到了什么具体阻碍。例如，如果PR审查响应时间仍然是36小时，可以说：“我们上次约定的是两小时内发起审请，实际数据显示平均是36小时。我想了解在这段时间里，你是否经常被其他临时任务打断，或者是否对审查的优先级有不确定？”通过这种方式，你把焦点放在“过程阻碍”上，而不是“个人懒惰”。
在一次真实的debrief会中，一位经理发现一位后端工程师的文档更新率始终低于目标，于是问：“你在更新文档时是否需要查找很多旧的设计决策，还是因为模板本身不够清晰导致你不确定该写什么？”员工回答模板太泛，导致他每次都要花时间思考该写哪些细节。经理于是和团队一起修改了文档模板，加入了检查清单，随后更新率在两周内从65%升到了90%。这说明，当员工未达标时，正确的做法是把对话变成一次过程改进的调研，而不是一次惩戒宣告。这样不仅能保持关系，还能持续提升团队的整体效率。
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。