Org Charts for SaaS Companies: From First Hire to 300 People

If you’ve worked at a SaaS company past 50 people, you’ve lived this: the org restructures every six months. The structure that worked at 40 simply could not work at 90.

SaaS companies have a structural problem that most industries never face. Growth is nonlinear. You might double headcount in a year. You ship product continuously, so teams need to reorganize around new priorities every quarter. Remote and hybrid are standard. And the engineering culture that attracted your first ten employees actively resists the hierarchy that your hundredth employee desperately needs.

So your org chart is either outdated, nonexistent, or actively misleading. And the people inside the company pay the price.

What follows walks through each stage of SaaS growth, from the founding team through 300 people. Patterns drawn from how real SaaS companies structure and restructure as they scale.

Why SaaS Companies Are Different

SaaS organizational structure is distinct in ways that matter for how you build your org chart.

Continuous delivery changes how teams work. A manufacturing company ships a product, then maintains it. A SaaS company ships every day (or every hour). Teams need to be structured for ongoing collaboration. The squad model exists because waterfall departments cannot keep up with continuous deployment. And because engineering is typically the largest department (40-60 people out of 100 might be in engineering and product), the reporting structures and communication patterns are shaped by that ratio.

Remote-first has become standard. The 2024 Flex Index report found that 79% of tech companies are fully flexible, requiring no office time at all. Your org chart needs to work for people who may never share a physical office.

On top of that, SaaS companies often resist titles and hierarchy longer than other industries. The reasoning is understandable: the early team was productive precisely because it was small and informal. But the same informality that worked at 15 becomes a liability at 50, when three people independently believe they own the same decision and nobody wants to be the person who “introduces hierarchy.” That gap between informal reality and the structure people actually need is what creates organizational debt.

A template designed for a 100-person law firm will not work for a 100-person SaaS company, even if the headcount is identical. What follows is specific to SaaS.

Stage 1: Pre-Product-Market Fit (5-15 People)

Skip the org chart. A shared Google Doc with everyone’s name and what they are working on is enough. The only structural investment worth making at this size: a decision log. Write down who makes final calls on product, hiring, architecture, and customer-facing messaging. This prevents the single biggest early-stage dysfunction: everything escalating to the CEO because nobody knows who owns a decision. Resist creating VP titles or drawing org charts with seven departments for a team of ten.

Stage 2: Post-Product-Market Fit (15-50 People)

You have paying customers. Revenue is growing. Hiring accelerates. For the first time, someone joins the company and does not personally know the founders.

Most SaaS companies should create their first real org chart at this stage. Not because process demands it, but because new hires need a way to understand the organization they just joined. When the answer to “how do I learn who does what?” shifts from “just ask anyone” to “I have no idea,” you have waited too long.

The structure that works

The specifics vary, but what matters is that every person has one clear manager and every function has one clear owner. Typically this means three levels (founders, team leads, ICs) and four to six functional groups (Engineering, Product, Sales, Customer Success, Operations). Hire your first People Ops person somewhere between 30 and 50 people. The signal that you are late: new hires consistently report confusion about the company structure, or the CEO spends more than two hours a week on people operations tasks.

The flat-structure reckoning

Somewhere in this range, the flat structure ideology collides with reality.

At 20 people, flat works because you can resolve ambiguity with a five-minute conversation. At 45, that conversation takes three days and involves six people. Three people think they own the same decision. New hires spend weeks figuring out the invisible hierarchy that exists despite the company insisting it does not. Senior engineers who are de facto team leads burn out because they have management responsibility without the title, authority, or compensation.

You don’t need to impose corporate hierarchy overnight. You need to name what already exists. If Sarah is already making architectural decisions for the backend team, make her the engineering lead. If Marcus is already onboarding every new salesperson, make him the sales manager. Formalizing reality is not the same as creating bureaucracy.

Practical org chart advice for this stage

Keep it simple. A clear tree with three levels. Every person appears exactly once. No dotted lines yet. Update it when someone joins or leaves, which at this growth rate means weekly.

A CSV import from your HR spreadsheet is the fastest way to set this up and keep it current. You probably already have employee data in a spreadsheet. Turn that into a visual org chart and make it accessible to everyone.

Stage 3: Scaling (50-150 People)

The 50-to-150 range is where SaaS org structure gets complex. Engineering alone might have 30-60 people. You are probably hiring across multiple time zones. The product has grown enough to need distinct teams working on different areas simultaneously. And this is where two competing models emerge: the traditional functional hierarchy and the squad/pod model.

Traditional functional hierarchy

