A manager agrees to take on a new project, then realizes the team cannot deliver it alongside existing work without more support. Expectation management means addressing that gap before execution: clarify the work, discuss constraints, and agree on a workable plan. section 11.4.1
An expectation is more than a deadline. It can specify inputs, outcomes, responsibilities, resources, ways of working, and support. Realistic expectations draw on data and past experience; unsupported ones invite confusion and frustration. Some expectations are explicit, while others—such as contributing proactively—may remain unspoken until people discuss them. section 11.0 section 11.3.1
Use a five-step cycle rather than treating the first agreement as final:
- Set expectations. Define the task, desired outcome, resources, support, and time limit. Check that the plan fits each person’s strengths and constraints. section 11.3.1
- Communicate them. Explain what is being done and why, check for shared understanding, and document important agreements. section 11.6
- Negotiate when needed. Surface conflicting estimates or priorities and agree on trade-offs instead of silently overcommitting. section 11.3 section 11.4.1
- Adapt when circumstances change. Revisit commitments and communicate the effect on plans or timelines. section 11.3 section 14.2.4
- Appreciate contributions and share constructive feedback. Use what happened to improve the next agreement. section 11.3
Watch for three common obstacles: ambiguous requests, difficulty saying no, and taking comments personally. People can interpret even simple instructions differently. Ask clarifying questions early, and use regular check-ins to raise problems before they become surprises. section 11.2 section 11.6 section 11.4.1
Negotiate with leadership
An engineering manager cannot absorb a new project without straining existing work. She uses the priority list to propose exchanging a lower-priority project, documents the agreement, identifies a risk, and arranges biweekly progress check-ins. Saying no becomes a discussion of priorities and support, not a refusal to help. section 11.4.1
Align peer teams
Two teams disagree about a feature timeline: frontend work is estimated at two weeks, backend changes at four, and the frontend depends on the backend. Their managers compare assumptions about complexity and resources, then prioritize API definitions and data modeling so work can proceed in parallel. section 11.4.2
Apply the same habit upward with leadership, across peer teams, and downward with team members. Think of a recent conflict caused by unclear expectations: what question, resource, or early warning would have changed the outcome? section 11.4 section 11.5
