Most people running complex commerce environments will reach for the same explanation when execution starts to feel heavy: it is just how complex this work is. Complex environments. Complex integrations. Complex stakeholder structures. Complex data.
I have spent over 18 years working on these implementations with manufacturers, distributors, and complex retailers. And I have come to believe that explanation, while understandable, is not quite right. Complexity is real. But it is not what breaks execution. What breaks it is something more specific, more addressable, and almost always overlooked.
Key Takeaways
- Complexity does not break B2B commerce execution, the absence of clarity does.
- Heavy execution usually comes from adding layers (roles, meetings, documentation) to compensate for missing clarity, not from the work itself.
- Execution systems built for completeness (following industry convention) differ from systems built for intentionality (connected to real outcomes).
- The fix is a design choice: build a system where information enables good decisions by default, not one that requires constant human effort to reconstruct reality.
A familiar weight
There is a particular feeling that most people in complex commerce organizations know well, even if they have never named it precisely. The project looks serious from the outside. Responsible. Well managed. There is a project plan. There are weekly status meetings. There are detailed deliverables and engaged stakeholders. Everyone is working hard.
And yet something feels off. It is harder than it should be to answer a simple question: are we actually on track? Not the official answer. The real answer. Decisions feel slower than they should be. Costs keep growing. Timelines keep shifting. And the most frustrating part is that you cannot point to one thing that is broken. Everything looks fine. But execution feels heavy.
You cannot point to one thing that is broken. Everything looks fine. But execution feels heavy.
The natural explanation for that feeling is complexity. And it is not wrong exactly. Complex environments are genuinely hard to execute in. But attributing the weight to complexity misses something important about where the weight actually comes from and, more usefully, what can actually be done about it.
What actually breaks execution
What breaks execution is the accumulation of layers, roles, meetings, documentation, and coordination, added to compensate for missing clarity rather than to create it. Each layer feels justified individually, but collectively they put distance between the people doing the work and the reality of what is actually happening.
When execution starts feeling heavy, the natural organizational response is to add layers: more strategy, more research, more roles, more meetings, more documentation, more coordination, more oversight. Every single addition feels justified. Each one is intended to reduce risk, create alignment, provide control. And individually, they often do exactly that.
But collectively, they do something else. They create distance between the people doing the work and the reality of what is actually happening. And as that distance grows, something counterintuitive occurs: it becomes harder to answer a simple question about whether the work is on track. Not because the question is hard. Because the system that should answer it is now too many layers removed from the truth. The layers are not the enemy. The enemy is using layers to compensate for the absence of something that should exist in the execution system by design. That something is clarity.
A story I find uncomfortable to tell
About six years ago, we led a full replatforming engagement for a manufacturer. We ran what most people in this industry would consider a best-in-class strategy engagement. Several months of work. A full-time strategist. A UX researcher. A UX designer. Over a hundred pages of documentation: competitive analysis, personas, customer journey maps, influence models, brand voice, content strategy, market analysis, and many other well-crafted activities and deliverables. It was genuinely good work. The client was happy with it. And the site that eventually launched looked great.
But shortly after the new website launched, we asked ourselves an honest question. What actually changed the business outcome? The answer was uncomfortable. A fraction of the work, specifically the core findings from the personas and customer journey work, the high-level content strategy direction, the visual design and style guide, and ultimately the page templates built around all of that, was what shaped the final result. Meaningful work, but probably fifteen to twenty percent of the total effort. The rest, while genuine and well-executed, did not move the needle.
All that work was not creating clarity. It was compensating for the absence of clarity in the system.
The deeper question, the one that took longer to sit with honestly, was why. And the answer was not that we worked too hard or spent too long. It was that we started working before we had clarity on what the client actually needed to achieve, as distinct from what they said they wanted. We had not asked with enough rigor what they already knew about their market, their customers, and their competitors versus what was genuinely missing. We had not established which specific activities were actually necessary to achieve the project's stated objectives, and why.
Instead, we followed the system. The same system most organizations in our industry use. It told us what a strategy engagement of this type should include, and we delivered it with skill and care. But the system was not designed to guide us toward intentionality. It was designed to guide us toward completeness. We were checking boxes and following best practices rather than asking, for every activity and every deliverable, whether it was genuinely necessary for this client's actual goals with this project. The work was great. The intention behind it was not there.
For years, we followed the same industry defaults that everyone else did. We built the documentation, ran the strategy engagements, added the roles. We did not realize at the time that we were compensating for the absence of clarity rather than creating it. That recognition is what started us on a fundamentally different path.
That was about doing too much work. But the same pattern shows up in a different way.
A second story, different symptoms, same pattern
The first story was about doing too much work. This one is about having too many roles between the work and the outcome.
About four years ago we were working with a large distributor on post-launch continuous improvement. The team structure looked solid on paper. Three to four engineers, a UX designer, a business analyst, a solution architect, and a full-time project manager. All capable people. Progress was happening. The client was not unhappy.
But both sides felt things were slower and heavier than they should be. Nothing was obviously broken. There was just a lot of friction.
What we eventually realized was that the problem was structural. The BA owned requirements. The architect owned the solution. The engineers owned implementation. The PM owned coordination. Everyone was doing their job. But nobody clearly owned the outcome. And the people closest to the system, the engineers and the designer, had quietly become passengers rather than drivers.
When engineers are executing what they are told rather than thinking critically about why they are doing it, the quality of every decision degrades.
They stop questioning whether a requirement actually makes sense. They stop suggesting better approaches. They stop taking ownership of the result because they do not feel it is theirs to own. The system trained them to wait for instructions rather than to lead.
We started changing the model gradually. We pushed ownership of business requirements closer to the tech leads. We removed the translation layers between the client's needs and the people building the solutions. We raised expectations for engineers to think strategically, not just implement, and to understand the business context of every decision they made.
Not everyone was able or willing to step up. Some engineers had become comfortable in a system where someone else did the thinking and they could point to other roles when things were unclear. Raising the bar exposed that, and we mutually agreed for some team members to move on. That was a necessary cost of the change.
Today the team for this client is actually larger. Engineers only, elevated. One also acts as a tech lead. The investment is slightly higher. But the ROI is significantly higher. Not because the people are fundamentally different. But because the system they operate in no longer creates distance between the people doing the work and the outcomes that work is supposed to produce.
Completeness versus intentionality
The manufacturer story was about activities and deliverables that were not connected to outcomes. The distributor story was about roles that created distance between the work and the people who understood it best. Both are symptoms of the same underlying pattern: execution systems designed for completeness rather than intentionality.
Most organizations, when they experience heavy execution, ask: how do we improve the process? What role is missing? What tool would help? Those are reasonable questions. But they are not quite the right ones. The right question is: does the execution system produce clarity as a matter of course? Or does clarity require constant human effort to construct and maintain?
The first kind of system is built to produce clarity by design. Before work begins, there is genuine shared understanding of what the engagement needs to achieve and what gaps actually exist, as distinct from what was assumed or asked for. Every activity and deliverable is connected to those outcomes, not to industry convention or process completeness. And as the work runs, information is accessible without asking anyone, what you see reflects what is actually happening, and that information enables decisions without requiring interpretation.
The second kind of system requires constant human effort to keep clarity alive. Someone has to update the status report. Someone has to reconcile the budget. Someone has to run the meeting that reconstructs reality from the inputs of a dozen different people.
Execution feels heavy in those environments because the system was not designed for clarity. The layers were added to compensate. And as the layers grow, the distance from reality grows with them.
Most complex commerce organizations are operating in the second kind of system and trying to get the results of the first one.
What a system designed for clarity actually looks like
A system designed for clarity starts with genuine shared understanding of what an engagement needs to achieve, connects every activity to that outcome, and keeps scope, progress, risk, and decisions visible in real time rather than reconstructed after the fact. This reflects the architecture-first approach we bring to commerce execution.
This is a framework we call the Clarity Ladder, developed through years of working on complex commerce implementations with clients. It has eight levels, from Transparency at the foundation to Competitive Advantage at the top. Each level is only accessible when the one below it is in place. Most organizations are somewhere between Levels 1 and 2. Very few have reached Level 3, which is the turning point where information stops being something you access and becomes something that enables decisions. The framework is documented in full in its own article.
The difference between heavy execution and clear execution is not complexity. It is design.
A system designed for clarity starts with a genuine shared understanding of what needs to be achieved and ensures every activity connects to those outcomes rather than to process convention. As the work runs, scope is visible, progress is real-time, risks surface before they become crises, ownership is explicit, and decisions and their rationale are captured as they happen.
When that system exists, the layers that were added to compensate for its absence start to look different. Not essential. Optional. And the energy that was going into meetings that reconstructed reality can go somewhere more useful instead.
The question worth sitting with
The question worth sitting with is simple: can you see the real state of execution, does it reflect reality, and does it enable good decisions without someone explaining it to you first? If the honest answer is no at any of those steps, the weight you feel is a clarity problem, not a complexity problem, and clarity is a design choice you can make.
Where are you on the Clarity Ladder right now? Not where your last status report says you are. Where you actually are. Can you see the real state of execution right now, without asking anyone? Does what you see reflect what is actually happening? Does that information enable you to make good decisions without someone explaining it to you first?
If not, the weight you are feeling in your execution is not a complexity problem. It is a clarity problem. And clarity is a design choice.
Radu Munteanu
Founder & CEO, Luminos Labs