How Should I Structure My Team?

In the early days, you’ll be handling support, writing code, running marketing experiments, doing sales demos, and onboarding customers. You wear all the hats, which means you cannot focus on one role.

If you want your business to grow, you have to start peeling off some of those hats and giving them to other people.

But a challenge most founders face is, because you perform three (or ten) roles at once, you think you can hire people who can also handle many roles. It’s easy to dream of hiring someone who’s good at customer support, business development, and front-end design when you’re handling those tasks and none of them add up to a full-time position. But these three disciplines require specific skill sets unlikely to exist in a single person.

So how does one do that?

The good news is there aren’t that many departments in a SaaS company. The following is a list of the departments you’ll need (plus a likely first hire in each):

Product. Product is focused on what to build and how it should function. Your first hire in this area will likely be once you’re above $1 million ARR, with a title like Product Manager.

Remember that “Manager” at the end of a job title implies they manage a process, not people. “Manager” at the beginning of the title implies they manage people.

Design. Design works with product and engineering to help define how new features should look while also weighing in on how they should function from a user’s perspective. Your first hire here will likely be a UX Designer.

Engineering. Engineering is focused on writing code and managing production servers. Your first hire here will likely be some variation of a Software Engineer.

Marketing. Marketing is focused on generating and converting inbound leads. It usually includes marketing strategy (deciding which approaches to tackle), implementation, and business development.

Your first hire here will depend on your marketing funnel, but typically you start with individual contributors who have experience implementing one or two marketing approaches (e.g., SEO, content, PPC).

But eventually you will need to hand off marketing strategy and project management to a Manager/Director of Marketing.

Sales. Sales brings in qualified leads and closes deals. This role is divided into a Sales Development Representative (SDR) or Business Development Representative (BDR) who qualifies leads for an Account Executive (AE) to close the deals. Your first hire here will likely be an AE who qualifies and closes their own deals.

Customer Support. Support answers incoming support emails, chats, and phone calls. Your first hire here will likely be a Customer Support Representative.

Customer Success. Customer success focuses on getting customers to stick around; their goal is to help people get onboarded and not churn. Your first hire here will likely be a Customer Success Manager.

Human Resources. Human resources (HR; sometimes called People Ops) is focused on compliance, payroll, people ops, and organizational structure. Your first hire here will be a ways down the line but will likely be a combined Operations role that handles HR, Legal, and Finance. This role typically has a title like Operations Manager or Director of Operations.

Legal. Legal responsibilities are outsourced to an external lawyer, with the founder handling coordination until there’s enough budget to hire someone in an Operations role.

Finance. Usually outsourced to a bookkeeper and accountant, with everything beyond that handled by the founder (for now) until there’s enough budget to hire an Operations person.

Being a founder means firing yourself from one job after another to focus on the high-level strategic roles the company needs you to handle.

Before you can fire yourself, you have to hire someone to fill that role. To determine which role to fill next, track your time for a week or two (or you can list from memory) to compile a list of all the tasks you’re handling. As a founder, these will usually span many departments and many roles.

Then, using the list of departments I provided above, group your tasks into those departments (and if possible, individual roles).

Once you have that list, ask yourself:

• Which of these am I bad at and think someone else could do better?
• Which of these am I good at but don’t enjoy?
• Which of these could I stop doing that wouldn’t cause a negative impact?
• Which of these could I hand off to a current team member?
• Which of these, if leveled up, is most likely to grow the company?

In a perfect world, you’ll find that what the company needs most urgently is one of the things you’re not good at or don’t enjoy. When that doesn’t happen, you’ll have to decide which role to prioritize. It seems there is never enough money to hire for every role you’d like to.

As a general rule: support is usually an early hire because it’s a repetitive task of lower value than other things a founder is typically focused on.

Sales, marketing implementation, and development usually come next; which one depends on the skill sets of the founders. If you have two founders who are both engineers, you likely don’t want to hire an engineer. In that case, you’ll want to do some soul-searching to determine if one of you should dive deep into marketing or sales or hire for it. Hiring for a role a founder has never done can be quite challenging.