Departments with clear reporting lines. Engineering, Product, Design, Sales, Marketing, Customer Success, Operations, each with a VP or Director. Sub-teams within departments (Backend, Frontend, Infrastructure, QA within Engineering). Individual contributors report to team leads who report to directors who report to the CEO or COO.

This works well when: you have clear separation between what teams build, customer-facing and internal teams need different cadences, you want predictable career paths, your product is relatively monolithic.

The squad/pod model

The squad model organizes people into cross-functional teams of 6-10 aligned to a product area or customer outcome. A typical squad: one PM, one designer, two to four engineers, sometimes a data analyst or QA.

Squads own a slice of the product end-to-end. They decide what to build, how to build it, and how to measure success. They are self-contained enough to ship independently.

This works well when: your product is modular enough for independent teams, you want speed over coordination, you trust teams to make good local decisions, your engineering culture values autonomy.

In practice: most SaaS companies use a hybrid

Pure squad models are rare. What works at 80-120 people is a reporting hierarchy (engineers report to engineering managers, designers report to a design lead) with a squad overlay for daily work. People have a “home” department for career development, performance reviews, and skill growth. They have a squad for their day-to-day work context.

What this actually looks like at 90 people: Three product squads of 7-8 (each with a PM, designer, and 4-5 engineers), a platform/infrastructure team of 5, two engineering managers overseeing the squads, a Head of Engineering, and the rest split across Sales (10), Customer Success (8), Marketing (6), People Ops (3), and Finance (2). The engineers report to the two engineering managers on the org chart, but they spend their days working inside their squad with the PM and designer who report to entirely different people.

Here’s the org chart challenge that creates. The reporting structure says one thing. The working structure says another. Both relationships matter. Only showing one makes the chart incomplete.

Trying to capture everything with dotted lines and matrix arrows does not work. What does: multiple views of the same organizational data. A reporting view for HR and management. A squad view for understanding who works on what. A skills view for finding expertise.

The product trio and how it changes structure

At this stage, most successful SaaS companies adopt some version of the “product trio” pattern: a PM, a designer, and a tech lead making decisions together for each product area. Marty Cagan’s work at the Silicon Valley Product Group popularized this approach, and for good reason. It works.

But the product trio does not fit neatly into a functional org chart. The PM reports to the VP of Product. The designer reports to the Head of Design. The tech lead reports to an engineering manager. They sit in three different branches of the tree, yet they make decisions as a unit every day.

This is a visibility problem, not a structural one. The reporting lines are correct. What is missing is a way for the rest of the company to see that these three people operate as a team. This is especially critical at this stage because other employees need to know: “If I have a question about the billing experience, who do I talk to?” The answer is the billing product trio, but that group is invisible on a traditional org chart.

When to restructure (and how to know you are late)

SaaS companies at this stage tend to restructure frequently, often every 4-6 months. New product areas spin up. Teams that were one squad become two. An acquisition adds a whole new group. The pace of change means your org chart is a living document or it is fiction.

Signs you need to restructure:

• Two teams keep stepping on each other’s work
• A squad has grown past 10 people and can no longer make decisions quickly
• Engineers spend more time coordinating across teams than building
• New hires take more than two weeks to understand the team structure
• Nobody can explain why a particular team exists anymore

The restructure itself is management work. Making the new structure visible to the whole company is what the org chart is for. And if employees cannot find each other after a reorg, the reorg has not landed, no matter how smart the new structure is on paper.

Stage 4: Growth (150-300 People)

Past 150 people, informal networks can’t cover the org anymore (we break down the stage-by-stage structural shifts separately). The org chart shifts from “helpful reference” to “critical infrastructure.”

At this size, a SaaS company typically has:

• 4-5 management layers (CEO, VP/Director, Senior Manager, Manager, IC)
• 8-12 distinct teams within engineering alone
• Multiple product lines or customer segments with dedicated teams
• Shared platform teams (infrastructure, developer experience, data) that serve other teams internally
• Specialized support functions (People Ops, Legal, Finance, Revenue Operations) that were one-person jobs at 50 people

The engineering org chart deserves special attention

In a 250-person SaaS company, engineering might be 100-120 people, essentially a company within a company. The internal structure of the engineering org directly affects shipping velocity, code quality, and engineer retention.

Two models dominate at this scale:

Feature teams aligned to product areas. Each team owns a vertical slice: one product surface, frontend through backend through data. Teams are independent and can ship without coordinating. Works well for companies with distinct product modules (think a platform with separate billing, messaging, analytics, and admin surfaces).

Platform + product teams. A core platform team builds shared infrastructure (APIs, auth, payments, data pipelines). Product teams build on top of the platform. The platform team does not ship customer-facing features directly; they enable other teams to ship faster. This model works when multiple product teams depend on the same underlying systems.

