/feedback-mastery

Expectation Alignment Guide

Frameworks for setting, communicating, and managing expectations with teammates, stakeholders, and leadership.

Why Expectations Misalign

Common causes of expectation misalignment in software teams:

The Expectation Alignment Framework

1. Define Success Explicitly

Never assume alignment. Make success criteria explicit:

2. Expose Assumptions

Before starting work, surface hidden assumptions:

Questions to ask:

• "What are you assuming about [timeline/resources/scope]?"
• "What would make this harder than expected?"
• "What's the worst case scenario?"
• "What dependencies are we assuming will be available?"
• "What's the definition of 'done' for this?"

3. Document and Share

Expectations that aren't written down don't exist:

• Put acceptance criteria in tickets
• Send follow-up emails after verbal agreements
• Update documentation when things change
• Share publicly (not just DMs)

4. Check Alignment Regularly

Don't wait until delivery to discover misalignment:

• Daily standups surface blockers early
• Mid-sprint check-ins catch scope creep
• Demo progress before "done" to validate direction
• Regular stakeholder updates prevent surprises

Scenario: Unrealistic Deadlines

Recognition Signs

• Timeline set without engineering input
• Estimates significantly lower than past similar work
• No buffer for unknowns
• Dependencies assumed to be risk-free
• "We just need to..." (minimizing language)

Response Framework

1. Acknowledge the goal:

"I understand hitting this date is important for [business reason]."

2. Present data:

"Based on similar past work, this typically takes [X]. Here's the breakdown..."

3. Offer options:

"We have a few paths:"

• "Hit the date by reducing scope to [core features]"
• "Deliver full scope by [realistic date]"
• "Add resources, but onboarding will take [time]"

4. Get explicit agreement:

"Which approach would you like? Can I document this so we're aligned?"

Sample Conversation

Stakeholder: "We need the new dashboard by end of month."

You: "I want to make sure we deliver something great. Let me share what I'm seeing: the full dashboard - charts, filters, export - typically takes 6-8 weeks. We have 4 weeks."

Stakeholder: "We really need it by end of month."

You: "I hear you. Here's what we could do: ship the core charts by end of month, then add filters and export in the following two weeks. That gets value to users faster. Would that work?"

Stakeholder: "What about just working faster?"

You: "I wish that worked, but rushing usually creates bugs that cost more time later. The scope-first approach gets you something solid you can show stakeholders. What matters most - the date or the full feature set?"

Scenario: Unclear Role Boundaries

Recognition Signs

• Tasks falling through cracks
• Duplicated work
• "I thought you were handling that"
• Confusion about who decides what
• Finger-pointing when things go wrong

Response Framework

1. Identify the gap:

"I've noticed some confusion about who owns [task/decision]. Can we clarify?"

2. Propose explicit ownership:

"My understanding is that [Person A] owns [X] and [Person B] owns [Y]. Does that match your understanding?"

3. Define handoff points:

"The handoff happens when [specific condition]. At that point, [Person B] takes over."

4. Document and share:

"Let me send a quick summary so everyone's aligned."

RACI for Common Confusion Points

Scenario: Scope Creep

Recognition Signs

• "Can we just add..."
• "One more thing..."
• Requirements changing mid-sprint
• Original estimate no longer realistic
• Features growing beyond initial spec

Response Framework

1. Acknowledge the request:

"That's a good idea. Let me think through the impact."

2. Quantify the change:

"Adding [feature] would take approximately [time]. That would push our delivery from [date] to [new date]."

3. Present trade-offs:

"We could add this by dropping [other feature] or extending the timeline. Which would you prefer?"

4. Get explicit approval:

"Before I add this to the scope, can you confirm [the trade-off]?"

The Scope Change Template

When scope changes are requested, respond with:

**Change Request:** [What's being asked]

**Impact:**
- Timeline: [Current] → [New]
- Resources: [Any changes]
- Risk: [New risks introduced]

**Options:**
1. Add scope, extend timeline to [date]
2. Add scope, drop [other feature]
3. Defer to next phase

**Recommendation:** [Your suggestion]

**Need decision by:** [Date]

Setting Expectations Proactively

At Project Start

• Define success criteria explicitly
• Surface assumptions and dependencies
• Establish communication cadence
• Agree on decision-making process
• Document in shared location

During Work

• Regular status updates (before asked)
• Early warning on blockers
• Proactive communication of changes
• Demo progress incrementally
• Update documentation as things change

At Delivery

• Confirm acceptance criteria met
• Document what was delivered vs planned
• Capture lessons learned
• Set expectations for next phase

Phrases for Expectation Conversations

Setting Expectations

• "Let me make sure we're aligned on..."
• "Here's what I'm committing to..."
• "My understanding is that success looks like..."
• "Just to be explicit about scope..."
• "The definition of 'done' for this is..."

Surfacing Misalignment

• "I want to flag a concern about..."
• "I think we might have different assumptions about..."
• "Can we clarify what we mean by...?"
• "I'm seeing a gap between [X] and [Y]..."
• "Before we go further, I want to make sure..."

Resetting Expectations

• "Based on what we're learning, we need to adjust..."
• "The original estimate didn't account for [X]..."
• "Here's what's realistic given [constraints]..."
• "I need to revise what I committed to because..."
• "Let me give you an updated picture..."

Getting Commitment

• "Can I confirm that we're agreeing to...?"
• "Let me send a summary so we're all aligned."
• "Is everyone okay with this plan?"
• "Before we proceed, I need explicit approval for..."
• "Can you confirm in writing?"

Expectation Alignment Checklist

Before Starting Work

• Success criteria are explicit and measurable
• Timeline includes buffer for unknowns
• Dependencies are identified and owners confirmed
• Assumptions are documented
• Communication plan is agreed
• Decision-making process is clear
• RACI or ownership is explicit

During Work

• Regular updates before being asked
• Blockers raised immediately
• Changes communicated proactively
• Progress demonstrated incrementally
• Documentation updated as things change

At Delivery

• Acceptance criteria reviewed before "done"
• Stakeholder sign-off obtained
• Gaps between planned and delivered documented
• Next steps and expectations clear

Related: Return to feedback-mastery skill for difficult conversation frameworks.