When you have roles that don’t require 40 hours a week, it can be enticing to want to combine two or three roles into a single hire. It’s hard to imagine hiring a full-time person to handle something you only spend 10 hours per week handling.

One reminder I have for you is that, as a founder, you are often more effective than the average hire. So realize something that takes you 10 hours per week might take them 20.

Second, as the founder, you are often not doing the best job handling certain tasks because you’re in a hurry as you task-switch from one to the next. Someone focused on a single role will do a more thorough job, requiring more time than you expect.

But unless you’ve raised a chunk of funding, when you only have 10 or 15 employees, you’ll want to look for generalists who can fill two roles at once. Eventually, you will hire specialists with specific domain expertise who fill a single role.

With that said, certain roles combine more easily because they require similar skill sets. If you are going to combine two roles into a single hire, here are some typical combinations that work:

Finding someone who is good at and wants to handle multiple roles will be more difficult than finding someone to fill just one role. But in the early days, you won’t have much of a choice.

As your team grows, you’ll start splitting these roles using the same principle of firing yourself from roles you’re not a good fit for. If your Customer Success Manager is great with your high-end customers, hire someone to take their support workload off their hands so they can focus on retaining your best customers.

When splitting roles, have your team member run through the task-tracking exercise described above to help determine which role you most need to hire for.

I used to make up job titles because, as a bootstrapper, I didn’t particularly care what someone’s title was. I didn’t want it to matter—but it really does.

When we realized we needed an architect to scale our infrastructure at Drip, we asked our internal recruiter to hire for the job of “Senior Scaling Architect.” She eventually talked us into the title of “Senior Architect.” Why? Because when she ran the data, she couldn’t find enough salary information on the title we’d given her. Not only that, but if we’d used a made-up job title, qualified candidates wouldn’t have known what we were hiring for.

There are standard SaaS job titles. Use them. Your ideal candidates have saved job searches for things like “Engineer,” “Customer Service Lead,” and, yes, “Senior Architect.” Ignoring that makes it harder to connect with people searching for the job you’re hiring for. It also does a disservice to whomever you end up hiring. They’ll have a much tougher time explaining their qualifications to their next employer when their job title was “Code Wizard” rather than “Senior Engineer.”

Although a treatise on organizational structure is beyond the scope of this book, here’s a typical hierarchy of engineering titles (in descending order of authority) that can be easily translated into other departments:

• Chief Technical Officer
• VP of Engineering
• Director of Engineering
• Manager of Engineering
• Senior Software Engineer
• Software Engineer
• Junior Software Engineer
• Entry-Level Software Engineer

Note: These titles assume the typical path is to move into management, which doesn’t have to be the case. Individual contributor titles above Senior exist, such as Principal Engineer and Distinguished Engineer. But for the sake of simplicity, I’m laying out the above hierarchy, which will work for companies well into the millions of ARR.

Another note on titles: be careful with handing out elevated job titles to early employees. One company I know named their first customer service person “Head of Customer Success.” When they inevitably grew and added more customer service people, they didn’t want him managing them and ended up in a tough situation. Should they demote him and have him leave? Or come up with an even more elevated title for the real manager?

SaaS founders generally come in three flavors: those with a software development background, those with a marketing or sales background, and those who are subject matter experts.

I just got done recommending you hire for the roles you don’t enjoy or aren’t good at. This is especially true if you’re a founder who’s great at sales or marketing. It’s a no-brainer to hire more technical help to free up your time to land more customers.

However, if you’re a founder who’s really good at the technical side of things, my advice is different. I recommend you focus on building skills in sales and marketing and start hiring developers to get yourself out of the nuts and bolts of the code.

There are two reasons for this.

First, developers are gonna develop. If your sole focus is on the product, you will want to solve every business problem by developing. Is your revenue plateauing? Are your churn numbers high? Are you not closing sales? The solution is to code more features . . . right?

Actually, building more features probably isn’t the answer to those problems. But if writing code is comfortable for you and marketing is not, you’ll have a natural tendency to over-build the product instead of getting to the real source of the problem.

