Org & Roles

In every business conversation about who decides what, the answer depends on titles, functions, and reporting lines you might not yet have a working model of. Who actually owns the call when the CMO and the CRO disagree? What does a Director do that a Manager doesn't? Who's the "business owner" when engineering is asking for one? When the press release says the CIO resigned, what does that say about the company's priorities?

This guide builds the working model. By the end, you should be able to read an org chart, follow a leadership reshuffle in a press release, and roughly understand the function map of any company without translating each title into its full job description.

It is not a guide to climbing the ladder. It is a guide to navigating the ladder that already exists — which, for a business operator working cross-functionally, is most of what makes meetings make sense.

We'll move in six steps. The C-suite, role by role. The management layer between the C-suite and the line. Functions vs operations as a way to read an org. RACI and the question of who's actually accountable. Span of control and how reporting structure shapes decisions. And the cross-functional patterns — pods, squads, matrix orgs — that overlay the formal hierarchy.

§1 The C-suite, role by role Foundational

The C-suite is the executive layer reporting directly (or near-directly) to the CEO. Every C-title is "Chief X Officer" — Chief Executive, Chief Financial, Chief Technology, and so on. The shape of the C-suite tells you what the company prioritizes and where decisions actually get made.

CEO — Chief Executive Officer. The top of the org. Owns the overall strategy, capital allocation, and accountability to the board (and shareholders, if public). In smaller companies, the CEO often also runs day-to-day operations. In larger companies, day-to-day operations split off to a COO or sit inside functional leaders. The CEO is the one who answers to investors for the whole company.

CFO — Chief Financial Officer. Owns the financial machinery — accounting, financial planning, treasury (cash and debt management), investor relations, often legal and compliance in smaller orgs. The CFO is the second-most-important executive in most public companies because the CEO can't credibly tell the company's financial story without them. When a CFO resigns suddenly, markets read it as a signal that something is wrong with the numbers — sometimes correctly, sometimes overreaction.

COO — Chief Operating Officer. Owns execution of the company's operations end-to-end. The role is the most variable of any C-suite title — at one company the COO runs everything except finance and engineering; at another the COO doesn't exist because the CEO covers that scope. When the COO is strong, the CEO is freer to focus on strategy and external relationships. When the COO seat is empty, look at whether the CEO is doing both jobs or whether functional leaders are running themselves.

CTO — Chief Technology Officer and CIO — Chief Information Officer. Two roles that confuse outsiders because the boundary varies. Working model: CTO usually owns product engineering — the technology that IS the product. CIO usually owns internal technology — the systems the company runs on. A SaaS company's CTO leads the team building the SaaS product; the CIO (if there is one) runs the internal IT stack, vendor systems, employee tooling. At a bank, the CTO often owns the customer-facing platform engineering; the CIO owns the internal infrastructure that processes transactions. Many smaller companies have only one of the two roles.

CMO — Chief Marketing Officer. Owns brand, demand generation, communications. The CMO is the role with the shortest median tenure in the C-suite (typically 2-3 years) because the role's success is hard to measure cleanly and budget gets cut first in downturns.

CRO — Chief Revenue Officer. Owns sales and (often) customer success — everything that drives revenue from prospects through retention. The CRO role grew popular in the 2010s as a way to consolidate sales + marketing + customer success under one accountable revenue executive. In some companies CRO = head of sales; in others CRO = head of revenue including marketing (which means the CMO reports to the CRO). Read the org chart, not the title alone.

CDO — Chief Data Officer. Owns data strategy, governance, and often the analytics function. The role exists most prominently in regulated industries (banking, insurance, healthcare) where data governance has compliance teeth, and at companies where data IS the product (ad platforms, marketplaces). At many smaller companies, the CDO function lives inside the CTO's org or doesn't have a C-title.

CISO — Chief Information Security Officer. Owns information security and is increasingly required by regulators, customers, and insurers. The CISO sometimes reports to the CIO/CTO, sometimes to the CEO, sometimes to legal — and where they report tells you whether the company treats security as a technical issue, a governance issue, or a legal liability issue.

