Back to Details

managing-urgency

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Managing Urgency

紧急情况管理

Before Starting

开始之前

Check for EM context first. If 
.agents/em-context.md
exists, read it.
If 
.agents/em-context.md
does not exist, ask for a minimal manager profile first and save it before giving detailed advice: role/title, team size, team mission or ownership area, and current challenge or priority.
If a specific person is central to the conversation and 
.agents/reports/[name].md
does not exist, ask for a minimal profile for that person first and save it before giving detailed advice: title/level, tenure, strengths, and current challenge or growth area.

If the conversation reveals durable new context later, update 
.agents/em-context.md
or 
.agents/reports/[name].md
automatically. Save stable facts and patterns, not guesses, transient frustration, or unresolved interpretations.

首先检查EM相关背景。如果存在
.agents/em-context.md
文件，请阅读它。
如果
.agents/em-context.md
不存在，请先询问并保存一份基础的经理资料，之后再提供详细建议：职位/头衔、团队规模、团队使命或负责领域，以及当前面临的挑战或优先级。
如果对话核心涉及特定人员且
.agents/reports/[name].md
不存在，请先询问并保存该人员的基础资料，之后再提供详细建议：职位/级别、任职时长、优势，以及当前面临的挑战或成长领域。

如果后续对话揭示了持久的新背景信息，请自动更新
.agents/em-context.md
或
.agents/reports/[name].md
。仅保存稳定的事实和模式，不要保存猜测、暂时的挫败感或未解决的解读。

Response Style

回应风格

Keep the first answer concise and useful. Do not dump the whole framework unless the user asks for depth.
Default to:
  • State the likely diagnosis or recommendation first
  • Ask at most 2-3 targeted questions only if the missing context changes the advice
  • Give the next concrete action and, when useful, exact wording the manager can use
  • Mention the relevant framework briefly, but do not explain every part of it
  • Offer a deeper version only after the direct answer
首次回答要简洁实用。除非用户要求深入讲解，否则不要全盘输出整个框架。
默认遵循以下原则：
  • 先说明可能的判断或建议
  • 仅当缺失的背景信息会影响建议时，最多提出2-3个针对性问题
  • 给出下一个具体行动，必要时提供经理可直接使用的准确措辞
  • 简要提及相关框架，但无需解释每个部分
  • 仅在直接回答后再提供深度版本

How to Use This Skill

如何使用此Skill

  • Just received an unreasonable deadline — need to decide how to respond → When You're Handed an Unreasonable Deadline (start here)
  • Want to use deadlines proactively to drive focus → Using Deadlines as a Tool
  • Deadline is set — want to avoid common pitfalls in execution → 5 Mistakes to Avoid
  • 刚接到不合理的截止日期——需要决定如何回应 → 当你接到不合理的截止日期时（从此处开始）
  • 想要主动利用截止日期来提升专注力 → 将截止日期作为工具使用
  • 已设定截止日期——想要避免执行中的常见陷阱 → 需避免的5个错误

Default Response Shape

默认回应结构

When helping with urgency, make tradeoffs explicit:
  1. Deadline type: real, fake, useful constraint, or panic.
  2. Five-question check: goal, scope, quality, staffing, and intensity.
  3. Options: reduce scope, add capacity, accept risk, move date, or stop other work.
  4. Recommendation: the least-bad path and why.
  5. Stakeholder script: how to communicate the tradeoff without sounding defensive.
Never answer urgent requests with only "push back." Give a concrete tradeoff menu.
在处理紧急情况时，要明确说明权衡取舍：
  1. 截止日期类型：真实的、虚假的、有用的约束，或恐慌性的。
  2. 五问题检查：目标、范围、质量、人员配置和工作强度。
  3. 可选方案：缩减范围、增加人力、接受风险、推迟日期，或暂停其他工作。
  4. 建议：相对最优的方案及其原因。
  5. 利益相关者沟通脚本：如何在不显得防御性的前提下沟通权衡取舍。
永远不要只用“拒绝”来回应紧急请求。要给出具体的权衡选项。

When You're Handed an Unreasonable Deadline

当你接到不合理的截止日期时

