How Decisions Move

Idea one

At that moment, there is only a signal

A customer says something is wrong. A report contains a number that does not make sense. A frontline employee sees a safety risk. A manager hears the same complaint for the third time. A technician finds a component that failed earlier than it should. Someone in finance notices a supposedly routine invoice dispute spreading across several accounts.

At that moment, there is only a signal. It may be clear or ambiguous, urgent or easy to ignore. It may arrive through a formal system, a customer call, a conversation in a corridor, or a feeling that something does not add up. But before an organization can decide what to do, somebody must recognize that the signal matters and must be willing to speak.

This first stage is often treated as automatic. It is not.

Organizations spend real effort on decision rights, approval processes, meetings and implementation plans. They are less likely to examine how problems first become visible. Yet a problem that is not seen cannot be addressed, and a problem that is seen but not voiced may become more expensive, more dangerous, or harder to resolve before it reaches anyone with authority.

At Northstar, the failed equipment was not identified by a director reviewing a dashboard. It was identified by the customer, who called their account executive because he was the person they knew and trusted. He did not own field service, control the warehouse, or have the power to release a part from credit hold. But he heard it first, and his response determined whether it entered the organization as a serious operational issue or stayed, for a while, a difficult customer conversation.

People closest to the work often see problems first — the customer's frustration before it appears in a retention report, the process failing before a monthly metric declines, the workaround and the repeated rework. None of them may have authority to resolve the issue. But they hold something just as important at the beginning of the decision journey: proximity to the truth.

Idea two

A route, time, and reason to speak

Organizations that silence, dismiss or exhaust frontline employees become slow to learn. They may still have senior leaders, dashboards, governance meetings and formal risk registers — but the earliest signals are weakened before they reach those mechanisms.

The problem is not always that people are afraid to speak. Sometimes they simply do not believe speaking will make a difference.

Someone raises a concern and receives no response. They point out a recurring defect and are told it is not their area. They submit a suggestion into a system that appears to have no reader. They alert a manager to an emerging issue and are asked why they cannot solve it themselves. After enough experiences like this, people adjust. They stop escalating. They solve what they can privately. They complain to trusted colleagues rather than raising things formally. They wait until the problem is undeniable.

That behavior gets described as a lack of ownership. But ownership is difficult to sustain when the organization gives people responsibility for noticing without offering a credible route for being heard. A business can tell people to speak up as often as it likes. The real test is whether it gives them a route, time, and reason to do so.

And sometimes the first person to notice benefits from keeping quiet. A sales manager hesitates to flag an unrealistic implementation date because the deal is close to signing. An operations manager avoids reporting a capacity problem for fear of looking unable to manage the team. These are not necessarily acts of bad faith. They are often predictable responses to incentives and consequences. If Sales is rewarded for bookings but not for successful delivery, an operational concern is experienced as a threat to a target.

Which sets a trap for the organization, because early signals are rarely complete. They sound inconvenient, uncertain, small: "The customer says this feature is not working." "I think this stock number may be wrong." "We have had a few similar complaints." An organization that demands certainty at this stage will hear about problems late — by which time the customer may have left, the cost may have risen, or the options may have narrowed.

The right response to an early signal is not always immediate intervention. It may be investigation, monitoring, or a request for more evidence. But the signal must have somewhere to go.

Idea three

When a local fix becomes evidence

A support adviser at Northstar takes several calls about the same thing: customers cannot download service records from the portal. Each call can be handled with an apology and a manual email. In isolation no call is severe. She logs them, sends the records, moves on.

But after the fourth call, she sees a pattern.

Now she has a choice. She can keep treating each contact as an individual request — keeping the immediate customer happy while leaving the underlying fault invisible — or she can raise the pattern: not "one customer needs a document," but "the portal may be failing for a group of customers, and support is creating a manual workaround." That is the point at which observation becomes organizational information.

Whether she makes that move depends on conditions that have nothing to do with her character. Does she know where to raise it? Does the system let related cases be linked? Does her manager ask about recurring issues, or only about call volumes and response times? Will Product treat her evidence as useful or dismiss it as anecdotal? Most importantly, does she expect that raising it will lead to action?

