The team was not fighting. That made the friction easier to miss. A review waited two days. A handoff lost one small decision. A tester asked the same question for the third release in a row. Nobody had done anything terrible, but the system was starting to ask people to compensate quietly.
Friction is not the same as failure. It is the small resistance people feel when the way work moves does not match the way decisions, context, or ownership are actually arranged. Left alone, friction becomes a story. The story often becomes blame.
Early friction sounds ordinary. I did not know this was mine. I thought product had decided. I was waiting for review. I did not see the updated acceptance criteria. These sentences are not accusations yet. They are clues.
The healthy move is to look at the path before judging the person. Where did context disappear? Where was ownership unclear? Which decision lived only in a meeting? Which tool made the next action invisible?
This does not remove accountability. People still need to follow through. But accountability works better when the process is not forcing good people to guess. A team should not need hero memory for routine delivery.
Friction becomes dangerous when people normalize it. A little delay is fine. A little repeated confusion is not. Repetition is what turns a small inconvenience into a team tax.
I like naming friction in low-drama language. We are losing context between planning and QA. Reviews are waiting because ownership is implicit. Release notes are too late for support. The sentence should point at the system first.
If the team can notice friction early, it can fix something small: a template, a checklist, a clearer owner, a decision log, a better handoff. That is much cheaper than waiting until people are tired enough to explain the problem as someone else's character.