Before committing the team, work through five questions:
1. Is the deadline actually necessary?
Speed has a cost: technical debt, poor decisions, and burnout. Each engineering team has an optimal sustainable pace — pushing significantly beyond it reaches the first milestone faster but degrades everything that follows.
Pressure-test the deadline. Who set it and on what basis? Does it reflect an external constraint (contract, launch, regulatory date) or an internal wish? Does everyone involved understand the quality trade-offs? If the deadline is genuinely necessary, communicate exactly why — teams will go further when they know what they're fighting for.
2. Who should work on it?
More people is not always faster. Above a small number, coordination costs overtake the benefit of additional capacity — especially on tightly coupled work. Identify the minimum effective team size. It's often acceptable to split the team for a short sprint, keeping critical ongoing work alive elsewhere, rather than pulling everyone into one crisis.
3. How hard should you ask people to work?
People have lives. The bar for asking for extra effort should be high — and when you ask, you need to mean it. Guidelines that tend to hold:
  • Weekend work: only when the company's success genuinely depends on it, and compensate with time off after
  • People differ in capacity and willingness — don't assume uniformity
  • If your business has predictable crunch periods (launches, seasonal peaks), set those expectations during onboarding, not mid-crisis
When you do ask for extraordinary effort, bring in a senior leader to acknowledge it directly — it answers questions and signals that the effort is seen.
4. Are you on the right path?
Normal delivery tolerates course corrections over time. Urgent delivery doesn't — a small wrong turn compounds fast. Your most critical job during a crunch is ensuring the team is working on the right thing in the right way.
Run short feedback loops. Involve PM and design immediately. Ask daily: what can be cut? What can be simplified? What already exists that we can reuse? Early in the sprint, even temporary micromanagement on key decisions is justified — every early choice locks in or unlocks downstream time.
5. What does the return to normal look like?
After a successful crunch, leadership may assume the team can always work that way. It cannot. Sustained crisis mode drives attrition and degrades quality. Your job after the crunch is to be explicit: "We delivered this under exceptional circumstances — this isn't the baseline." Set that expectation before the next deadline appears.
在让团队投入工作前，先梳理以下五个问题：
1. 这个截止日期真的有必要吗？
追求速度是有代价的：技术债务、错误决策和员工倦怠。每个工程团队都有最优的可持续工作节奏——大幅超出这个节奏会更快到达第一个里程碑，但会损害后续所有工作。
对截止日期进行压力测试。是谁设定的？依据是什么？它反映的是外部约束（合同、发布、监管日期）还是内部愿望？所有相关人员是否都理解质量上的权衡？如果截止日期确实必要，要明确说明原因——当团队知道他们为何而战时，会更愿意全力以赴。
2. 应该安排谁来做这项工作？
人多并不总是更快。当人数超过一小部分时，协调成本会超过额外人力带来的收益——尤其是在紧密关联的工作中。确定最小有效团队规模。通常可以在短周期内拆分团队，让其他地方的关键持续工作得以推进，而不是让所有人都陷入同一场危机。
3. 你应该要求团队付出多大的努力？
员工有自己的生活。要求额外努力的门槛应该很高——而且当你提出要求时，必须是认真的。通常遵循以下准则：
  • 周末加班：仅当公司的成功真正依赖于此，并且事后给予调休补偿
  • 每个人的能力和意愿不同——不要假设所有人都一样
  • 如果你的业务有可预测的紧张时期（发布、季节性高峰），要在入职时就设定这些预期，而不是在危机中期才提出
当你确实要求员工付出超常努力时，请让资深领导直接认可他们的付出——这能解答疑问，并表明他们的努力被看到了。
4. 你们走在正确的道路上吗？
常规交付允许随时间进行路线修正。但紧急交付不行——一个小的错误转向会迅速加剧。在紧张时期，你最关键的工作是确保团队在以正确的方式做正确的事情。
运行短反馈循环。立即让产品经理（PM）和设计人员参与进来。每天询问：哪些可以削减？哪些可以简化？有哪些已存在的内容可以复用？在周期初期，即使对关键决策进行临时的微观管理也是合理的——每个早期选择都会锁定或解锁后续的时间。
5. 回归常态是什么样子？
在成功度过紧张时期后，领导层可能会认为团队总能保持这种工作节奏。但实际上不能。持续的危机模式会导致人员流失并降低质量。紧张时期过后，你的工作要明确说明：“我们是在特殊情况下完成这项工作的——这不是常态。”要在下一个截止日期出现前就设定好这个预期。

Using Deadlines as a Tool

将截止日期作为工具使用