The distinction underneath all of this is easily missed. Good employees are often skilled at local problem-solving — they find the missing document, call the helpful colleague, correct the data, stay late to finish the task. Their practical judgment keeps work moving. But a manager should ask a second question: what does this local fix tell us about the system?

If the adviser sends one service record manually, she has helped a customer. If she sends fifty over two weeks, Northstar does not have fifty isolated requests. It has a portal issue, a growing workload in support, and possibly a failure in the handover between Product, Technology and the customer-facing teams. The number of manual fixes is not just activity. It is evidence.

Idea four

Escalation is not the same as upward

Escalation is often misunderstood as sending a problem upward. Sometimes that is what it is. But hierarchy is only one part of it. In practice, escalation means moving an issue from the place where it was noticed to the place where someone can make, support, or coordinate the next decision. That place may be higher in the hierarchy. It may also be sideways.

A support adviser may need Product, because a recurring portal fault cannot be fixed by better call handling. A service manager may need Finance, Sales and Operations to consider an urgent customer situation together. A project manager may need a technical specialist to judge a risk before a senior leader can choose anything at all.

The key question is not "Who is senior enough?" It is "What decision is needed, and who has the authority, information, and capacity to make it?"

When people cannot answer that, escalation goes wrong in one of two directions. A slow escalation climbs through layers of management that add little value — supervisor to manager, manager waits for the weekly meeting, meeting agrees another department should be consulted, that department asks for more evidence. By the time anyone with the right authority sees it, the original problem has grown.

A broad escalation copies everyone in because nobody knows who owns the decision. Twelve recipients, each with a slightly different reading. Some reply at once, others stay silent, one asks for detail, another proposes a solution outside their area, a third says they were not consulted early enough. The sender has created visibility, but not movement.

This is not a failure of email etiquette. It is a structural failure.

And a related one sits behind a lot of silence: people do not know whether a problem is theirs to raise. Support sees the customer impact and assumes Product owns the fault. Product assumes Technology owns the system. Technology sees an error log and assumes Support will say whether customers are affected. Each team holds a piece of the picture. Nobody feels entitled to assemble it. So the useful question is not "Whose fault is this?" but "Who is responsible for making sure this signal enters the decision process?" That person may not own the solution. But someone must own the next movement.

Idea five

A decision is not a change

A decision made in a meeting, approved in an email or announced by a senior leader changes nothing by itself. For the organization to move, somebody must turn that decision into action.

A decision is not the same as a change.

This sounds obvious, and organizations behave as though the difficult part is over once someone has said yes. A director approves an exception. A management meeting agrees a priority. An email announces that a process will be revised. It goes in the minutes, the meeting ends, everyone moves to the next item. Then a week later the customer is still waiting, the old process is still in use, or the same problem appears again.

The decision happened. The change did not.

Implementation is the journey between those two facts — turning an authorized choice into a different reality: a part released from the warehouse, a customer contacted, a system amended, a policy changed. And it exposes a common misunderstanding about authority. The authority to make a decision and the capacity to carry it out are different things.

At Northstar the decision was to release the part despite the credit hold. Finance assessed the debt position, Daniel accepted the commercial risk, the service manager confirmed the urgency, the finance manager approved within her limits. That was an important decision. It was not yet a restored customer site. The warehouse still needed a clear instruction. Someone still had to remove or override the hold in the system. The supervisor still had to locate the part physically, not merely rely on the stock record. The engineer had to be assigned, briefed and able to collect it. The customer needed an accurate update. Any one of these steps could stop the work.

So implementation is not an administrative afterthought. It is where decisions meet the real organization: its workloads, systems, handovers, competing priorities, unclear instructions and practical constraints. A decision that cannot be implemented is not fully a decision. It is an intention.

Which is why the first requirement is clarity about what exactly has been decided. "Please prioritize this customer." "We need to improve communication." "Let's make an exception." "Operations needs to take ownership." Each may reflect genuine agreement. None tells the people doing the work what they must do next.