Introduction: The cost-centre trap
In most mid-market retail businesses, the technology function reports into operations or finance, is measured on cost and uptime, and is the last team consulted on strategic decisions. The CTO, if there is one, sits three levels below the CEO. Technology investment is approved line by line against specific projects, and the team is judged primarily by whether the systems stay running and the implementations land on time.
This operating model made sense twenty years ago, when retail technology was genuinely just operational plumbing. POS systems, back-office infrastructure, maybe an early e-commerce platform. The technology team kept the trains running. That was the job.
That world no longer exists. In 2025, technology underpins pricing decisions, customer acquisition, fulfilment economics, and loyalty. The businesses winning in retail are not winning because they have better buyers or better store layouts. They are winning because they have better data, better digital channels, and better integration between systems. Technology is not a supporting function in these businesses. It is a commercial capability.
This article makes a practical argument for a different operating model: one where technology is organised and funded as a product function, embedded in commercial decisions, and accountable for outcomes rather than uptime. The mechanics of how you actually make the shift are what matter here.
Why most retail businesses treat technology as a cost centre
The historical context
Retail technology functions evolved from IT departments. The lineage matters because it shapes everything: reporting lines, budgeting models, how technology leaders are recruited, and what success looks like. When the technology team’s job was managing POS systems and keeping the servers running, measuring them on cost and uptime was entirely sensible.
The problem is that this framing persisted long after the technology function’s role changed dramatically. Retailers added e-commerce platforms, digital marketing infrastructure, customer data platforms, and integration middleware. The complexity and commercial significance of the technology function grew enormously, but the operating model did not change. The team still reported into operations. The budget was still project-based. The CTO was still not in the room when commercial strategy was set.
The self-fulfilling prophecy
The cost-centre model creates a predictable cycle. Technology is perceived as overhead, so it is underfunded relative to its actual complexity and commercial importance. Underfunding leads to technical debt accumulation, delivery delays, and system instability. Poor outcomes reinforce the perception that technology is a cost and a source of risk, not a driver of value. The board and CEO lose confidence, constrain the budget further, and the cycle accelerates.
What makes this cycle so persistent is that it feels rational at every step. From the CFO’s perspective, the technology team is expensive, the systems are unreliable, and the business is not seeing the returns it was promised. The logical response is to constrain spend and demand better project outcomes. But the constraints are precisely what prevent the better outcomes. You cannot build commercial technology capability on a cost-centre budget.
The symptoms in practice
The cost-centre model has observable indicators. Technology leaders are absent from board meetings or appear only when there is a system issue to explain. Technology investment is approved project by project, with no persistent budget for platform improvement or product development. Engineering teams are measured on tickets closed and deployments made rather than on commercial outcomes. The backlog grows faster than it shrinks because there is no mechanism to say no to requests. And when commercial teams want to move quickly on a new initiative, they route around technology rather than through it, building shadow systems and accumulating debt outside anyone’s oversight.
The product-thinking shift
What product-oriented technology means in retail
A product-oriented technology function organises teams around business capabilities rather than around systems or projects. Instead of a “CRM team” that manages a platform, you have a “Customer Experience” team that owns the full customer lifecycle across channels, including the CRM, the loyalty platform, and the personalisation engine. Instead of a “Delivery and Integrations” team, you have a “Fulfilment” team that co-owns the economics of getting product to customers alongside the operations and supply chain functions.
These teams have a persistent roadmap, a defined domain they are accountable for, and commercial stakeholders they work alongside rather than receive tickets from. They are not support functions. They are co-owners of the business capability they serve.
From projects to products
The practical difference between project-based and product-based delivery matters more than the terminology. In a project model, technology teams are assembled for a defined initiative, a new platform, a feature build, an integration, and then disbanded or redeployed when the project ends. Knowledge walks out the door. The next project starts from scratch. The team never builds compounding expertise in a domain.
In a product model, the same team owns a capability over time. They understand the history of decisions, the technical debt they are carrying, the commercial context of what they are building, and the users who depend on their work. Continuous improvement becomes possible because the people doing the work understand the system deeply. Velocity increases over time rather than declining as complexity compounds.
Project-based models also create misaligned incentives. The incentive is to hit the go-live date, not to ensure the capability actually delivers value. Post-launch, nobody owns the outcome. Problems discovered after go-live become someone else’s project.
Technology as enabler, not support function
The core mindset shift is this: technology exists to create commercial advantage, not to keep the lights on. This sounds obvious stated plainly, but in most retail businesses the operating model contradicts it at every level.
In a product-oriented model, technology leaders contribute to commercial strategy from the beginning of planning cycles, not as an afterthought. Engineering teams proactively identify technical capabilities that could create commercial advantage, rather than waiting for requirements to arrive as tickets. Technical feasibility is a genuine input into business decisions. And when a commercial team wants to launch something new, the technology function is a strategic partner in figuring out what is possible and how to sequence it, not a bottleneck that slows things down.
What a modern retail tech operating model looks like
Organisational structure
For a mid-market retailer, the right structure is usually a small, senior technology leadership team alongside product-aligned squads with shared infrastructure. The leadership team needs a CTO or VP of Engineering who has commercial credibility, not just technical depth. Below that, leads for platform engineering, data and analytics, and delivery. These are strategic roles, not delivery managers.
The product-aligned squads sit at the intersection of technology and the business. A Customer squad that includes engineers, a product manager, and a commercial stakeholder. A Fulfilment squad with similar composition. A Merchandising and Pricing squad. The number of squads depends on scale, but the principle is consistent: each squad owns a domain end to end and is accountable for what happens in it.
A thin shared services layer handles infrastructure, security, and DevOps. These are genuinely shared utilities, not another team that everything funnels through.
Governance and prioritisation
Good technology governance in retail is lightweight, transparent, and commercially grounded. A technology investment committee with commercial representation meets quarterly to review the portfolio of work and make prioritisation decisions. The committee has a clear mandate: allocate technology investment across innovation, platform improvement, and risk reduction in a ratio that reflects the business’s strategic priorities.
Prioritisation uses a transparent framework that weighs commercial impact, strategic alignment, technical debt reduction, and risk. Every significant piece of work is justified in commercial terms. Not “this will improve system stability” but “this will reduce fulfilment error rate by X percent, which costs the business Y per quarter”. The commercial framing is not window dressing. It is how technology investment competes for capital on the same terms as any other part of the business.
Metrics that matter
The right scorecard for a retail technology function includes three categories. Commercial outcomes: revenue influenced by technology capabilities, conversion impact of digital improvements, operational efficiency gains from automation and integration. Delivery health: cycle time from idea to production, deployment frequency, the ratio of time spent on new capability versus maintenance. And platform health: technical debt ratio, incident frequency and severity, integration reliability.
Most retail technology teams measure only the third category, and only reactively. The shift to measuring commercial outcomes is what makes the function legible to the business and positions it for investment rather than cost reduction.
Embedding technology in commercial decision-making
The CTO at the leadership table
The technology leader must sit at the executive table with a direct line to the CEO. Not reporting into the COO or CFO. Not attending as a guest when there is a technology topic on the agenda. A permanent seat at the leadership table with a commercial mandate.
This structural change enables things that are impossible when the CTO sits outside the executive team. Earlier input on strategic decisions before commercial plans are locked and technology constraints become blockers. A technology perspective in M&A and partnership discussions. Real-time context on what is technically feasible when the business is evaluating new markets, channels, or product lines. And the ability to proactively raise technology risks before they become crises.
Joint planning and shared accountability
The “throw it over the wall” dynamic, where commercial teams define requirements and technology teams are expected to deliver them, is a symptom of the cost-centre model. In a product-oriented model, planning is joint.
Shared OKRs or KPIs that span commercial and technology teams prevent the dynamic where success means delivering the project on time regardless of whether it moves the business metric. A practical example: a merchandising team and the Merchandising squad planning a pricing capability investment together. The commercial team contributes the business case and the outcome definition. The technology team contributes the technical feasibility assessment and implementation approach. Both teams are accountable for the commercial outcome, not just their respective workstreams.
Commercial literacy for technology leaders
Technology leaders in retail need to understand margin, customer lifetime value, inventory economics, and channel profitability. Not at a superficial level. At the level where they can evaluate technology investment options against commercial trade-offs and make credible recommendations in a room full of commercial leaders.
This commercial literacy is what earns the seat at the table and sustains it. A technology leader who speaks in technical abstractions and implementation timelines will be perceived as a cost centre. A technology leader who can say “the reason we should build this capability before we replatform is that the contribution margin impact is X, and the replatform will reset our delivery capacity for 12 months” is speaking a language the business understands and respects.
Capability building vs outsourcing
What to own internally
Some capabilities must be built internally. Technology strategy, architecture decisions, vendor management, data ownership, and the core product management function are all strategic assets. These are the capabilities that determine whether the technology function creates commercial advantage or merely operates systems. Outsourcing them creates dependency on external parties who do not share accountability for business outcomes.
This does not require a large internal team. A small, senior team owning strategic direction, architecture, and vendor relationships can work effectively alongside external partners for execution. The scale of the internal team is less important than its seniority and commercial grounding.
What to outsource and how
Legitimate outsourcing use cases are well-defined. Implementation projects that require specialist skills the business does not need permanently. Managed services for commodity infrastructure where in-house operation provides no strategic advantage. Development capacity for peak demand, such as a major platform build that requires more engineering resource than the business maintains on an ongoing basis.
The key principle is to retain control of direction and quality. Outsourcing execution is fine. Outsourcing thinking is not. If the technology strategy lives in a partner’s slide deck, the business has a dependency, not a capability.
The partner dependency risk
The most dangerous outsourcing pattern is the one that starts sensibly and compounds over time. A retailer engages a systems integrator for a platform implementation. The project succeeds. The partner becomes the go-to for subsequent projects. Gradually, the partner accumulates deep knowledge of the business’s systems and architecture. Internal technology capability atrophies because the partner is doing the interesting work. The business is now dependent on a commercial relationship for knowledge it should own internally.
Breaking this dependency is expensive and disruptive. The better approach is to set boundaries from the start: clear internal ownership of architecture, explicit knowledge transfer requirements in every engagement, and deliberate capability building alongside partner delivery.
Making the transition: a practical roadmap
Start with the narrative
The first step is not restructuring. It is building the case for change in terms that resonate with the board and CEO. Technology leaders often make this argument in technology terms: “we need a product-oriented model because it produces better delivery outcomes”. The argument that lands is the commercial one: “our technology function is currently structured in a way that prevents us from using technology as a source of competitive advantage, and here is what that is costing us”.
Quantify the cost of the current model. Time lost to rework because technology was not consulted early. Revenue opportunities missed because technical constraints were discovered after commercial commitments were made. System instability costs, whether reputational or direct. The commercial framing makes the status quo a business problem, not a technology complaint.
Quick wins: embed before you restructure
Structural changes require executive sponsorship and take time. Before requesting a restructure, demonstrate the value of the different model with low-friction changes. Invite the CTO to board meetings and leadership planning sessions. Co-locate a technology lead with the commercial team for a planning cycle. Introduce outcome-based metrics for one significant initiative and report them alongside commercial metrics. Run one joint planning process with a commercial team and a technology squad. These create evidence that the model works, before asking for the organisational and budgeting changes to make it permanent.
The structural shift
Reorganising from a project-based to a product-based model takes 12 to 18 months to fully embed. The sequence: define product domains that map to business capabilities, assign clear ownership to each domain, shift from project-based to persistent product-based budgets, and build the governance framework that connects technology investment to commercial planning. Expect resistance from people who benefited from the old model, and from commercial leaders who are accustomed to treating technology as a service function rather than a strategic partner.
Conclusion: This is a leadership challenge, not a technology one
Every component of the operating model shift described in this article is a leadership challenge. Restructuring reporting lines requires CEO support. Changing budget models requires CFO engagement. Embedding technology in commercial decision-making requires commercial leaders who are willing to share accountability. And changing how the business perceives technology requires a sustained, consistent demonstration of commercial value that changes the evidence base over time.
Technology leaders who want to make this shift need to be honest about the fact that they cannot do it alone. The technical arguments are the easy part. The harder work is building the political and commercial case for change, finding executive sponsors, and demonstrating value in terms the organisation responds to. The operating model described here is not novel. The businesses that operate this way are winning in their markets. The question is whether your organisation is willing to do the hard work of getting there.
What to read next
If you found this useful, these related pieces go deeper on specific aspects:
- Standardising technology across a PE portfolio applies the operating model thinking to multi-company contexts where portfolio-level governance is also a consideration.
- What usually goes wrong in retail technology transformation covers the execution risks that emerge when the operating model is not aligned with the transformation ambition.
- What a Fractional CTO actually does explores one practical model for embedding senior technology leadership without the overhead of a full-time hire.
Next steps
If you are rethinking how technology is structured and led in your retail business, get in touch or review the services to understand how an advisory engagement might help.
What to read next
- What a fractional CTO actually does (and when you need one): The operating model shift described here often starts with bringing in senior technology leadership on a flexible basis.
- What usually goes wrong in retail technology transformation: Most retail transformation failures trace back to operating model problems, not technology choices.
- Standardising technology across a PE portfolio: where to start: How the product-led model scales across a portfolio context where standardisation is the goal.