The Work Between the Boxes

I was working as a Technical Project Manager at Celebal Technologies, helping coordinate a $1.2 million Databricks migration for NXP. Until then, I had thought execution problems would be visible: a major technical failure, a missed deadline or an obvious disagreement.

Instead, I discovered that execution usually fails quietly.

It fails in the time between two follow-ups. It fails when five people attend a meeting but nobody leaves with ownership. It fails when “blocked” remains written on a tracker for four days without anyone defining what will unblock it.

Our response was to create a war room involving developers, architects, platform teams and client stakeholders. Nearly 30 people were connected to the recovery effort. But simply putting more people into a meeting did not solve the problem. In fact, without structure, it could have added another layer of complexity.

What changed the situation was a deceptively simple shift. We stopped discussing only the status of each problem and started defining the next physical action.

“Access is pending” was not accepted as an update.

“Person A will provide the required access by 4 p.m.; Person B will validate it by 5 p.m.; the issue will be escalated if it is not received by 4:15” was an executable update.

That distinction taught me more about operations than any sophisticated project-management framework. A plan describes where an organisation wants to go. Execution identifies who must make the next move.

The distance between intention and action

Most organisations do not suffer from a shortage of ideas. They have strategy decks, transformation programmes, dashboards and improvement initiatives. The real difficulty lies in translating an idea through multiple layers without losing its original intent.

A senior leader may say, “We must become more customer-centric.”

A team converts that into a programme. The programme becomes a set of targets. The targets become tasks. The tasks finally reach an employee handling a customer request at 6:30 on a Friday evening.

By then, the employee may be measured on closing the ticket quickly rather than solving the customer’s problem completely.

The strategy has not necessarily been rejected. It has simply been distorted during translation.

This is why I believe the real unit of execution is not the presentation slide or the quarterly goal. It is the decision made closest to the work.

If that decision supports the strategy, execution moves forward. If the employee faces conflicting incentives, unclear ownership or an unnecessarily complicated process, even a brilliant strategy begins to weaken.

Automation does not repair a broken process

I encountered a different version of the same lesson during my time at Bank of America.

My work involved automating regression testing for Oracle Accounts Payable systems. Over time, our team built more than 1,700 automated scripts covering over 1,200 vendor-onboarding and invoice workflows. The automation helped reduce a regression cycle that once took approximately five weeks to around two weeks.

It was tempting to describe this purely as a technology success.

However, the difficult part was not writing the scripts. The difficult part was understanding and standardising the process before automating it.

A script needs a clear answer. What should happen when a field is empty? Which business unit follows which rule? Is a failed validation a defect, an expected exception or a data problem?

Human beings can sometimes work around ambiguity. A system cannot. It will repeatedly execute whatever confusion has been built into it.

That experience changed how I think about scale. Technology can multiply efficiency, but it can also multiply disorder. Automating an inconsistent process does not create operational excellence. It only allows inconsistency to travel faster.

The organisations that scale successfully therefore do something unglamorous before they introduce new tools: they simplify decisions, clarify rules and remove unnecessary exceptions.

Frontline employees hold the missing information

Operational problems are often diagnosed from conference rooms. But the people closest to the work usually know where the process actually breaks.

They know which approval always takes two additional days. They know which mandatory field customers misunderstand. They know which dashboard shows green even when the ground reality is red. They may even have created informal spreadsheets or WhatsApp groups to compensate for gaps in the official system.

These workarounds are easy to dismiss as indiscipline. In reality, they are signals.

Whenever employees repeatedly bypass a process, the organisation should ask whether the people are resisting the system or whether the system is resisting the work.

During testing cycles at Bank of America, some of the most useful insights came from testers and business users who had observed the same failures across several releases. During the NXP migration, developers working on individual workstreams often identified dependencies long before they appeared in management reviews.

Frontline involvement is therefore not only an engagement exercise. It is an operational necessity. Strategy provides direction, but frontline employees provide contact with reality.

Efficient is not always effective

Execution is also weakened when organisations confuse efficiency with effectiveness.

An efficient team may close 100 support tickets in a day. An effective team asks why those tickets are being raised repeatedly.

An efficient meeting may finish in 20 minutes. An effective meeting ends with decisions, owners and deadlines.

An efficient employee may complete every assigned task. An effective employee may question whether one of those tasks needs to exist at all.

This distinction becomes especially important as organisations grow. Every new layer, tracker, approval and handoff may appear reasonable in isolation. Together, they create a hidden tax on execution.

I have built and managed several project trackers myself. They were useful when they exposed ageing blockers, clarified dependencies or triggered escalation. But I also learned that a tracker can create the illusion of control. Updating a row is not the same as resolving the problem represented by that row.

A process adds value only when it changes an action or improves a decision.

Execution should not depend on heroics

When projects fall behind, organisations often celebrate the person who stays awake until 3 a.m. and rescues the release. That effort deserves appreciation, but a system that repeatedly requires rescue is not a strong system.

Good operations reduce dependence on exceptional individual effort.

They create predictable review rhythms. They make problems visible early. They distinguish reversible decisions from irreversible ones. They allow teams to move quickly where mistakes can be corrected and demand greater precision where errors are costly.

Most importantly, they make consistency possible.

Consistency rarely receives the same attention as innovation. It does not produce dramatic announcements. It looks like a checklist being followed for the hundredth time, a blocker being escalated before it becomes a crisis or a team conducting the same disciplined review after every release.

Yet this repetition is often the source of competitive advantage. Customers may not see the process, but they experience its outcome as reliability.

The real work lies between the boxes

In classrooms and presentations, organisations are represented through neat boxes connected by arrows. Strategy flows into planning, planning into execution and execution into results.

In practice, the most important work happens between those boxes.

It happens when one team hands over work to another. It happens when an unclear target is converted into a measurable action. It happens when someone notices that a process is no longer serving its original purpose and chooses to improve it.

My experiences have taught me that getting things done is not primarily about working faster or adding more pressure. It is about reducing the distance between information, ownership and action.

Ideas may begin the journey. But what survives is decided by the systems, habits and people that carry those ideas through the final mile.

And more often than not, that final mile is where the real strategy is revealed.