Managing Urgency

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.

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

---

How to Use This 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

---

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.

---

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.

---