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:
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:
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?
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 talent@m13.co.
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:
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:
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?
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 talent@m13.co.
Read more
The views expressed here are those of the individual M13 personnel quoted and are not the views of M13 Holdings Company, LLC (“M13”) or its affiliates.This content is for general informational purposes only and does not and is not intended to constitute legal, business, investment, tax or other advice. You should consult your own advisers as to those matters and should not act or refrain from acting on the basis of this content.This content is not directed to any investors or potential investors, is not an offer or solicitation and may not be used or relied upon in connection with any offer or solicitation with respect to any current or future M13 investment partnership.Past performance is not indicative of future results. Unless otherwise noted, this content is intended to be current only as of the date indicated. Any projections, estimates, forecasts, targets, prospects, and/or opinions expressed in these materials are subject to change without notice and may differ or be contrary to opinions expressed by others.Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in funds managed by M13, and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results. A list of investments made by funds managed by M13 is available at m13.co/portfolio.