The E-Commerce Team: Who Actually Does What

As an e-commerce operation grows, the question stops being "do we have enough people" and becomes "does everyone know who owns what." The most common operational failure isn't too few hands; it's unclear ownership, where everyone assumes someone else is handling something and nobody actually is. An e-commerce team isn't a headcount, it's a map of ownership, and the failures happen in the gaps between roles, not inside them.

This is a core of the Operations, Scaling & Seasonality pillar, under the cornerstone about scaling without the chaos. That piece said the informal coordination breaks first when you scale. This one is about the most important form that coordination takes: who, unambiguously, owns each thing.

The real team problem isn't capacity

When something keeps going wrong, the reflexive diagnosis is "we need more people." Sometimes that's true. More often, the problem isn't capacity at all, it's ownership. Things fall through the cracks not because nobody had the time, but because nobody was clearly responsible, so everyone quietly assumed someone else had it.

This is the operational failure that hides best, because there's no overloaded person to point at, no obvious bottleneck. The work just didn't happen, and afterward everyone can honestly say they thought it was being handled. The gap between roles, not the workload inside any one role, is where operations most reliably fail. And you can't hire your way out of a gap; adding a person to an unclear structure just adds another person who isn't sure whether it's their job.

Why "everyone does a bit of everything" breaks

In a small team, shared everything works, it's the informal coordination the cornerstone described, and when there are only a few of you, it's genuinely efficient. But as you grow, "everyone owns it" curdles into "nobody owns it," and the things that suffer first are the important-but-not-urgent ones: the product-data hygiene, the broken automation nobody's watching, the slowly degrading page speed. Nobody's ignoring them out of laziness; they're just everybody's job, which means they're no one's, and the urgent always crowds out the merely important when responsibility is diffuse.

Diffuse responsibility is comfortable, no one has to feel solely accountable, and quietly corrosive, because the work that doesn't have a name attached is the work that doesn't get done until it becomes a fire.

A team is a map of ownership

Reframe the team away from headcount and toward ownership, and the structure becomes clear. Every e-commerce operation has a set of functions that each need a clear owner, someone whose job it is to notice when that thing is wrong:

• The catalogue and product data, the foundation everything else reads from.
• The orders and fulfilment, getting what was bought to the customer.
• The channels and marketing, where demand comes from.
• The data and analytics, knowing what's actually happening.
• The customer and service, the relationship and the support.
• The site and tech, the platform it all runs on.

Each of these needs an unambiguous owner. Not necessarily one person per function, that's a question of size, but each function needs a name attached, someone who would notice and feel responsible if it broke. The map matters more than the headcount.

The small-team reality: many hats, one head

Most e-commerce teams are small, and the realistic situation is one person wearing several hats, the same person owns the catalogue, the data, and the site. That's completely fine, and worth saying plainly, because the point here is not "hire a specialist for every function." The point is that each hat has a clear owner, even when one head wears five of them.

The failure mode isn't wearing many hats; it's hats that nobody is wearing because ownership was never actually assigned. "I sort of assumed you were keeping an eye on the product feed" is the sound of an unowned hat, and it happens just as easily in a three-person team as in a thirty-person one. So the discipline is independent of size: make the ownership explicit regardless of how many people you have. One person owning six functions consciously is robust. Six functions that everyone vaguely shares is fragile, no matter how many people are involved.

The gaps are where it actually fails

The classic operational fires almost all start in the gaps between roles, the places no single function clearly owns:

• The product-data error that's "marketing's problem, or maybe ops'," so neither fixes it.
• The broken automation that's "whoever built it," so nobody monitors it and it fails silently.
• The customer issue that spans service and fulfilment, where each waits for the other.

The fix isn't more people; it's naming the owner of the gap. Decide who owns the thing that lives between two roles, and the gap closes. Leave it unnamed and the gap owns you, because it's exactly where the next fire will start.

Ownership and SOPs, together

Clear ownership and documented process are the combination that actually scales, and they need each other. Ownership without documentation is still fragile, the function is hostage to the one person who owns it and knows how it works. Documentation without ownership still drifts, nobody maintains the SOP, and it rots into archaeology. Put them together, a named owner and a written process, and the function survives the owner being on holiday, being off sick, or leaving, because someone else can pick up the documented process. That pairing is what turns a person-dependent operation into a durable one.

As you grow, the natural move is to split hats off into dedicated roles, the person who owned catalogue-and-data-and-site hands off the site as the volume justifies a dedicated owner. Growth done well is progressively splitting hats into clear owners, not just adding generalists to a vague structure. Split by ownership, not by "we're busy, let's hire someone."

What this comes down to

An e-commerce team isn't a headcount; it's a map of who owns what. The failures happen in the gaps between roles, where everyone assumed someone else had it, which is why the work that actually scales a team isn't just hiring, it's making ownership explicit: every critical function with a clear, named owner, even when one person wears several hats. Pair that ownership with documented process and the operation survives people being away, leaving, and growing.

Add people without adding clarity and you just have more people in the same fog, more hands, the same unowned gaps, the same fires starting in the same places. Map the ownership first. Then, when you genuinely need more capacity, you'll know exactly which hat you're hiring someone to wear.

A few common questions

Is my operational problem really a staffing problem? Often it isn't. The reflexive diagnosis is "we need more people," but more often the problem is unclear ownership, things fall through the cracks not because nobody had time but because nobody was clearly responsible, so everyone assumed someone else had it. This failure hides well because there's no overloaded person to point at; the work just didn't happen. You can't hire your way out of a gap, adding a person to an unclear structure just adds someone else unsure whether it's their job. Fix the ownership first, then assess whether you actually need more capacity.

What does it mean to treat a team as "a map of ownership"? It means that instead of counting heads, you list the functions that each need a clear owner, the catalogue and product data, orders and fulfilment, channels and marketing, data and analytics, customer and service, and the site and tech, and make sure each has an unambiguous owner who'd notice and feel responsible if it broke. Not necessarily one person per function; the point is that every function has a name attached. The map of who owns what matters more than the headcount.

Is it a problem if one person wears many hats? No, that's the normal reality for small teams and it's completely fine. The point isn't to hire a specialist for every function; it's that each hat has a clear owner even when one head wears five. The failure mode isn't wearing many hats, it's hats nobody is wearing because ownership was never assigned, which happens just as easily in a three-person team as a thirty-person one. One person consciously owning six functions is robust; six functions everyone vaguely shares is fragile, regardless of headcount.

Where do most operational failures actually happen? In the gaps between roles, the places no single function clearly owns: the product-data error that's "marketing's or ops' problem" so neither fixes it, the broken automation that's "whoever built it" so nobody monitors it, the customer issue spanning service and fulfilment where each waits for the other. The fix isn't more people, it's naming the owner of the gap. And pairing clear ownership with a documented process is what lets the function survive the owner being away or leaving, since someone else can pick up the written process.