The org chart is not the operating model

After 14 years and 20+ operational teams stood up, the single most useful framing shift I've made is the distinction between an org chart and an operating model. They look like the same thing on a slide. They are not. The confusion between them is why so many 7-figure businesses feel structurally broken even when nobody on the team is underperforming.

Here is the distinction, why it matters, and how to actually design your business's operating model independently of who you happen to have on the team right now.

What each one is

An org chart is a map of the people currently working in your business. It shows reporting relationships, titles, and who-reports-to-whom. It updates when people are hired, promoted, or leave. The org chart describes who you have.

An operating model is a map of the functions your business needs to run. It shows what work needs to happen, with what cadence, with what quality, with what handoffs between functions. It updates when the business strategy changes. The operating model describes what you need.

Most founders draw an org chart and call it an operating model. The problem: the org chart describes the people; the operating model describes the work. These can diverge significantly, and when they do, the business feels broken.

How the confusion shows up in practice

Three common patterns we see across 7-figure businesses.

Pattern 1: a function isn't anyone's job, but it's nobody's fault. Example: customer renewals. The CSM is doing customer success ("keeping them happy"), the sales team is doing new business, the finance team is processing the renewals when they come in. Renewals as a proactive function (60 days before renewal, work the account, drive the conversation) is in nobody's job description. Renewals slip. Nobody on the org chart is failing. The operating model has a gap.

Pattern 2: two people are partially doing the same function. Example: lead routing. The marketing automation tool routes some leads. The SDR manager routes others. There's no rule for which routes which. Some leads get routed twice. Some get missed. Both the marketing ops person and the SDR manager are doing the work they were hired to do. The operating model has overlap without explicit ownership.

Pattern 3: a function exists but the person owning it is the wrong fit. Example: a designer-turned-marketing-lead is owning the content ops function. They're a great designer. Content ops is operational discipline (publishing cadences, repurposing workflows, calendar management), not creative judgment. The function is owned but underperformed because the operating model needed a different skill profile.

In all three patterns, the org chart looks fine. The operating model is broken.

Why founders confuse the two

Three structural reasons.

Reason 1: org charts are easier to draw. Listing the people you have and connecting them with reporting lines takes 15 minutes. Designing an operating model takes weeks. So founders default to the easier exercise.

Reason 2: org changes feel concrete; operating-model changes feel abstract. Hiring or firing produces visible motion. Redesigning the operating model produces invisible motion (the work happens differently but the org chart looks the same). Founders prioritize visible work.

Reason 3: the operating model requires articulating what you actually want. This is the hard part. Most founders haven't fully articulated what every function needs to produce, on what cadence, with what handoffs. The operating model design forces that articulation. The articulation is uncomfortable because it surfaces assumptions that turn out to be unclear.

The org chart is a snapshot of who. The operating model is a map of what. Designing the second one requires more clarity than founders typically have, which is why most businesses default to the first.

How to design an operating model

The simplest exercise that works.

Step 1: list the functions, not the roles. Write down every function your business needs to run. Not the job titles you have. The functions. Examples: customer support, community management, content production, content distribution, lead routing, sales qualification, customer success, renewal management, data hygiene, financial reporting, recruiting, payroll, legal compliance, etc.

Don't worry about who does what yet. Just list the functions.

Step 2: for each function, define outputs and cadence. For each function, write 2-3 sentences:

• What does this function produce?
• How frequently does it produce it?
• What quality bar does it have to meet?

Example for content production: "Produces 1 newsletter per week (Tuesdays) at the brand's voice quality bar, plus 1 podcast episode per week (Thursdays) edited to our production standards, plus 3 YouTube videos per month."

Step 3: define handoffs. For each function, what does it depend on (inputs) and what does it feed (outputs)? Map the dependencies.

Example: content distribution depends on content production (its input). Content distribution feeds community engagement (its output).

Step 4: NOW assign owners. For each function, identify who owns it. The owner is one named person, not a team. The owner is accountable for the function's outputs hitting the cadence and quality bar.

If a function has no clear owner, that's a gap. If a function has multiple owners, that's an overlap.

Step 5: compare to the org chart. The operating model now exists independently of the org chart. Look at the org chart and ask: which functions are well-covered by current roles? Which have gaps? Which have overlaps?

Most founders discover 3-5 gaps and 1-2 overlaps in their first operating-model design. Fixing them produces dramatic operational improvements without changing headcount.

What changes when the operating model is explicit

Three changes happen.

Change 1: hiring becomes targeted. Instead of "we need to hire because we're stretched," you can say "we need to fill the gap in function X." Job descriptions become specific. Hiring decisions become evaluable against the function's needs.

Change 2: performance evaluation becomes legible. Instead of "is this person doing a good job," you can ask "is the function this person owns producing its expected outputs at its expected cadence and quality." The conversation becomes about outcomes, not vibes.

Change 3: business changes propagate cleanly. When the business strategy changes, the operating model gets updated first (which functions are still needed, which need to change, which new ones are needed). Then the org chart updates to fit. Without the operating model, business changes propagate as "we need to reorganize," which is usually messier than it has to be.

Where the Pod model fits

The Pod is one specific implementation of an operating-model-first approach. A PodFleet Pod is composed by function (customer support, community, content ops, data/admin, AI automation), not by who happens to be available. The POL designs the operating model for your business and then staffs the Pod to execute it.

This is why the Pod is a unit, not a team of individuals. The unit is defined by the functions it covers; the people are selected to execute those functions. If a specialist isn't the right fit, they get replaced in 10 business days without the function ownership changing.

For founders who don't want to design their own operating model from scratch, the Pod model includes the design work as part of the engagement.

The exercise to run this week

If you've never explicitly designed your operating model, run the 5-step exercise above. Block 2 hours. Don't try to make it perfect on the first pass.

What you'll discover:

• Functions that nobody owns (the gaps)
• Functions that overlap unclearly
• People doing work that doesn't fit their best skill profile
• Cadence assumptions that aren't actually being met

The discovery is uncomfortable. It's also the most productive 2 hours you'll spend on the business this quarter.