Second, coding is deep work. You need to get into the Zen state of flow to have the right headspace. But looking up at the clock and saying, “Oh wow, it’s already 4 o’clock!” is antithetical to handling all the day-to-day marketing and sales tasks you need to do as a founder.

As a developer, you need to be on what Paul Graham calls a Maker’s Schedule, where you can take a whole afternoon to immerse yourself in work uninterrupted.

As a founder, you will absolutely be on a Manager’s Schedule, which cuts the day into one-hour increments you can fill with all those necessary meetings and other tasks.

Of course, you can ignore this advice. You’re in control; it’s your company. Just know that you will hamper growth if you keep the job of developer forever.

Ninety percent of bootstrapped SaaS companies have at least one technical founder, according to MicroConf’s State of Independent SaaS Survey. If you do not have a developer on your founding team, you are very much in the minority.

There’s a reason for this: building SaaS is both complex and expensive. Aside from marketing, sales, and support, you have to write code and maintain an always-on production environment. Developers who are good at SaaS are usually not cheap, and being able to tell the difference between someone who says they are good and someone who is actually good is close to impossible without knowing how to evaluate their code.

Having no developers on your founding team makes SaaS difficult to bootstrap. Most of the founders I see who attempt this either raise funding very early or run another business that throws off enough cash to allow them to hire a senior developer out of the gate. Whereas, if one of the founders was a developer, they would build the product during nights and weekends for no out-of-pocket cost.

If you have no technical founders and want to launch a SaaS, find a developer you can trust early and expect to pay them a lot. You will almost need to think of them as a cofounder because they will be making technical decisions that will have a major impact on your company’s future. If you don’t have the budget to do this, I encourage you to find a developer cofounder.

Craig Hewitt, the nontechnical founder of Castos, told me, “If I did it again, I’d very much want my first developer to be a cofounder or someone I know really, really well. I’ve wasted too much money while being misled by developers who are just looking to make a few bucks and don’t care about the outcome of the project.”

If you’re a lifestyle bootstrapper who’s happy without scaling, you may not be planning to hire. And that’s great, but I’d still challenge you to consider hiring at least a support person.

Why? Because for bootstrappers, a lack of money isn’t what kills businesses. It’s founder burnout.

Sure, you’re good at answering support emails—you know the product inside and out. Sure, it might not take much time out of your day. (Or does it? I bet it takes more time than you think.) But that doesn’t mean you’re the right person for this job.

One objection I hear repeatedly is, “My product is so technical, I’ll never be able to find a support person who can handle it.”

This is rarely true. It’s not that your product is too technical; it’s that you need to take the time to set up documentation, systems, and training. I’ve seen super technical products where people found a sharp junior developer who could provide amazing support. Eventually that junior developer will graduate to an actual developer in the company, and you can replace them.

In the long term, handling support will likely lead to burnout, and hiring a frontline support agent will free you up to keep doing the work you love.

You’ll hear a lot of people talking about how their company is all one big happy family, but I caution against that.

I do not refer to my fellow employees as family. I view us as a high-performing team (this sentiment was popularized by Netflix in an early culture document).

Calling your employees your family is disingenuous. It may give you warm fuzzies to say it, but you don’t fire your sister or uncle. You do bench a teammate if they’re no longer the best player for their position.

The team mindset allows healthy interpersonal relationships to develop and friendships to be built without putting your business at risk. Teams that are “families” become enmeshed and don’t maintain appropriate boundaries.

When you hire, be up front about your company culture: you’re a team, you support each other, and you work together for the success of the business. If a teammate isn’t performing, you need to be able to make the right decision for the company.

High-performing team members should be happy to hear it. We’ve all worked with people who aren’t as good as the rest and who, frankly, drag the rest of the team down. It sucks to constantly pick up the slack for someone who’s always dropping the ball, doesn’t get things done as fast as you do, or doesn’t care as much as you do.

If you hire and tolerate mediocre performance, you will lose your best people and create a culture of underperforming.

No one has ever said, “I fired that person too soon.” Normally the regret is that you waited too long to fire someone and they dragged morale down around them.