Parkinson's Law: work expands to fill the time available. Projects without deadlines take longer than they need to and accumulate scope. This isn't a flaw in people — it's a structural property of open-ended time.
The practical implication: a challenging deadline in a healthy environment drives focus and creativity. The same deadline in a toxic environment drives shortcuts and fear. The tool is neutral — the environment determines the outcome.
A simple test: send a survey with no deadline vs. the same survey due tomorrow. Response rate and speed differ dramatically. Apply this principle broadly — to internal reviews, design sign-offs, decision cycles.
The critical distinction between a challenging deadline and an impossible one: a challenging deadline requires prioritization and focus. An impossible deadline requires cutting corners on things that matter, burning people out, or both. Your judgment on which category a deadline falls into is one of the most consequential calls you make as EM.
Parkinson's Law：**工作会自动膨胀，填满可用的时间。**没有截止日期的项目会比实际需要的时间更长，并且不断扩大范围。这不是人的缺陷——而是开放式时间的结构性特征。
实际意义：在健康的环境中，具有挑战性的截止日期能提升专注力和创造力。而在有毒的环境中，同样的截止日期会导致走捷径和恐惧。工具本身是中立的——环境决定结果。
一个简单的测试：发送一份没有截止日期的调查问卷，对比同样的调查问卷要求明天提交。回复率和速度会有显著差异。将这一原则广泛应用——适用于内部评审、设计确认、决策周期等。
具有挑战性的截止日期和不可能完成的截止日期之间的关键区别：具有挑战性的截止日期需要优先级排序和专注力。不可能完成的截止日期需要在重要事项上走捷径、让员工倦怠，或两者兼而有之。作为EM，判断截止日期属于哪一类是你做出的最具影响力的决策之一。

5 Mistakes to Avoid

需避免的5个错误

1. Not telling the team what happens after the deadline. Teams will work harder when they understand the consequence of hitting or missing the date. If the deadline is internal, say so — and explain what it enables. "Nothing external happens, but shipping this unlocks Q3 roadmap approval" is a real reason worth knowing.
2. Not involving the team in scoping. Deadlines work best when the team has had input on what's feasible. You don't need consensus — you need to have asked. An engineer who thinks "if anyone had asked me, I could have told them this wouldn't work" is disengaged before the sprint begins.
3. Pushing too hard to hit it. The point of a deadline is focus, not suffering. When unexpected obstacles appear — external blockers, underestimated complexity, a dependency that slips — a deadline should flex before it breaks the team. Missing a self-imposed deadline occasionally is better than working weekends to defend a date that no longer makes sense.
4. Not pushing hard enough. The opposite failure. Some managers avoid asking for more effort to protect goodwill — sometimes doing the extra work themselves rather than asking. That's not protection; it's avoidance. Finding the right level of push is the job.
5. Being rigid when the scope or date needs to change. External requests to adjust scope or timeline are not failures. They're new information. The right response is to communicate the trade-offs clearly and make a joint decision — not to defend the original plan as a matter of pride.
1. 不告诉团队截止日期之后的安排。 当团队了解到达成或错过截止日期的后果时，会更努力地工作。如果截止日期是内部设定的，要说明这一点——并解释它能带来什么。“没有外部影响，但交付这项工作能解锁第三季度的路线图审批”是一个值得让团队知道的真实原因。
2. 不让团队参与范围规划。 当团队参与过可行性讨论时，截止日期的效果最好。你不需要达成共识——但你需要询问过他们。如果工程师觉得“要是有人问过我，我早就告诉他们这行不通了”，那在周期开始前他们就已经失去积极性了。
3. 为了达成目标过度施压。 截止日期的意义在于专注，而不是让员工受苦。当出现意外障碍——外部阻碍、低估复杂度、依赖项延迟——时，应该先调整截止日期，而不是让团队崩溃。偶尔错过一个自行设定的截止日期，总好过为了维护一个不再合理的日期而让员工周末加班。
4. 施压不足。 这是相反的错误。有些经理为了维护良好关系而避免要求额外努力——有时甚至自己承担额外工作而不要求团队。这不是保护，而是逃避。找到合适的施压程度是你的工作。
5. 当范围或日期需要变更时过于僵化。 外部要求调整范围或时间线不是失败。这是新的信息。正确的回应是清晰地沟通权衡取舍，并共同做出决策——而不是出于自尊心去维护最初的计划。

Dive Deeper

深入了解

If the user asks where a framework came from, wants to read the original article, or wants more context on any topic in this skill — read 
references/sources.md
.
如果用户询问框架的来源、想要阅读原文，或想要了解此Skill中任何主题的更多背景信息——请阅读
references/sources.md
。

Related Skills

相关Skills

  • delegation
    — Chronic urgency is often a symptom of delegation failures upstream
  • working-with-pm
    — Most fake or misaligned urgency originates in the PM–EM relationship
  • roadmap-planning
    — Unreasonable deadlines are usually a planning and scoping problem at the source
  • delegation
    — 长期的紧急情况往往是上游授权失败的症状
  • working-with-pm
    — 大多数虚假或不一致的紧急情况源于PM与EM的关系
  • roadmap-planning
    — 不合理的截止日期通常根源在于规划和范围界定问题