Friction Should Become Part of the System

In the previous post, I looked back at an experience where we found missing decisions only after development had begun. Reviewing work earlier can reveal that people have different definitions of done. By friction, I mean bringing those differences into the open and working through them with feedback.

Friction is unavoidable at work. When people with different experiences work together, they will not always agree on what comes first, what counts as finished, or who should decide.

The problem is not that friction happened. The problem is that we leave nothing behind after giving feedback.

Did we agree on what done means? Is it clear who makes the decision? Can the next task move forward without asking the same questions again? If none of these things remain, we have not solved the problem. We have only found a temporary way to get this task through.

Repeated feedback means the system has not learned

If work moves only when I point something out, I have not made friction part of the system. I am still supplying it myself.

At first, I might think I prevented a problem by being careful. But if I have to ask the same question on the next task, my attention is acting as a temporary patch instead of a process.

That may keep things moving in the short term. In the long term, the problem returns whenever a particular person is away, because their understanding of the rules and context never made it into the documents or workflow.

When friction appears, we should leave behind what needs to change. For example:

• Add the missing completion criteria to the handoff checklist.
• Name the DRI (Directly Responsible Individual) who will decide, execute, and own the outcome, and agree on when they will respond.
• Turn a repeated question into a check for the next task.
• Record the cost accepted when an exception is allowed.
• Leave the reasoning the next person would otherwise have to ask for again.

Turn individual judgment into shared work criteria

Leaving feedback in the system does not mean scoring people. It means describing the conditions we can observe in the work before we explain a gap as a problem with someone’s character or effort.

In code review, we can look at test results, the size of a change, rule violations, and missing cases without changing the criteria based on who wrote the code. We can do something similar with design and other work: check whether existing standards were followed, whether states were left undefined, whether decisions changed late, and whether rework repeated.

AI can help repeat this first check against the same criteria. It can show missing conditions without changing its checklist based on who did the work, who knows whom, or what someone’s title is. But an AI result is not a verdict. People still need to explain exceptions and revise criteria that do not fit the work.

A checklist should not replace the decision-maker either. A reviewer and AI can gather evidence, but the DRI doing the work should make the final decision. If the DRI allows an exception, they should record the reason, the cost they are accepting, and own the outcome.

Checklists and metrics are common ground for people to review the same work together, not a substitute for their judgment.

The quality of friction matters too

I do not want to treat friction itself as performance. A heated disagreement does not mean the work improved.

Friction should be judged by the improvement it produces. Did we record what we decided? Did rework go down on the next task? Did the question move earlier in the process?

If review time goes up but rework stays the same, we should change the process too. Adding another checklist does not automatically improve the work. We need to see whether the new step actually reduces repeated waste.

The same standard should apply to leaders and individual contributors. Leaders do not have to solve every problem themselves, but they should leave the team with a way to address a problem that has already surfaced. If individual contributors notice a problem, they can help turn it from a personal frustration into a criterion the next task can use.

Friction will not disappear, but its results can carry forward.

I do not want to say that a way of working has improved just because people have become more careful. I want improvement to mean that we can spot the same problem earlier and make decisions with less rework, without relying on one person’s memory or attention.

If one disagreement changes the rules for the next task, the friction served a purpose. If nothing changes, we have not improved yet.

Leaving a criterion behind does not automatically make feedback better. In the next post, I will think about how to use those criteria without rushing to judge people.

Next: Give Feedback Early. Judge People Slowly →