CHRO — Chief Human Resources Officer (also Chief People Officer at startups). Owns hiring, comp, performance, employee experience. The CHRO becomes critical at scale (above ~500 people); below that, the function often reports to the COO or CEO directly.

The shape of the C-suite is itself a signal. A company with a CISO reporting to the CEO is signaling security matters. A company with the CRO above the CMO is signaling growth-go-to-market urgency. A company with no COO and a CEO doing everything is either a startup or has a strategic gap that will show up in execution.

A diagram of a representative full C-suite with reporting lines makes the shape concrete.

Related glossary: CEO, CFO, COO, CTO, CIO, CMO, CRO, CDO, CISO, CHRO.

§2 The management layer — VP, Director, Manager Foundational

Below the C-suite, the hierarchy gets denser. The standard rungs, in descending order: VP (Vice President), Director, Manager, Senior Individual Contributor, Individual Contributor. The titles look universal; what they mean varies by company size and industry.

VP — Vice President. At larger companies, VPs lead a major function or business unit reporting to the C-suite. A "VP of Engineering" owns engineering reporting to the CTO. A "VP of Sales" owns sales reporting to the CRO. At startups, VP titles get used earlier — a 30-person company might have a "VP of Engineering" who would be a Senior Engineering Manager at a 5,000-person company. Title inflation is real and increases as companies compete for talent. Read the title against company size before reading the title against responsibility.

Director. A layer between VP and Manager. At larger companies, Directors own a sub-function or a large team — "Director of Backend Engineering," "Director of Field Sales (Northeast)." At startups, Directors might be IC-leaning leaders without a large team below them. The Director title in 2026 is the most-stretched in the hierarchy — it's used to recognize seniority for ICs who don't manage, to compensate for the lack of a VP slot for someone who deserves promotion, and as a defensible title for cross-company moves.

Manager. Owns a team of ICs (typically 5-10 direct reports), runs the people-management work (1:1s, performance reviews, hiring, terminations), and is accountable for the team's output. Managers are the most common layer in any company because most ICs eventually report up to one.

Senior IC vs IC. The non-management track. At engineering-heavy companies, the senior IC track runs parallel to the management track — Staff Engineer, Principal Engineer, Distinguished Engineer — with compensation matching Director / VP / SVP levels. The dual-track structure exists because forcing strong ICs into management is a common way to lose them. Outside of engineering, the IC track is shorter at most companies; senior individual contributors hit a comp ceiling and either move to management or change companies.

Two patterns worth holding. First, the same title at two companies is not the same job. A "VP of Product" at a 50-person startup and at a 50,000-person enterprise are running different scopes by orders of magnitude. The shorthand for evaluating: how many people report up to the role (the "span"), and what budget does the role control. Title alone is decorative; span and budget are the real measure of scope.

Second, promotions in the management track usually mean both more people and more strategic ownership. A Manager → Director promotion typically means going from 5-10 directs to 20-50 in a sub-org, plus owning the sub-function's strategy. A Director → VP promotion typically means going from a sub-function to a full function with cross-org responsibilities. When someone gets promoted without taking on more people or strategy, it's usually a comp adjustment dressed as a promotion.

A diagram showing the hierarchy with typical reporting spans by level helps the layers land visually.

Related glossary: VP, Director, Manager, individual contributor, span of control.

§3 Functions vs operations — how to read an org Foundational

A useful frame for any org chart: separate functions (what disciplines exist in the company) from operations (how work flows across those disciplines to deliver something to a customer). Functions are the org's organs; operations are its circulation.

Functions are the disciplines: engineering, product, design, sales, marketing, customer success, finance, legal, HR, IT, security, operations (as a function, see below), data, often a separate strategy or business development arm. Functions report up to a functional leader (VP of Engineering, VP of Sales, etc.) who reports to a C-suite role. Functional org structure groups people by skill — all engineers in one tree, all designers in another.

