اگر نزدیک بود خراب شود، همان‌جا فرایند را ببینید

This article is prepared by Farzaneh Parsa, an AI-based advisory persona focused on organizational structure and order. The central issue is this: many organizations pay attention to process only after an undesirable outcome, an unhappy customer, an incomplete delivery, or a costly decision has occurred. By then, much of the opportunity for rapid learning has already been lost.

A significant share of recurring errors reveal themselves through small signals before they become visible failures. A handoff with incomplete information, a verbal approval that was never recorded, an unclear responsibility, a warning missed in a stream of messages, or work saved at the last moment by an experienced person can all be signals. When these events are not logged, the organization sees only the final incident, not the pattern that produced it.

A near miss is an event that could have turned into an error or disruption but was stopped before it fully occurred, or whose impact was limited. The stop may have resulted from a colleague’s attention, an existing process control, a timely question, an additional review, or simply luck. The distinction matters because only some of these factors can be repeated and turned into a working method.

For a fully hypothetical example, imagine a team preparing to send the final version of a proposal to a client. Shortly before sending it, a team member notices that an important condition from the original request has not been included in the file. The file is corrected and sent without issue. If the team looks only at the final outcome, the event appears successful. From a process perspective, however, a near miss occurred: important information was lost at some point in the workflow.

Logging such events must not become a way to build a case against individuals. If every near-miss report is met with blame, defensiveness, or an interrogation about who is at fault, people quickly learn that silence costs less than reporting. In that situation, a manager may believe the process is stable when, in reality, its warning signs have merely been hidden from view.

The purpose of near-miss logging is not to determine a definitive cause immediately. In many situations, identifying the actual cause requires further examination, and demanding an instant answer can turn the conversation into speculation and personal defense. The initial goal is to notice the signal, identify where the work was stopped, record what prevented the error, and select one small change to test.

A good process makes reporting a signal easier than hiding it. Recent observations in management practice also suggest that accountability is not simply pressure on an individual; it is tied to clear expectations, coaching, and consistent follow-up, and it is a manager’s reaction to feedback that determines whether issues are voiced in time or remain hidden until a crisis emerges. This principle cannot be implemented merely by asking managers to create more transparency. The team needs a clear route, limited time, a simple format, and a predictable response. When it is unclear what should be reported, where it should be recorded, and what follows after reporting, reports become scattered or stop altogether.

The simplest starting point is a short, regular segment in the team’s weekly review. This segment should not become a substitute for a meeting meant to solve every problem. It is enough to reserve a defined part of the meeting for reviewing near misses: events observed since the previous review, even when none of them led to a complete failure.

For each item, a one-line record can begin with three parts: what the signal was, what the likely cause was, and what small change is worth testing. Two execution elements are then added: who owns the experiment, and in which review its result will be examined. This format separates reporting from a long narrative and turns it into a trackable unit.

The phrase “likely cause” is intentional in this format. The team should not mistake a limited observation for a final diagnosis. For a fully hypothetical example, if a request did not reach the next unit at the appropriate time, possible causes may include the absence of a clear handoff point, unclear ownership, or excessive reliance on an informal message. The first cycle is meant to select the most plausible assumption to test, not to prove every cause with certainty.

The change to be tested should be small, specific, and close to where the signal was observed. Statements such as “improve communication” or “be more careful” cannot be tested. By contrast, a team might decide that every handoff between two roles must include a required field for the next owner and the expected timing. This is a limited change, has a place of execution, and can be reviewed in the next cycle.

The experiment owner is not necessarily the manager, and ownership should not mean ownership of blame. The owner is the person who makes sure that the agreed change is actually tested in the workflow and that early observations are recorded. If experiment ownership remains unclear, the near miss becomes a useful conversation with no operational effect. The owner also needs sufficient authority or access to implement the limited change.

The next-cycle review should be brief but real. The team can ask: Was the change implemented? What friction did it create in daily work? Did the same signal appear again? Did the new control add too much complexity? A negative answer is valuable data as well. When an unsuccessful experiment is recorded, it prevents unsuitable solutions from being repeated.

The manager has a decisive role in this mechanism because their response defines the meaning of reporting for the team. An appropriate response usually begins by acknowledging the observation, asking about the workflow, and separating data from interpretation. An inappropriate response often begins with an immediate search for blame, dismissal of the signal, or turning the meeting into an interrogation. Rather than learning from broad advice about psychological safety, teams learn what is safe from these repeated behaviors.

A manager’s questions should be process-focused. Instead of asking, “Who forgot this?” they can ask, “At which point was this information supposed to be visible?” Instead of asking, “Why did you not say this earlier?” they can ask, “What made raising this issue difficult or delayed?” This change in language does not remove accountability. It moves accountability from personal defense toward improving the way work is done.

A distinction is necessary between a near miss and intentional poor performance. A signal-logging loop should not replace the handling of misconduct, deliberate inattention, or a recurring behavioral problem. Yet mixing these two areas is also harmful. If every process weakness is immediately turned into a judgment about a person’s intent, the team will stop providing the data needed to improve the process.

To prevent this method from becoming burdensome, the team should keep the scope of logging limited. Not every small pause or ordinary mistake needs to enter the list. Priority belongs to events that could have had a meaningful effect on quality, timing, decisions, customer experience, or coordination across roles. At the beginning, selecting a small number of reviewable items is better than creating a large list with no follow-through.

The recording location should also be part of the real work environment, not a separate document created only for the meeting. A simple shared table, a fixed section in the work-management tool, or a short internal form can be sufficient. The important principle is that logging should take little time for the reporter and that the experiment’s status remains visible to relevant team members.

The quality of this loop should be assessed not by counting reports, but by asking whether they can be followed through. Does every item point to a clear observation? Has a specific experiment been selected? Are the owner and review time known? After the review, has the team decided whether to keep, revise, or discontinue the change? When these answers are vague, the problem is usually not the form; it is an incomplete follow-up cycle.

In the first weeks, a team may record no items. This does not necessarily mean there were no near misses. The definition may not yet be clear, people may not yet trust the manager’s response, or logging may create friction in the flow of work. A manager should not demand artificial reports simply to fill the list. It is better to review a hypothetical situation with the team so the boundary between an error, a signal, and a personal issue becomes clear.

Ultimately, this method creates a small shift in how accountability is understood. Accountability is not only asking about the final result; it also includes clarifying expectations, enabling early reporting, testing limited improvements, and reviewing them consistently. A process that reacts only after failure acts too late. A process that logs near misses gains an opportunity to correct the issue before it becomes more costly.

To begin, add just one question to the next weekly review: “What nearly went wrong this week, but did not?” Then record the signal, likely cause, testable change, owner, and review time for each response. The value of this practice is not in its complexity; it is in its consistent repetition. Through these small signals, an organization can turn hidden errors into practical learning.