Hand checking off items on a to-do list
Hand checking off items on a to-do list

"I've Got It" Is Not a Commitment

"I've Got It" Is Not a Commitment

Why accountability breaks before follow-through begins

A leadership meeting is wrapping up. One team raises a blocker: they promised a customer a date, and they cannot hold it until another function delivers a key input.

A capable, well-intentioned leader says, "I've got it."

Everyone nods. She means it.

Three weeks later, the team is still waiting.

The miss gets treated as an accountability failure. But she never broke a clear commitment. The team never created one.

"I've got it" expressed intent. It did not name the outcome, the date, what done meant, or who was blocked without it.

The failure did not happen three weeks later.

It happened in the meeting.

The team stopped at agreement

Weeks later, the same team sits down to define what should count as a commitment. The conversation is productive. People offer language. Heads begin to nod.

Then the CEO stops the room and asks a direct question:

Has the team committed to this standard, or does everyone simply agree with it?

That is the problem in one sentence. The team was trying to define commitment and still stopped at agreement.

Agreement is not a decision. People can follow the logic, support the idea, and leave without owning anything—or leave with different ideas of what "done" means.

A shared list cannot close that gap. It can only hold what the team puts into it. Give it agreement instead of commitment, and agreement is what ends up on the list.

Accountability usually starts as a clarity problem

Most accountability problems begin before anyone misses a date. The team has never agreed on:

  • What belongs on the shared commitment list, and what stays an individual task

  • What makes a commitment valid

  • What happens when the date or the outcome changes

Without that standard, intentions get logged as commitments. Activity gets confused with outcomes. People inherit items they never accepted. The completion rate slowly stops meaning anything.

Then the tool takes the blame. The tool is not the problem. The definitions underneath it are.

Task or commitment?

A task is work you manage inside your own system. A commitment is a specific outcome another person, team, or enterprise priority is counting on by a defined date.

The difference is not size, effort, or importance. It is dependency and enterprise consequence.

The steps to produce the result stay with the owner. The shared list holds only the outcome others are waiting on.

"Schedule the pricing meeting" is a task. "Deliver the approved pricing plan to the account teams by September 1" is a commitment.

One is yours to manage. The other affects someone else's ability to move.

Two tests, not one

Getting this right takes two decisions.

Does it belong on the shared list?

It belongs there when either is true:

  • Another person, function, or team cannot move until it is delivered.

  • It is materially tied to an enterprise priority, KPI, decision, or cross-functional dependency.

Is it a valid commitment?

A commitment is valid only with one owner and three things clear:

  • The outcome

  • The definition of done

  • The date

The outcome is what you will produce. The definition of done describes what the person waiting can now do—not what the owner completed. Most of the time the two live in one sentence; stating done separately just removes the argument about whether the work is complete.

The gap shows up when the outcome is fuzzy. "Improve the forecast inputs" is an outcome with no done. Add done: "Sales submits forecast inputs by the third business day, and finance no longer has to chase them." Now anyone can check it.

The two tests do different work. Fail the first, and it is a task—keep it off the shared list. Pass the first but fail the second, and it is not ready to enter the system.

Saying something in a meeting does not make it a commitment. Meeting the standard does.

Most of what a leadership team discusses should never reach the shared list. That is the point. The list stays short enough that the team can see what actually matters.

When the standard is met, the person waiting can tell whether a commitment was kept without debating effort or intent. Done or not done. By the date or not. The reason for a miss still matters—it helps the team learn and intervene—but the explanation should not redefine completion after the fact. This is not about blame. It is about seeing a problem while there is still time to fix it.

Keep the standard simple

The operating standard does not need to be complicated:

  • The owner states the commitment aloud: outcome, definition of done, and date.

  • The owner enters it within the team's agreed window.

  • Nothing lands on the shared list that the owner did not accept.

  • The original date stays visible. If the commitment is renegotiated, the new date and reason are recorded.

  • One person keeps the list honest and reports the score, and does not write commitments for everyone else.

The owner owns both the result and the quality of the commitment. If a commitment is unclear, the owner sharpens it. That is not the scorekeeper's job.

Expect the list to shrink

When the standard takes hold, the list usually gets shorter. That is a good sign. A short list of real dependencies is worth more than a long list of activity.

Completion may even drop at first. The team is trading a flattering number for an honest one. Only when the inputs are clean does the completion rate mean anything.

Then someone will say the tool is clunky and offer to build a better one. They may be right. But a new tool inherits the same confusion until the team agrees on what belongs in it and what makes an item valid.

The tool keeps score. It does not decide what deserves to be scored.

The team still has to make the commitment

Return to the CEO who stopped the meeting. The nods were not the failure. They revealed it. The team agreed with the standard. No one had yet committed to being held to it.

A commitment system does not create accountability. It makes accountability visible. The team still has to supply the willingness to be held to its word. The system can preserve the agreement, expose the miss, show the pattern, and support intervention.

It cannot make the commitment for anyone.

Accountability is not installed through policy. It is built through clarity, ownership, and commitments the team has chosen to make.

Task: yours to manage.

Commitment: an outcome someone else is counting on, delivered by a date.

Roger Young works with executive teams on the systems that connect strategy to execution. Excel Leadership Group.

the Leadership Operating System (LOS™) — a disciplined way for leadership teams to operate as one and consistently deliver results.

info@mail.com

the Leadership Operating System (LOS™) — a disciplined way for leadership teams to operate as one and consistently deliver results.