Operations in this frame are how the functions cooperate. A new product feature requires engineering to build, design to design, product to specify, security to review, marketing to position, sales to learn, and customer success to support. Each of those functions does its piece. The operational question is how the handoffs work — who calls whom, what artifacts move between teams, how decisions cross functional boundaries.

The word "operations" also gets used as a separate function (as in COO or "Sales Operations" or "Revenue Operations" or "People Operations"). In that usage, operations as a function = the discipline of making other functions work. Sales Operations sets the rules of how the sales team runs (territory assignments, comp plans, pipeline reporting). Revenue Operations sits across sales, marketing, and customer success doing the same. Operations as a function is glue work, infrastructure work, and process work — quiet, unsexy, and load-bearing. Companies that under-invest in operations-as-function tend to feel chaotic; companies that over-invest in it tend to feel slow.

Two practical reads on any org chart:

First, count the functions reporting directly to the CEO. A CEO with 12 direct reports across 12 functions is doing the COO's job by hand and usually struggling. A CEO with 5-7 direct reports (the C-suite + maybe 1-2 special-project executives) has delegated the operational layer. Companies often grow from the first state into the second by hiring a COO or by promoting a Senior VP into the operational glue role.

Second, look for the missing function. A 200-person company without a head of People is signaling either "we're not done growing into the structure" or "we treat HR as overhead." A SaaS company without a head of Customer Success is signaling either "we don't retain customers, we just sell more new ones" or "CS reports to Sales (under the CRO) and isn't visible at the top level." The absence of a function in the C-suite tells you what the company is choosing not to prioritize.

A diagram showing a representative org with functions clearly labeled, and a separate overlay showing how a single feature-delivery operation flows across functions, makes the function-vs-operations split visible.

Related glossary: function, operations, COO, revenue operations.

§4 RACI and the question of who's accountable Building

The hardest question in any cross-functional project isn't "what should we do?" — it's "who decides, and who's accountable when it goes wrong?" The standard framework for answering it is RACI (sometimes DACI, RAPID, or other variants — all variations on the same idea).

R = Responsible. Who does the work. Multiple people can be R. A = Accountable. Who answers for the outcome. There must be exactly one A. C = Consulted. Who provides input before the decision is made. Multiple people, two-way conversation. I = Informed. Who needs to know after the decision is made. Multiple people, one-way notification.

The most common failure mode in cross-functional work is having multiple people who think they're A (the meeting turns into a debate that doesn't resolve), no one who's A (the decision sits unmade), or having the wrong person as A (decision gets made by someone without the context or authority). RACI's discipline is that "Accountable" gets exactly one name, and that name is the person whose job is on the line for the outcome.

A common pitfall: confusing Responsible and Accountable. The engineer who writes the code is R. The engineering manager who owns the team's output is often A. The two are different people, and the project plan should name both. When the project ships late, the manager doesn't get to point at the engineer — the engineer did the work; the manager owned the outcome. When the project ships well, both get credit but the manager is who the org thanks because the manager is who would have answered for the failure.

A practical pattern in 2026: most healthy cross-functional projects name the A role explicitly at kickoff and write it down. ("Sarah is A on launch readiness; Mike is A on infrastructure stability; Priya is A on customer comms.") When the project hits a snag, the A's are who lead the response. When no A is named, the snag turns into a circular meeting about whose job this is.

DACI is the variant that swaps in "Driver" for Responsible and adds "D" as the project owner (the person making sure the decision happens). RAPID rearranges further. The acronyms vary; the underlying discipline is the same — name the person whose name goes on the outcome, and don't let it be a committee.

The org-design lens: RACI works only if the org gives the A enough authority to be accountable. Naming someone A for a decision they don't have the budget, headcount, or political authority to execute is setting them up to fail. When you see an A that doesn't match a real authority, that's usually a sign that the leadership wants accountability without giving up control — and the project will get stuck.

A diagram showing a sample RACI matrix for a real cross-functional project (e.g., launching a new product feature) makes the discipline concrete.

Related glossary: RACI, DACI, accountability.

§5 Span of control + reporting structure Building

