Tasks Are Promises, Not Requirements

The Language Matters#

There’s a subtle but profound difference between a requirement and a promise.

A requirement is something imposed on you: “You must do this.” The language creates external pressure and removes agency. If the requirement was wrong or impractical, that’s someone else’s problem.

A promise is something you commit to: “I will do this.” The language creates ownership and accountability. If the promise becomes impossible, you speak up and renegotiate.

From Requirements to Promises#

When a task is framed as a requirement, the conversation is one-way:

Manager: “We need this feature by Friday.” Developer: “Okay, I’ll try.” (Friday arrives, feature is incomplete) Manager: “Why isn’t this done?” Developer: “It was harder than expected.” Manager: “Well, it was required.”

The requirement was clear, but the developer didn’t deliver it. Blame flows downward.

When a task is framed as a promise, the conversation is a negotiation:

Manager: “We need this feature by Friday. Is that possible?” Developer: “Given the complexity, I can deliver it by Wednesday if I focus on it, or by Monday if I skip the tests.” Manager: “Can you get it done by Friday with tests?” Developer: “Yes, I promise.” (Friday arrives, feature is delivered)

The promise was clear, owned by the developer, and delivered. No blame needed.

Why Promises Work Better#

Accountability Without Blame#

Requirements create pressure. Promises create commitment. A developer who makes a promise has ownership in a way that someone following a requirement doesn’t.

When circumstances change and a promise becomes risky, the developer speaks up. They know they own the outcome. There’s no hiding behind “the requirement wasn’t realistic.”

Better Estimates#

When you frame something as a requirement (“You must estimate this”), estimates are inflated or vague. Uncertainty gets hidden in padding.

When you frame it as a promise (“What do you promise you can deliver?”), developers estimate conservatively. They know they own the outcome. They include buffer only where needed.

Psychological Safety#

Requirements create fear. If you can’t meet the requirement, you failed. Promises create partnership. If conditions change and you need to renegotiate, that’s a conversation, not failure.

Teams with promise-based language have better psychological safety. Missing a promise is still a miss, but it’s treated as a learning opportunity, not a failure of the person who made it.

Last-Responsible-Moment Decisions#

When something is a requirement, you need to figure out all details upfront. You need estimates before you know what you’ll discover.

When something is a promise, you can defer details to the last responsible moment. You make the promise at the right grain of detail:

  • Monday: “I promise to investigate the integration and report back by Wednesday.”
  • Wednesday: Based on what you learned, “I promise to implement the integration by Friday.”

The promise evolves as understanding improves.

Framing Promises Correctly#

A promise needs to be:

Specific#

“I promise to implement the API endpoint that returns user data in JSON format, tested, by Friday.”

Not: “I promise to work on the API stuff.”

Specificity makes the promise testable. When Friday arrives, either you delivered the JSON endpoint or you didn’t.

Ownable#

“I promise to build the feature” is better owned by the developer than “We promise to deliver the feature.”

When it’s unclear who owns the promise, it gets lost. Explicit ownership creates accountability.

Honest#

A promise should be something you genuinely believe you can deliver. Sandbagging estimates by over-promising creates a culture of low trust. Over-promising to please stakeholders creates burnout.

Good promises stretch you slightly but are achievable with focus.

Renegotiable#

A promise isn’t a contract in stone. If circumstances change—you discover unexpected complexity or other work emerges—a mature team renegotiates.

“I promised to deliver by Friday, but I discovered this is more complex than expected. I can deliver a reduced version by Friday or the full version by Monday. Which do you prefer?”

This is better than either missing the promise or silently working nights to make it.

Team Culture and Promises#

Teams with promise-based language develop a different culture:

  • Trust: If someone makes a promise, you trust they’ll deliver. Delivers aren’t constantly questioned or checked
  • Transparency: When something becomes risky, people speak up early rather than hiding the problem
  • Learning: When someone can’t deliver a promise, the team asks “what did we learn?” rather than “who failed?”
  • Agency: Developers have a say in what they commit to rather than having requirements imposed

Anti-Patterns#

Coerced Promises#

A manager asking “Promise you can do this by Friday?” when it’s clearly not feasible is creating coerced promises. The developer feels pressure to promise despite knowing it’s impossible.

Promises need to be genuinely voluntary. If a date is immovable, that’s a constraint to work with, not a promise to make.

Promise Pile-Up#

Teams that promise everything and deliver nothing lose all credibility. Promises need to be limited by capacity.

Good promise-based teams have a capacity limit. When capacity is full, new promises are queued for future weeks.

Broken Promises Without Learning#

If promises are consistently broken and no one learns or adjusts, the promise becomes meaningless. Promises only work if broken promises trigger reflection.

Promises and Agile Sprints#

Agile sprints use promise-based language already: “What does the team commit to this sprint?” Sprint commitment is a promise.

The difference is extending this to daily work. Instead of all work being requirements assigned by managers, work is framed as commitments made by the team.

“The UI work is promised to be done by Wednesday. The API work is promised to be done by Friday. What else should we commit to?”

This shift in language from requirement to promise changes the dynamic significantly.

The Last Responsible Moment#

Promises enable deferring decisions to the last responsible moment. Instead of making all decisions upfront, you make them as late as possible when you have more information.

This works because promises are specific about what you’re committing to now, not what the full implementation will be:

  • “I promise to spike the API integration and bring a recommendation by tomorrow” (specific, short timeframe)
  • “Based on the spike, I promise to build the integration using approach X by Friday” (specific, informed by learning)

Conclusion#

Reframing tasks as promises rather than requirements seems like a small change in language. The impact is profound.

Teams with promise-based language have better accountability without blame, more honest estimates, and higher psychological safety. They make better decisions because they can defer details to the last responsible moment.

Start using the language of promises in your team:

  • “What do you promise to deliver this week?”
  • “Do you promise you can have this ready by Friday?”
  • “This promise is becoming risky. Should we renegotiate?”

You’ll notice the conversation becoming more collaborative and the outcomes becoming more reliable.

Promises create ownership. Requirements create compliance. Ownership is what drives quality.