Give Feedback Early. Judge People Slowly.

In the previous post, I wrote about finding a gap in the work and carrying it into the next task as a checklist item. Once we have a standard, we have to use it in real feedback.

When I see something that needs to improve, I tend to raise it early. Before deciding who is right, I want to understand what is different. The friction I mean is closer to feedback in a code review than to a fight.

What does each person consider finished? What do they see as their responsibility? If a change is difficult, why? I do not want us to rush into the work before we understand those differences.

For example, the person handing off a design may consider the screen finished once it is drawn. The person receiving it may expect the narrow-screen states and exceptions to be decided too. By their own standards, both people may have finished the work, but the next step is missing different things.

If we find that gap for the first time in development or QA, someone has to fill it in late. That is when we discover that we had different work in mind all along.

So, when someone asks, “Why bring it up at the start?” I can answer:

I am checking at the start to see whether there is a problem. I do not want us to get further into the work and only then find out that we had different things in mind.

Look at the process before the person

When a problem appears, I think we should first look at the way work is set up and how it is led. Were the completion criteria clear? Did people have the information and time they needed? Did the person making the decision have the authority to do so? Did a late leadership decision become a bottleneck?

When the same omission happens across several people and tasks, individual effort is less likely to be the first cause. Roles may be unclear. Someone may be held responsible without having the authority to decide. People doing the work may be left to resolve a conflict that a leader should handle. If we judge the person first, we can end up assigning an organizational problem to an individual.

After checking the process and leadership, we should look at how the person carried out the work. If they had clear standards, authority, and support, and the same problem still recurs, then we can talk specifically about skill, choices, and responsibility. This is not about protecting people at all costs or removing individual responsibility.

I think the order of evaluation should move from process and leadership to the individual. That gives us a chance to examine organizational problems before judging someone too quickly.

Raise the issue early without applying pressure

Asking a question early is different from applying heavy pressure. If we start by pushing hard, we may learn more about how someone defends themselves under pressure than how they think about the work. We lose sight of what we meant to understand.

Instead of asking, “Why are you not trying to improve this?” we can ask, “This omission makes the next person ask the same question again. What makes it difficult to check before handoff?”

That leaves room to find out whether the obstacle is interest, time, or authority. We can raise the issue without rushing to a judgment about the person.

Ask early, but do not rush to a conclusion about the person. That is what I mean by early friction.

Decision-making authority comes with evidence and responsibility

To wait before judging someone, we need to make the basis for our feedback visible first. We should be able to point to the missing completion criteria, the difference from an existing rule, or the rework it creates for the next step.

Every task needs a final decision-maker. The DRI (Directly Responsible Individual) leading the work should consider the different views and evidence, decide when the work is ready, and own the execution and outcome.

Leaders are not exempt from review. For the area they lead, they should be the DRI. Their job is not to stand away from the work and only evaluate people. They should set priorities, make necessary decisions, and turn repeated problems into process improvements. The organization should ask whether leaders have enough authority and resources, and whether they actually reduce bottlenecks and rework.

If I built an organization, I think I should be prepared to pay a leader at least 1.5 times as much as an individual contributor with the same scope, and up to twice as much depending on the responsibilities of the role. That would not be because of a higher title, but because the leader takes on broader and harder responsibilities. A leader should do the work, make decisions, explain the outcomes, and improve the way we work so that the same problems do not keep happening.

A role is not leadership if it pushes individual contributors’ responsibilities onto someone without giving them enough pay or decision-making authority. On the other hand, a title alone should not put someone in charge of people before they have shown they can execute and take responsibility. A leader should create the conditions for the team to work better and be accountable for the results.

The problem is not that someone has authority to decide. The problem is when that person’s close connections get exceptions more easily, while the reasons and responsibility remain hidden. If a formal process says yes or no based on who someone knows, then quality is being decided by relationships instead of the work.

We cannot remove every political judgment between people. I know I may want to defend my own decisions too. That is why I think we have to keep improving the way a business defines completion and quality so it depends more on visible criteria and evidence than on someone’s authority.

AI can help make an initial review more consistent without taking decision-making authority away from the DRI. Using an agreed checklist and observable measures, it can surface omissions first and ask the same questions when the conditions are the same.

People still need to discuss the feedback and review. They need to decide whether a flagged item is really a problem, whether an exception is justified, or whether the standard itself needs to change. The DRI makes the final decision and owns the result. AI should not be a judge of people; it should help people begin their conversation from the same evidence.

Friction is not about winning

It is not enough to decide who was right after a disagreement. We need to agree on what done means, who decides, and what information to leave for the next task.

Otherwise, the same conversation will happen again on a different screen or under a different deadline. Then the friction I created is not helping us improve; it is just personal pressure I have to apply whenever I need to move the work along.

I do not want to avoid uncomfortable questions. I want them to clarify what the next step needs, rather than push someone into a corner.

Raising friction early does not mean starting a conflict sooner. It means finding out, before we get too far, where our definitions of done and boundaries of responsibility differ. When those differences become a shared standard and the next review starts from that standard, friction can help the work get better.