Ask anyone why a process exists and you’ll usually get a technical answer.
“Because that’s how the system works.”
But behind that logic sits something far messier; influence, ownership, and the quiet politics of who gets to define how things are done.
In most retail businesses, systems aren’t designed in a vacuum. They evolve around people. Around departments trying to protect their workflows. Around leadership agendas and vendor relationships and that one person who “owns” the data model and doesn’t want anyone touching it.
We pretend technology is neutral. It’s not. Every field name, every approval step, every permission setting is the product of a decision, and decisions are never just technical.
Whose truth are we building around?
Commerce loves to talk about the single source of truth. It’s a nice phrase. It implies clarity and unity and tidy dashboards. But in practice, “truth” depends entirely on who you ask.
Marketing wants flexible data; they care about speed, tags, campaign structures. Operations want precision and control. Finance wants traceability. Each of those truths is valid, but when you try to fit them all into one structure, conflict is inevitable.
The result is usually compromise. The taxonomy that marketing hates but operations insists on. The SKU naming convention that no one understands anymore. The workflow approval step that exists purely because someone senior didn’t trust the last person who skipped it three years ago.
Systems aren’t just code and configuration. They’re a reflection of organisational memory; every argument, workaround, and power struggle encoded into logic.
Ownership is leverage
Ask who owns your ERP and you’ll learn more about your company culture than your systems architecture.
In some brands, the ERP lives with finance, and so every change is viewed through the lens of control and compliance. In others, it sits with operations, and data integrity is prized over flexibility. Increasingly, it lives in the void between them, with no single owner but several self-appointed guardians.
Ownership, in systems terms, equals influence. The person who controls the data model often controls the narrative. They decide which metrics are “trusted,” which definitions are official, which fields exist at all. They don’t have to fight for budget; they just decide how information flows.
When two teams share a system, power shifts constantly. Every permission request, every integration spec becomes a negotiation. That’s not bad, but pretending it isn’t happening makes the system weaker, not stronger.
Incentives shape architecture
If you want to understand why your systems behave the way they do, look at the incentives of the people building and using them.
Operations teams optimise for accuracy; they hate exceptions. Marketing teams optimise for agility; they live for exceptions. Finance optimises for reconciliation; they’ll take a slower process if it means clean reporting.
These competing incentives get baked into the architecture over time.
That’s how you end up with three ways of defining “product,” two different prices for the same SKU, or a daily Slack ritual dedicated to “manual syncs.”
And yet, when you zoom out, no one’s wrong. The system isn’t broken because someone made a mistake. It’s broken because everyone’s optimising for their own version of success.
The illusion of neutrality
We talk about system design like it’s an objective exercise; “what’s the best way to do X?”, as though there’s a perfect answer waiting to be discovered. But the truth is that every system encodes bias. Not in the AI sense, in the human sense.
A product hierarchy is political. So is a returns process. So is the decision to measure performance by sell-through rather than margin.
Technical neutrality is a myth. Every rule you codify privileges one behaviour over another. Every governance model defines who gets to speak, who approves, and who waits.
That’s why system design needs diplomacy as much as it needs logic.
The best system architects aren’t the most technical people in the room; they’re the ones who can map the power dynamics before drawing the workflows.
System maturity is cultural
A mature system isn’t one with the most automation, integrations, or dashboards. It’s one where everyone understands why it’s built the way it is, and who it’s built for.
Immature systems are full of ghosts: legacy rules no one remembers setting, processes no one dares to remove, data no one trusts. Mature systems are transparent. They document decisions, acknowledge trade-offs, and evolve through governance, not rebellion.
That maturity isn’t technical, it’s cultural. It requires a level of honesty most organisations avoid. You have to admit that systems reflect people’s egos, fears, and incentives as much as they reflect business logic.
Map power, not just processes
Every systems map tells a story about flow: where information goes, what triggers what, which teams touch which data. But the more useful map is the political one, who benefits, who resists, who decides.
Because once you understand the politics, the technology makes sense.
You stop trying to force objectivity and start building systems that work with your organisation’s reality, not against it.
Every system is political. You don’t remove that by pretending it isn’t true, you manage it by making the politics explicit.