The founding CTO of a $3 billion company explains why it's vital he still gets his hands dirty coding
- Eliot Horowitz is the founding CTO of MongoDB, which is currently valued at $3.2 billion after going public in October 2017.
- Horowitz has been in the position for a decade, and acknowledges it's unusual for the same CTO, who developed a product from scratch, to stick around once the company explodes.
- He says he now manages around 400 people, but still gets his hands dirty coding to understand both MongoDB's own developers and its customers.
- Other founding CTOs who are scaling up should stay close to their product so they can have intelligent conversations with their engineers, he says.
Eliot Horowitz acknowledges that he's an unusual breed: A founding CTO who has weathered going public, changing CEOs, and still manages to get his hands' dirty writing code.
Horowitz is the chief technology officer at MongoDB, the database company disrupting incumbents like Oracle and Microsoft and powers sites like eBay.
MongoDB went public in October 2017 with a $192 million float, and is currently worth $3.2 billion. By the end of the first day of trading, Horowitz's nearly 6% stake in the company was worth around $77 million.
There aren't many examples of founding CTOs who are still around at public tech firms. Snap is an exception, with cofounder Bobby Murphy still leading the engineering team.
Not only that, but MongoDB's other two cofounders have stepped back from day-to-day executive positions, with Kevin Ryan and ex-CEO Dwight Merriman both taking chairman roles. (Both men also cofounded Business Insider.) Current CEO Dev Ittycheria joined in 2014, and took the company public.
"It's on the more unusual side," Horowitz said of his long-held position in an interview with Business Insider.
A founding CTO is often the person building the product, alongside the CEO. They're the person setting the technical direction for the company, but they might also pick up a lot of odd jobs in the very early stages of the company.
Horowitz says he wouldn't do his job well if he didn't still code
A decade later, Horowitz is managing a team of around 400 people and, if he didn't want to, would probably never need to do any coding or programming.
"I still get my hands dirty," said Horowitz. "I don't think I could do my job well if I didn't get my hands dirty. One of the things about our engineering culture is that all of our engineering managers also get their hands dirty.
"To be an effective engineering manager you have to be able to have empathy both for the people on your team, the developers, and for your users. And for us, our users are developers."
Horowitz spends a lot of time using MongoDB's products on internal apps, he added, making sure he understands them and working directly with engineers on specific problems.
Asked why he's stuck around for ten years, Horowitz said developing MongoDB wasn't like building a one-off social media app and then dropping it into the world.
"It's not like 'Hey, I want to build this product, it's going to take three years, and now it's built and now the job's really changed,'" he said. "Mongo is all about building a great database and turning that to a data platform to make other developers get their job done. We want to help other companies, other teams build applications faster. And I'm not done... There's a lot more we can do."
Horowitz has one piece of advice for founder CTOs transitioning to become managers
In keeping with his ethos of maintaining his programming chops, Horowitz advises other founding CTOs not to lose sight of the product as the business scales up.
"Don't get too far separated from either the technology in your team and the users," he said. "You have product management, but a lot of the job of a CTO is being the person who can really connect with both the developer teams and the users at an executive level."
It's the CTO, he says, who can often see what needs to be done quickly on the technology side and marry that up to what users want.
"A lot of CTOs are great at staying close to their teams but are hands off on the product," he added. "I think that's a mistake. Staying close to the code, I would highly encourage that."