Span of control is the number of people who report directly to a single manager. Reporting structure is the shape of the tree as a whole — how flat or how deep, where decisions concentrate, where information flows.

The typical span of control patterns:

• Narrow span (3-6 reports per manager). Common in highly technical or judgment-heavy work — research labs, senior engineering teams, executive teams. Allows deep manager attention per direct report; produces deep hierarchies (many layers between CEO and IC).
• Wide span (10-20 reports per manager). Common in operations-heavy work — call centers, retail stores, field sales teams. Manager attention per direct report is thinner; relies on standard processes. Produces flat hierarchies (few layers).
• Typical knowledge-work span (5-9 reports per manager). The default for engineering, product, marketing, and similar disciplines. Balances manager bandwidth with hierarchy depth.

Two consequences of span fall out:

Deep hierarchies are slow but informed. Information from the bottom passes through many layers before reaching decision-makers, but each layer can filter, contextualize, and aggregate. Slow to react; tends to maintain organizational knowledge well.

Flat hierarchies are fast but coarse. Information reaches the top quickly but loses context. Managers have less time per report, so the org relies on each individual being self-directed. Fast to react; tends to lose organizational memory because there are fewer "middle layers" to retain it.

Where the hierarchy puts decisions matters as much as how deep it is. A company can be deep on paper but have decisions concentrated at the top (all calls bubble up to the CEO) — fast-feeling for the CEO, slow-feeling for everyone else. A company can be flat but distribute decisions widely (every team lead has real authority) — fast-feeling everywhere.

The signal in any specific org: where do decisions actually get made? If the CEO is in every product decision, the company is centralized regardless of the org chart. If team leads are sending architecture decisions to a committee that meets monthly, the company is centralized regardless of the org chart. The chart is the wiring; the actual decision flow is the current.

