How to Scale Your Startup’s Engineering Org

Do all startups need a CTO? What makes a great first hire? Former Podz CTO Seye Ojumu weighs in.

Last Updated: December 10, 2021

Published: December 10, 2021


When I first met Seye Ojumu in early 2021, he was the chief technology officer of Podz. M13 had just invested in Podz’s seed round, enthralled by the potential for its innovative and transformative audio technology. As impressed as we were by this game-changing product, we were equally impressed by the leadership team. And so it was no surprise that within the year, Spotify had acquired the startup for its technology that highlights the best 60-second clips in podcasts.

An experienced technical founder and engineering leader (and now a senior manager leading a 12-person team at Spotify), Seye recently joined me to answer top questions from CTOs and engineering leaders at M13 portfolio companies about how to scale high-performing engineering teams at early-stage companies:

Does every startup actually need a CTO?

It depends on the stage of your startup. When it comes to the first engineering hire, most early-stage startups actually simply need a head of engineering, who is “a leader, pioneer, and a teacher,” Seye says. A head of engineering is typically responsible for:


Figuring out the motivations of the people being hired

Making sure that people work well together

In other words, a head of engineering is “basically responsible for the project management and people management of the engineering organization, while the responsibilities of a CTO are more about technology direction,” Seye says. “Frequently for small organizations, [a CTO is] going out to potential partners and explaining the technology in a way that gives people confidence and trust that they can work with or interact with your systems.”

So when is the right time for a CTO to join a startup? When your startup is ready to “to do more of this outward-facing stuff and the person who's been running the org [may not be] good at the outward-facing stuff,” Seye says.

What are traits that every engineering org should hire for?

Like every team, a good engineering org needs diverse skill sets. With startups, Seye makes it a point to hire:

Generalists: “The practical point is you don't know what your product is going to look like. You're probably going to have to pivot.”

Teacher archetypes: “A good mix of people who are comfortable and good at explaining things is important.”

Product-thinking people: “If you have an engineer who doesn't like the product you're making, I think you've done something wrong.”

How can startups compete for engineering talent anyway?

“Try to look for people who care about the product,” Seye says. “They will get some personal validation and satisfaction from making a product that people actually like to use.”

Startups get to be fun. There are other reasons to work somewhere other than how much they pay you or what your title is. You have advantages—you should use them.

How should engineering managers think about sprints and collaboration tools?

To begin with, managers must create a team based on “psychological safety—it's the belief that people can suggest ideas without feeling unsafe,” Seye says.

Continuous deployment is one way to “set the right mindset in the team members that their code would always be shippable. And in case you make a mistake—which you will certainly make—you find them as quickly as possible. The less mature the team, the smaller the sprint.”

The goal is to make sure that nobody gets stuck on a problem without asking for help.

Seye Ojumu

When it comes to collaborating, Seye’s teams have used everything from a “rolling Word document because that was the easiest thing to collaboratively write in” to JIRA and Trello. “Whatever tool that people will use is the right tool,” he adds.

What are some do’s and don’ts for scaling?


Admit when someone is not a great fit: “The biggest mistake I've seen with people who are getting off the ground is they've hired the wrong person. Sometimes you just have to get rid of people. It's hard and the morale will suffer, but in general it is better for the company as a whole.”


Don’t do performance improvement plans: “I’ve seen it work one time in the last 20 years of writing software at a small company.”


Encourage engineers to use, and provide product feedback: “Some people are just quiet, and they don't want to criticize the designer if they're not the designer or they don't want to disagree with the product person. And that is sometimes a problem because the product person is a lot of times the CEO, right? If you’ve hired people who are not naturally product people, make them into product people. Get them to care about the product, get them to use the product, get them to talk about the product.”

How should an engineering team’s structure evolve?

As a startup grows, managers usually have to decide how to split into two or more teams, Seye says. Whether it’s back-end versus front-end engineers or cross-functional teams dedicated to the creator versus consumption experience, “[t]he only the thing I would be most concerned about is people getting stuck on the wrong org or getting stuck on the boring org where they're working on stuff that is useful to the business but not personally interesting … It really depends on your people.”

Are you an engineer looking to grow your career? Check out job opportunities at M13 portfolio companies or email

m13 logo

For press inquiries, please contact

1920 Olympic Blvd.
Santa Monica, CA 90404

568 Broadway, Suite #405
New York, NY 10012

© 2021 M13