Process is the surface

When work is slow or inconsistent, the first instinct is often to fix the process. Add a step. Remove a step. Document the workflow. Automate the handoff.

Sometimes that works. But process is often where another problem becomes visible.

A broken handoff may be a decision-rights problem

Two teams can have a perfectly documented handoff and still fail if neither has authority to resolve the exceptions. A workflow can be automated and still produce bad outcomes if the underlying definitions are contested.

A checklist cannot repair incentives that reward one function for creating work another function has to absorb.

Automation is especially good at revealing this. If humans disagree about what a status means, automating the status change does not create alignment. It creates faster disagreement.

Before automating, I want to know whether the organization has actually decided what the process is trying to preserve.

Follow the symptom upstream

When I hear ‘process problem,’ I start asking: What information is missing? Who has authority? What is each team rewarded for? Where is capacity constrained? Which system owns the truth? What relationship has lost trust?

The answer may still be a process change. But now the process is solving the cause rather than organizing the symptom.

Process is not unimportant. It is simply rarely alone.

I keep coming back to a simpler description of process: steps are handoffs, handoffs happen between relationships and roles, and those handoffs represent commitments. The steps are agreements about who is doing what part of that commitment.

That is why a process problem so rarely stays contained inside a process diagram. If the agreement is unclear, if authority and responsibility do not match, if the information required to complete the handoff is inaccessible, the process is only where the deeper design choice becomes visible.

Processes developed together are more deeply understood. Systems built together are shared systems. The diagram matters, but the agreement underneath it is what makes the diagram real.

A decision is not finished at approval

Organizations are full of decisions that are technically complete and operationally unfinished. A new pricing model is approved. A market is entered. A partnership is signed. A compensation plan changes. A tool is purchased.

The decision has an owner, a slide, and a date. Then the work arrives downstream.

Execution is part of strategy

Who has to change behavior? Which systems need new logic? What data must exist? Which teams inherit exceptions? What customer communication changes? What happens to work already in flight?

Those are not administrative details after the strategic work. They are part of determining whether the strategy is viable.

The cost often moves to the least powerful place

When execution is not considered early, the missing design does not disappear. It becomes manual work, late nights, customer confusion, escalations, spreadsheets, and local workarounds.

The organization may still call the initiative successful because the launch date was met. The people carrying the unplanned complexity experience a different outcome.

I prefer strategic decisions that include the people who understand how reality will resist them. Not because every decision should be made by committee, but because feasibility is information.

A strategy becomes stronger when implementation can change the decision before the decision becomes expensive to change.

A decision is not finished because leadership agreed. It is finished when the organization has a credible way to make the promise real.

Execution is where the decision encounters reality

Frameworks are the structures that help turn vision into reality. Building them—and reinforcing their design every day—is part of how change actually happens.

This is why I want people who understand execution in the room before a decision hardens. They know where data does not exist, where a workflow will break, where a customer promise creates an internal exception, and where a supposedly small change requires three other systems to behave differently.

A decision can be strategically elegant and operationally impossible. Reality is not an implementation detail.