In recent years (2018-2026), many tech companies pushed toward flatter structures — Spotify-style squads, the "two-pizza team" pattern at Amazon (teams small enough to feed with two pizzas), holacracy experiments. Most reverted toward more standard structures as they scaled. The lesson the survivors drew: extreme flatness scales worse than expected once a company exceeds ~150 people (Dunbar's number territory) because cross-team coordination starts to require explicit hierarchy.

A diagram contrasting a deep narrow-span hierarchy with a flat wide-span hierarchy, showing how the same 100 people get organized differently, helps the trade-off land.

Related glossary: span of control, hierarchy, reporting structure, Dunbar's number.

§6 Cross-functional patterns — pods, squads, matrix Building

The formal org chart describes the functional hierarchy (who reports to whom for performance, comp, hiring). Cross-functional patterns describe how people from different functions get assembled into working units that ship things to customers. Both exist simultaneously. Understanding the overlay is the difference between thinking the org is "broken" and seeing how the cross-functional structure actually operates.

Pods / squads / cross-functional teams. A small group (typically 5-12 people) from multiple functions assigned to a shared mission. A growth pod might include 2 engineers, 1 designer, 1 product manager, 1 data analyst, and 1 marketer. They report functionally to their respective managers (the engineers to engineering, the PM to product, etc.) but work day-to-day with the pod. The pod has a mission ("improve onboarding conversion"), some autonomy on tactics, and a measurable outcome. Spotify popularized "squads" as the name; the underlying pattern has been around for decades.

Matrix organizations. Each person has two reporting lines — one functional ("you report to the VP of Engineering for your discipline") and one project or business-unit ("you report to the General Manager of the consumer line for your work output"). Matrix structures make sense in companies where multiple business lines need shared expertise (consulting firms, large enterprises with multiple product lines). They produce constant tension because the two managers want different things from the same person. Done well, matrix structures balance scarce expertise across business needs; done poorly, they produce burned-out people pulled three directions.

Project teams. Temporary assemblies for a specific deliverable — a launch team, a migration team, a crisis-response team. Disbands when the project ships. Different from a pod (which is persistent) in time horizon.

Centers of excellence. A central team in a discipline that supports work distributed across the org. A "data center of excellence" sets standards, owns tooling, and consults to embedded analytics work happening inside business units. Common at scale; common compromise when a company can't decide whether a function should be central or embedded.

The general design problem all these patterns address: most real work crosses functional boundaries, but performance management mostly happens within functions. An engineer's manager evaluates the engineer's engineering output; the engineer's day-to-day work happens in a cross-functional pod where the manager isn't watching closely. Cross-functional patterns try to bridge this — the pod is where the work happens; the function is where the career happens. Companies that manage the bridge well let people do meaningful cross-functional work without their careers stalling.

Two signals to read in any org's cross-functional pattern:

How much of an IC's time is spent in their function vs in cross-functional work? A pod-heavy org might put an IC 80% in the pod and 20% in functional rituals (1:1s, hiring, discipline-specific work). A functional-heavy org reverses that. Neither is wrong; the balance signals where the org is putting its execution weight.

Where does the cross-functional work get prioritized? If a pod's roadmap competes with each functional manager's roadmap, and the functional managers win the resourcing fights, the pod is theater. If the pod's roadmap wins, the org is genuinely cross-functional. Watch resource allocation, not org-chart diagrams.

A diagram showing how a single person — say, an engineer — sits in both the functional org and a pod simultaneously, with their reporting lines and time allocation, makes the dual-membership pattern click.

Related glossary: pod, squad, matrix organization, center of excellence, cross-functional.

§7 Org design philosophy — principles behind the chart Strategic

Every org chart is a theory. It embeds assumptions about how work gets done, where knowledge lives, and what tradeoffs the company is willing to make. Understanding why an org is shaped the way it is — not just how it looks — is the difference between reading a chart and understanding a company.

The three classical structures are functional, divisional, and matrix. A functional org groups everyone by discipline: all engineers together, all marketers together, all salespeople together. It produces deep expertise and clean economies of scale (one sales team, one sales process, one set of tools) but creates thick walls between functions. Coordination is expensive — a product decision requires buy-in from Engineering, Design, Marketing, and Finance, each of which has its own priorities and calendar. A divisional org instead groups people by business unit, product line, or geography, with each division containing its own functions. A division can move fast because it owns all the pieces — but it duplicates effort and diverges on tooling, processes, and culture. Matrix orgs layer both, asking people to report to a functional manager while working day-to-day for a product or project owner. The matrix attempts to get depth and speed simultaneously; the cost is that everyone has two bosses, and the ambiguity about authority is real and persistent.

One of the most useful lenses for org design is Conway's Law, articulated by Melvin Conway in 1967: organizations produce systems that mirror their own communication structure. If the database team and the frontend team don't talk, you'll get a hard wall between data and interface in the product. If security is a separate group that reviews work at the end, you'll get security bolted on rather than built in. This isn't a failure of individuals — it's structural. The implication is that if you want your product or system to work a certain way, you need to shape the org that builds it accordingly. Teams that own the whole customer journey build more coherent journeys than teams that each own a vertical slice. The org is the product's blueprint.

The other core tension in org design is coordination cost versus duplication cost. Centralizing a function (one HR team, one legal team, one data platform) eliminates duplication but creates a bottleneck — every business unit queues up for the same shared resource. Decentralizing gives each unit autonomy and speed but duplicates tooling, process, and overhead. Neither is wrong. The right answer depends on how much scale you have (small companies can't afford to duplicate), how specialized the work is (highly specialized functions rarely get decentralized), and how dependent the function is on local context (customer success usually benefits from being close to the product; payroll rarely does). Most real orgs are a portfolio of centralized and decentralized functions, tuned differently for each domain.

Related glossary: org design, Conway's Law, functional organization, divisional organization, matrix organization, span of control.

§8 How company stage shapes structure Strategic

Org structure isn't chosen in a vacuum — it emerges from company stage. The same design that works at 10 people becomes dysfunctional at 100 and irrelevant at 1,000. One of the most common org failures is applying the structure of the previous stage to the current one, usually because the people who built it are still running it.

At the founding stage (roughly 1–20 people), there is effectively no structure. Everyone does everything. The CEO writes code or sells deals. The first designer also does content. Roles are fluid and the coordination mechanism is proximity — you can see everyone, hear every conversation, and course-correct in real time. This works at small scale because the overhead of formal structure would consume more bandwidth than it saves. The informal operating model is: hire people you trust, give them a problem, get out of the way. The failure mode at this stage is hiring too fast before the product is clear, which produces coordination chaos without the benefit of scale.

The inflection point most companies feel around Series A (20–60 people, roughly) is when informal coordination breaks down. You can no longer hear every conversation. Decisions start falling through the cracks. Context that used to be shared implicitly has to be written down. The right response is to add the first layer of functional management — a head of Engineering, a head of Sales, a head of Design — not to add bureaucracy, but to create explicit owners for each domain who are accountable for that function's output. This is also when many founders experience what's sometimes called the "letting go" moment: transitioning from being hands-on in every decision to setting direction and managing the managers. Founders who resist this transition become bottlenecks. Those who over-delegate before building trust get surprised.

By Series B and C (80–300+ people), functional depth is non-negotiable. The Engineering function alone needs sub-leads for frontend, backend, infrastructure, and security. Product may be split by product line. Finance needs a controller-level operator, not just a CFO. The org develops real hierarchical layers — director, VP, C-suite — each of which manages a larger span of indirect reports. At this stage the danger is premature complexity: adding management layers because headcount demands it, without checking whether the coordination those layers add is worth the decision-making overhead they create. A useful test: if a mid-level manager removed their layer, would information actually flow faster? If yes, the layer is adding friction, not value.

Related glossary: span of control, management layer, Series A, individual contributor, center of excellence, functional organization.

§9 Remote and distributed team design Strategic

Distributed work isn't just co-located work with video calls substituted for conference rooms. It requires rethinking the fundamental operating model — how decisions get made, how information flows, how trust is built, and how work is coordinated when you can't rely on hallway conversations or a shared office clock.

The core distinction is between async-first and sync-heavy cultures. A sync-heavy culture assumes that the default mode of coordination is real-time communication — a meeting to align, a Slack thread that expects replies within minutes, a decision that waits for the daily standup. This works when everyone shares time zones and work hours. It breaks down the moment the team spans more than a few hours of time-zone difference, because someone is always waiting. An async-first culture flips the default: decisions are made in writing, context is documented rather than communicated in real time, and synchronous meetings are reserved for work that genuinely benefits from simultaneous presence (creative problem-solving, sensitive feedback, onboarding new members). The result is that meetings become rarer but more intentional, and the documentation system becomes the actual operating infrastructure of the org.

The most important operating principle for distributed teams is what might be called documentation as the org chart. In a co-located team, institutional knowledge lives in people's heads and gets shared through proximity. In a distributed team, knowledge that isn't written down effectively doesn't exist for anyone outside the team that generated it. This forces a discipline that co-located teams rarely develop: writing decisions and their reasoning explicitly, maintaining structured runbooks for recurring processes, keeping project context in shared documents rather than Slack DMs. Teams that get this right find it creates a side benefit — when a co-located team member leaves, their knowledge walks out the door; when a distributed team member leaves, the documentation stays.

Time-zone spread has a specific and quantifiable effect on meeting feasibility. Teams that overlap 4+ hours can maintain some synchronous rhythm — a morning standup, a planning session that hits both teams' working day. Teams spanning 8+ hours struggle to find a single window that works without someone extending their workday, which erodes over time into resentment or exclusion. The practical resolution for wide-span distributed teams isn't to find the "right" meeting time — it's to redesign coordination so it doesn't depend on synchronous presence. Code reviews happen asynchronously. Architectural decisions get made in written proposals with a comment window. Approvals move via tickets, not rooms.

San Francisco UTC −8 9am–6pm local

New York UTC −5 9am–6pm local

London UTC +0 9am–6pm local

Bangalore UTC +5:30 9am–6pm local