Neither model is universally better. The right choice depends on how your product is architected and how much shared infrastructure exists. But both models require the org chart to show dependencies between teams alongside reporting lines.

The remote-first reality at scale

At 200 people across multiple time zones, the physical office (if one exists) contains a minority of the team. Decisions cannot wait for everyone to be online simultaneously. Documentation, async communication, and organizational visibility become load-bearing infrastructure.

For the org chart specifically, remote-first at scale means:

Location needs to be visible at this scale. When someone in your Paris office needs to schedule a meeting with the billing squad, they need to know that two squad members are in San Francisco and one is in Singapore. Time zone awareness is not optional.

In a co-located company, you absorb organizational context by being present. You overhear who is working with whom. You notice when teams move desks. Remote employees get none of that ambient information. The org chart is their primary way to understand how the company is organized. If it is stale or incomplete, they are navigating blind. Making the org a browsable, searchable directory matters more than making it a pretty diagram.

Onboarding compounds this. A remote new hire’s first week is largely spent figuring out who is who and which team does what. An accurate, searchable org chart cuts days off onboarding time. Building real remote culture requires infrastructure that persists between events.

The shared services challenge

At 200+ people, you have teams that serve the whole company: People Ops, IT, Finance, Legal, Revenue Operations. These teams do not fit neatly into a product-aligned org chart. They work across all product lines and business units.

A common mistake is hiding shared services at the bottom of the chart (implying they are less important) or creating a confusing web of dotted lines to every team they support. Neither helps anyone navigate the organization.

What works: show shared services as their own branch with clear internal structure, and make it possible to find shared services people by function or expertise rather than only by navigating the tree. If a new PM needs to understand the company’s data privacy policies, she should be able to search “data privacy” and find the right person in Legal, without knowing the Legal team exists or where it sits in the hierarchy.

Squads vs. Hierarchy: A Practical Assessment

A lot of SaaS content treats the squad model as categorically superior to traditional hierarchy. It is not. Both have failure modes, and the right choice depends on your specific context.

When squads work

Squads excel when teams can ship independently, going from idea to production without coordinating with three other teams. They also work better when product complexity is horizontal (many independent features) rather than vertical (one deeply interconnected system). Companies that do squads well share a few traits: strong engineering practices, a culture of ownership, enough senior engineers to lead each squad, and a product architecture that supports independent deployment.

When squads fail

Squads fail when teams cannot actually operate independently. If every feature touches the same database schema, the same API layer, and the same deployment pipeline, autonomous squads create coordination chaos. Five squads making independent decisions about shared infrastructure produce five incompatible approaches.

They also create a career development problem. If an engineer’s world is a 7-person squad led by a PM, who mentors them technically? Who evaluates their growth? Without a functional “home” in addition to the squad, engineers lose access to technical mentorship and career guidance.

The practical middle ground

In practice, most SaaS companies land somewhere between the two: functional reporting lines for career development and technical standards, cross-functional squads for daily work. Both structures coexist, and the org chart needs to show both.

When to Formalize: A Decision Framework

One of the hardest calls for SaaS leaders is timing. Formalize too early and you create overhead that slows down a team that needs speed. Formalize too late and you get confusion, duplicated work, and frustrated employees who cannot figure out how decisions get made.

Rather than picking an arbitrary headcount, look for these signals:

• Formalize team leads when the same person is consistently the tiebreaker in a group. They already have the authority; the title makes it visible to everyone else.
• Create departments when you have three or more people doing the same type of work, and they need a shared manager for prioritization, performance feedback, and career development.
• Build a real org chart when new hires can no longer learn the org structure in their first week through conversations alone. Usually around 15-20 people.
• Adopt multiple views when cross-functional teams (squads, pods, tiger teams) coexist with functional reporting lines. Usually around 50-80 people.
• Invest in searchable profiles with skills when you overhear someone say “I didn’t know we had someone who could do that.” Usually around 60-100 people.
• Hire dedicated People Ops when the CEO or a manager is spending more than five hours a week on people logistics. Usually around 30-50 people.

Treat Your Org Chart Like a Product

SaaS people understand the concept of building for users. Apply the same thinking to your org chart. Your “users” are employees trying to figure out who does what, new hires trying to understand the company, managers trying to see their team’s structure, and executives trying to make decisions about organizational design.

If you would not ship a product with a three-month-old interface that nobody can search, do not accept that for your org chart either. The structure of your company is a product. Treat it like one. Keep it current, make it useful, and let the people inside it see how it all fits together.