Two words that do more work than most team rituals: I understand.

The protocol is simple. When you receive instructions, you say one of two things. If you understand, you say “I understand.” If you don’t, you say “I don’t understand.” That’s the whole system.

It sounds almost insultingly basic. In practice, most teams don’t have anything like it, and the absence costs them constantly.

The problem the protocol solves is false confirmation.

False confirmation happens when someone says “got it” or “sure” or nods in a meeting, not because they understand, but because admitting confusion feels costly. The social cost of saying “I don’t understand” - looking slow, holding up the group, appearing unprepared - is higher than the cost of quietly figuring it out later. So people perform understanding they don’t have, and the confusion travels downstream.

By the time it surfaces, it’s expensive. The wrong thing was built. The dependency was missed. The deadline was misunderstood. The task was started from a false premise and now has to be redone. And the person who originally gave the instructions has no idea any of this happened, because the feedback they received was “got it.”

The protocol does not eliminate this problem by force. You can’t make people honest about their confusion just by having a rule. What the protocol does is change the default. It makes “I understand” a deliberate signal and “I don’t understand” an equally acceptable one. Both are professional responses. Neither carries a social penalty. The person who says “I don’t understand” is not admitting failure - they are doing their job.

The specificity of the phrases matters.

“I understand” is a stronger claim than “got it” or “sounds good.” It commits the speaker to a level of comprehension. It says: I know what you’re asking, I know what I need to do, I’m ready to act on this. That commitment creates accountability. If you said “I understand” and then did something different from what was asked, the question is not “did the message land?” - it’s “what went wrong in your execution?”

This is not punitive. It’s clarifying. “Got it” is soft. It means the message was received but makes no claim about what was understood. “I understand” is hard. It closes the loop with precision. If things go wrong after “I understand” has been given, you have a clear starting point for the conversation about what happened.

“I don’t understand” is equally precise. It is not “I’m confused” or “can you repeat that?” It is a formal signal that the handoff has not completed - that the sender needs to clarify before the receiver can proceed. It keeps the loop open until it can be properly closed.

The phrase is also a design decision about the culture.

A team that uses this protocol has implicitly agreed that clarity matters more than appearances. That’s not nothing. In most environments, the dominant incentive is to appear competent, which means performing understanding even when you don’t have it. The “I understand” protocol inverts this by making honesty the professional standard. Saying “I don’t understand” is not a confession. It is a correct response to incomplete information.

This requires leadership to model it first. If the senior person in the room never says “I don’t understand” - if the culture is one where leaders are expected to already know everything - the protocol doesn’t work. Junior people watch what gets rewarded and what gets punished. If confusion is treated as weakness in the people above them, they will hide their own confusion and pass the cost downstream.

The protocol only works in a culture that takes it seriously from the top.

The application to software is direct.

A spec that gets a round of silence in the review meeting is not a confirmed spec. “Any questions?” followed by silence is not confirmation of understanding. It is confirmation that nobody wanted to be the first person to admit they were confused.

Build explicit checkpoints into your process. After a spec walkthrough, ask each person to confirm: do you understand what’s expected of you? Not “any questions” - a direct request for “I understand” or “I don’t understand.” The distinction is important. “Any questions” gives people an opt-out. “Do you understand?” requires a response.

The same applies to code reviews, handoffs between teams, and any time a task moves from one person to another. Handoffs that don’t include an explicit confirmation of understanding are not handoffs. They are transfers of hope.

Two words. Use them precisely. Make both of them safe to say.

Most team failure is not a failure of effort or intelligence. It’s a failure of transmission. The instruction was given but not received. The requirement was written but not understood. The decision was made but not communicated clearly enough for anyone to act on it correctly.

“I understand” closes those gaps - but only if people actually use it, and only if the culture has made “I don’t understand” a normal and valued thing to say.

If it isn’t, you’ll keep getting “got it” when you needed something more.