An org chart feels like corporate overhead when a business is three people, which is exactly why most scaling sellers skip building one until reporting lines and ownership are already tangled. Even a rough, one-page chart is worth building the moment a business has more than one non-founder employee, because its real purpose isn't the box-and-line diagram — it's forcing clarity on two questions that otherwise stay implicit and get answered inconsistently: who owns each function, and who does each person go to when something needs a decision.

Why a founder-flat structure breaks down

In the earliest stage, everyone reports to the founder and the founder is involved in every decision. This works fine at 2-3 people. It starts to break at around 4-6, for a predictable reason: the founder's attention becomes the bottleneck for every decision across every function, and the team spends more time waiting on the founder than executing. The symptoms are recognizable — decisions stall waiting for founder input, people are unsure who "owns" a gray-area task, and the founder feels like they can't step away even for a day without something breaking.

A simple functional structure for the first 5-15 people

Most ecommerce businesses at this stage organize around function rather than product line or channel, because the functions (fulfillment, customer service, marketing/advertising, catalog/listings, finance) are distinct enough in skill and daily rhythm to warrant separate ownership even before headcount justifies full departments:

  • Operations/Fulfillment — inventory, receiving, shipping, returns processing
  • Customer Experience — buyer messages, disputes, reviews management
  • Growth/Marketing — advertising, listing optimization, new-channel and promotional work
  • Finance/Admin — bookkeeping, reconciliation, tax filings, reporting
  • Founder — strategy, sourcing/supplier relationships, new-channel and new-category decisions, and (in the early stage) direct oversight of all four functions above

As the team grows, each function gets its own lead, and the founder's direct reports shrink from "everyone" to "the leads of each function." This is the point where the founder's role shifts from doing-and-managing to setting direction and reviewing outcomes.

What to actually put on the chart

A usable first org chart doesn't need software — a single page with boxes and reporting lines is enough. Include, for each role:

  • Title and the person's name (or "open" if not yet filled)
  • Who they report to
  • The 2-4 core responsibilities that define the role (not an exhaustive task list — the headline outcomes the role owns)
  • Who reports to them, if anyone

Ownership clarity matters more than the shape of the chart

The specific structure (functional vs. by channel vs. by product line) matters less than making one thing unambiguous for every task that recurs: exactly one person owns it. Shared ownership of a recurring task ("the whole team handles returns") reliably degrades into no one handling it promptly, because everyone assumes someone else has it. A simple RACI-style pass — for each recurring responsibility, who is Responsible, who is Accountable, who needs to be Consulted, who just needs to be Informed — is a useful exercise even without formally documenting it, especially for tasks that touch more than one function (e.g., a return that involves both customer service and inventory).

Common mistakes

  • Building the org chart around current people rather than around the functions the business needs. This produces a chart that has to be redrawn every time someone leaves, instead of a stable structure that a replacement simply slots into.
  • Too many direct reports for one manager. A rough rule of thumb many small teams use is that one manager can meaningfully support 5-8 direct reports before quality of oversight degrades; beyond that, an intermediate layer or lead role usually needs to be introduced.
  • Leaving cross-functional gray areas unassigned. Tasks that touch two functions (a damaged-item return that's part customer service, part inventory write-off) are exactly where "I thought that was their job" disputes happen if no one owns the handoff explicitly.
  • Not updating the chart as the business changes. A chart from a year ago that no longer matches who actually does what is worse than no chart, because new hires get onboarded against stale expectations.

Best practices

  • Revisit the chart at least twice a year, and any time headcount changes by more than one or two people or a new major function (a new marketplace, a new fulfillment model, international operations) is added.
  • Pair the chart with a one-line description of each role's core responsibilities — the chart shows structure, the description shows scope.
  • When a task keeps falling through the cracks, treat it as a signal the org chart has a gap, not just a training or communication issue with the specific person involved.
  • Keep the chart visible and referenced (not a document that gets built once and never opened again) — it's most useful as a living reference for "who do I ask about X," especially for new hires.

Checklist for building your first org chart

  • [ ] List every recurring function the business currently performs (not aspirational roles — what actually gets done today, even if one person does five of them)
  • [ ] Group functions into logical role clusters based on the shape of the team you have or are hiring toward
  • [ ] Assign exactly one owner to each function/cluster
  • [ ] Draw reporting lines — who reports to whom
  • [ ] Identify and explicitly assign ownership for cross-functional gray areas
  • [ ] Share the chart with the team and confirm everyone agrees on who owns what
  • [ ] Set a recurring reminder (e.g., every 6 months) to revisit it

FAQ

Do I need an org chart at just 2-3 people? Probably not a formal one, but it's worth being explicit about who owns what even at this size, since ambiguity compounds as you add people rather than resolving itself.

Should the org chart be organized by function, by marketplace/channel, or by product line? For most sellers under roughly 15-20 people, function-based structure is simpler to manage because it avoids duplicating fulfillment, customer service, and finance capability across channels or product lines. Channel- or category-based structures tend to make more sense at larger scale, or when different channels/categories genuinely require different skill sets to run well.