So, most people reading this aren't looking for the marketing section. But I wanted to point something out I see all the time. Take a look at the roles under CMO at a 125 person company:<p>--<p><i>CMO (15)</i><p>Director, Product Marketing, plus 3 PMMs (4)<p>Director, Demand Gen, plus 3 marketers (4)<p>Director, Sales Enablement, plus 2 marketers (3)<p>Director, Brand Marketing (3)<p>PR & Analyst Relations (1-2)<p>Events/Community (1)<p>--<p>What I posit is that Product Marketing is useless as a position and should be eliminated most of the time.<p>The role ends up being:
- Jane Doe is the Product Marketer for product X. She's responsible for growing it as much as possible.
- She works with Anne X. in demand gen to make ads to promote the product to new customers.
- She works with Hillary Y. in email marketing to cross promote to existing customers
- She works with tech to do landing page/funnel testing.<p>However what I find is that the role just adds friction and useless tests to show value. Let the subject matter experts (in demand gen, email, website testing) create the plan for each product holistically. Product Marketers are dead weight 80% of the time.<p>I would only say this anonymously but its true. Source: I'm a marketing consultant that has worked with dozens of fast growing SaaS companies.
This is a good rough outline. As the author says, it's not meant to be a perfect target that fits every company. Adjust accordingly.<p>I like how he limits the number of C-level titles in the early stages to just a CEO and CTO. It's a common mistake for startup founders to hand out too many C-level titles to their cofounders and early hires. This causes problems when the company outgrows some (or most) of those people. If you need to bring in a more experienced CMO, CRO, CSO, or other C-level, your only options are to demote the existing C-level and replace them with a new boss or to arrange their exit from the company. Neither are good looks, and neither make people happy.<p>Much better to start with Director and VP level titles in the early days. You can either bring in a C-level above them when the time is right, or promote them to C-level if they grow into the role.<p>That said, most SaaS I've worked with would want more people on backend/devops at the earl stages. Having 3 people total handle combined devops and backend development is a big risk, especially if any of them want to go on vacation or leave for other jobs. Downtime and server outages are not a good look for a growing SaaS, so don't skimp on people who can keep it up and running.
I know it’s close to the truth, but it still feels weird that this hypothetical 50 FTE SaaS company has 2x the amount of sales/CSM folks vs technical profile. And that the whole product is in the hands of 6 devs (4x FE and 2x BE).
Two remarks:<p>* This feels way too hierarchical for the size -- there's significant distance from many employees and the CEO even at small sizes.<p>* Could not disagree more with putting HR and Ops under the CFO (even in a 50-person company). That's a surefire way to have a neglected HR/people function.
Why do the number of front end devs exceed the back end? Does anyone else see a problem here? Front end effort has always been a fraction of back end effort on the systems I've developed. If that's not the case, I can only hypothesize it's because front end toolchains have gotten overly complex for what they accomplish. Not only that, but I would posit that for most SaaS ventures, the back end is where the differentiation and value is delivered, so that is where the bulk of dev resources should be deployed.
I’m not cut out for VC track businesses.<p>- $25K ARR per person with >40 employees.<p>- $50K ARR per person with >100 employees.<p>- $100K ARR per person with >1,000 employees.<p>There are plenty of independent SaaS businesses that make it past $200K ARR per person with teams of <10.
This is silly. Of course I understand that because of scaling a 50-person org will have one "technical leader" who is, by definition, the CTO, and they might only have 12 reports.<p>But you don't now need to introduce additional abstractions when you go from 50 to 125. Why introduce a VP of engineering? Can the CTO not handle 3 extra director reports (4 if you add a "director" of QA with 2 reports?) Come on. Who is going to come on to be the "VP of engineering" for a startup, yet not have/want oversight for Security, Analytics, and Infrastructure?<p>Also in the 50 person startup, the product lead with 5 reports is a "Director" but a product lead with 11 reports is a "VP"? Get outta here, this is silly. It's the exact same role. It is NOT more scope or oversight.<p>There should be orders of magnitude size growths before you start overthinking the difference between a director and a VP, or introducing new layers.
For those of us who want to start an indie one-person SaaS, this is sobering - because it means that for a while, you’ll be doing all 50 of these jobs. And, paid far less than any of them.
Interesting examples, but starting at 50 employees sounds a little bit extreme to me.<p>I also find way more insightful how you get from x founders to 50 employees than from then on.
The terminology around seed vs a vs b is so skewed right now, but a 50 person series a startup, just estimating, is a 5 mil per year burn. Hard to say exactly the raise, but personally I’d be uncomfortable with less than 3 years runway, so let’s call it a 12mil raise. 12 mil raise for 25% of the company (again, totally back of the napkin here) puts us at basically 50mil valuation. 50 mil valuation on 1mil ARR seems way high to me, basically this all seems sort of shifted left on the headcount side (series b should be 50 people) and right on the revenue side.
It's really interesting how AAR scales per employee. The larger you are, better the ratio -- this helps explain why large companies can afford to pay so much more for top-level employees than small ones.<p>I'm sure this seems obvious to some, but I'm not enough of a business/finance person to have really thought about this before. It helps crystallize some dynamics between, for example, my current employer and my immediately former employer; the former is able to pay dramatically more (around 150% on salary, plus equity) for essentially the same work, and gets more and higher quality talent as a result.<p>I wonder how a smaller org can escape this problem, if at all.
Series A feels top heavy to me. Having a director or VP of Product at that point feels like a mistake. I also think you could do more delegating under the CTO. 12 reports is too much.
Another way to think about this is ratios of budgets to departments, ratios of "core" vs "experimental" spend, and ratios of IC's to managers. If you map those constraints out for the system that you're building you can tailor things a little more to your business while making intelligent trade-offs.
Gem of an article. Question/opinion though:<p>The CEO seems to manage the CPO & CTO relationship in these models as well, which seems like a risk given a CEO's value is investor and market / key customer facing, and any time they spend on managing the peers in the CPO/CTO relationship is opportunity cost against that value.<p>It also means the CPO & CTO as peers will be jockying for the CEO's attention as a deciding factor, which seems like unnecessary friction. The CPO's key relationships are to the board and supporting the CEO activities and sales key accounts with strategic feature alignment that may include M&A.<p>The CTO's key relationships are outward with technology partners, suppliers, vendors, etc. and downward in the org. A CTO should be a partnership with a COO role, as they are solving scale and optimization problems together.<p>All that is to say, depending on org maturity, I don't think CTO/CPO should be peers under the CEO. IMO one of the CPO/CTO should report to the other, as otherwise you're going to get unproductive running battles between them that cost CEO time. If you have this model and are wondering why your staff aren't working well together, it's you.<p>This is why it can be useful to keep a founder around as a facilitator with convening power, provided they aren't too marginalized or a loose cannon. That said, I've only consulted to orgs like this and see it across them, and this is not the view of a CEO.
I always thought that in SAAS company at least 50% should be in the engineering, instead, out of 50, only 12 (25%) is in the engineering..<p>Not sure if this is the correct rule of thumb, but one day from Software Engineering I might want to move into management or have my own startup and this would help.
It scares me to think that there's some capital-backed, likely nervous 20-something, reading this on their iPhone with shaky hands before screenshotting it and shipping it off to Glassdoor. Your company should be so much more than this, even an example that you find online for guidance.<p>Cargo-cult leadership might be the demise of the modern SaaS/VC workflow.
These “blueprint” charts are so harmful.<p>People that doesn’t understand what some position even are trust this kind of things and hire a lot of people for the sake of it.<p>Measuring growth in headcount is disfunctional and just bad. I’ve seen many of startups hiring tens on engineers because they can, and to show “growth” to the outside world, not because they added any value
If anyone is interested in what a typical SaaS sales org chart looks like, here is a good example: <a href="https://www.saasae.com/levels" rel="nofollow">https://www.saasae.com/levels</a>
I know this guy has a track record but not sure why you’d only have 12 engineers and 5 PMs in a 50 person company. Do you really need the Finance stuff? Why not just engineering and sales?
Perhaps because I only work at companies where the data is the product but I have a hard time imagining a company without a Data Science Department reporting into the CEO
Understanding fully that this is meant to serve just as a reference, this type of article risks positioning hiring as an end — not as a means to an end.<p>Better to take external advice on typical team sizes / talent needed to achieve specific milestones specific to your business. Hire to get meaningful work done. Not based on a funding-centric "target" org chart.
very insightful, would like a version for before-round-A startups.<p>By the point when you got round-A, you have already passed the most difficult time for a startup: to survive from bootstrap or angel-fund to round-A.<p>the key is actually how to get angel-fund or bootstrap so you can reach to round-A, instead of being those 95% failed to launch ones and never saw the light.
Can some explain to me what 25-50+ engineers do all day at these startups?<p>My experience is probably skewed, mostly working for SaaS companies providing enterprise B2B software, but the product and engineering team represents only 15-20% of the headcount - the customer success team is often 2-3x larger.
I fully expected this to be satire. Surely this is all subject to change based on the backgrounds of founders and early employees, industry, funding goals and sources, etc.
A less than 1:4 ratio of tech positions, 2 backend developers on a supposedly 50-employee SaaS company is ridiculous and shows how startups burnout tech employees.
I think this is stupid. Building a business shouldn’t be about hiring people to fit some platonic form of a company.<p>You should hire people based on a market need for that role. While I agree that this is the org chart that most often organically arises, it’s not because CEOs read this article on sub stack.<p>This is about as useful of information as telling me how to decorate my office space when I have a 50 person company.
It's so funny when a CEO or a CTO or a VP has 20-50 people reporting to him/her :). This is barely getting outside of the "manager" rank in a proper corporation.