The Advisor Series – Featuring Mike Shaver

Staircase Ventures has an outstanding team of Advisors supporting our portfolio companies. In this blog series, we introduce you to each of our Advisors, share their stories, and highlight some of their insights and advice on building startups.

Introducing Mike Shaver!

Mike co-founded Mozilla and led the engineering and product teams for Mozilla Firefox. He then moved to Facebook where he was the Director of Engineering and managed Facebook’s transition from a web-focused product to a mobile-first product. After Facebook, Mike joined Real Ventures as a partner, investing in Seed and Series A startups. Most recently, Mike was a Distinguished Engineer at Shopify directing technical strategy.

Mike is an outstanding developer and an exceptional leader. In an interview with Robbie Marks, Mike talks about the early days at Mozilla, how he thinks about the advancement of AI, and his advice for hiring, scaling, and managing engineering teams.

What are some of your key takeaways from founding Mozilla?

When I think back to founding Mozilla, I’m surprised because what we did was basically impossible and never should have worked. And for a long time, it didn’t. Nobody knew how to do open source from a corporate background. Nobody knew how to monetize a browser. And our technology was not very good at the beginning. We were open source’s greatest failure in a lot of people’s eyes. Netscape had done this huge thing, and Mozilla still hadn’t even released a v1.

Then we released Firefox. And a lot of the early success was being ready to take advantage of a market opportunity. There was a point where Internet Explorer had so many security bugs and CERT (effectively, the computer security agency for the US) advised companies to stop using Internet Explorer. So, we were like, “Holy shit, this is our moment.” And so, we started to target much more of our advertising and marketing around what we were building around security and integrity and how that related to open source.

That experience showed me that startups need to take advantage of market opportunities when they’re there. Not only do you need to build a world-class product, but the market also needs to be ready for it.

The other thing I reflect on is that Mozilla was mission-driven and non-profit motivated, which is different from most startups. We were doing it because we wanted to see a world where this problem is solved.

When you think about the advancements of AI, where do you think the most value will be created?

In my view, there are two buckets of AI advancements. On the one hand, there are LLMs producing generative AI, which is getting a huge amount of attention, and on the other, there’s the use of AI to tackle problems that were previously intractable or inefficient to solve.

Machine learning and AI have had these big up-and-down cycles for a long time, and we’ll have these “AI winters”. Now we’ve got an “AI summer” in the LLM and generative AI space and it’s unintentionally created this “semi-winter” for the rest of AI. I never expected AI to displace AI. Right now, it feels to me like we’re in the early web days where we just didn’t really know what could be accomplished. I believe we still don’t really know what we can do with AI.

For GenAI, we have this new tool that we’ve unlocked for novel applications. We don’t fully know what it’s good at yet. So, we’re probably trying to use it in the wrong ways, and we’re going to look back one day and wonder “Why were we doing it that way?”  For example, there’s a huge field of research investigating whether the LLM is broken. It’s like you turned the light on in a room but you don’t know what’s creating the light. It might turn out that it’s actually a fire. Is that the best way to light a room?

The other category is startups using advancements in AI to solve problems in a fundamentally different way than we could have before. That’s what’s really interesting to me. I think it’s a huge opportunity space and a great time to be looking around and revisiting some of those problems we couldn’t previously crack.

Sometimes startups are too focused on building capabilities rather than solving a problem for a market. People like to build cool things, which is great, but they forget to consider whether it will solve a real problem for a large market. Take AI video generation, for example. I think it’s awesome, but it’s just a capability until applied in a specific, useful manner. I think the most value will be created using AI to solve real problems in a new way.

Do you have any advice for startups building in the AI space today?

I wouldn’t look at OpenAI or Meta as competitors. You’re (most likely) not building a frontier model. You’re not building Llama 7. Think of it like if you were building a web business; you wouldn’t see Shopify or your Internet Service Provider as a competitor, you see them as part of your supply chain.

However, be cautious when building something adjacent to a platform. Often the platform grows to encompass it. For example, when ChatGPT was first launched you couldn’t upload files. Many startups started building the capability for models to read and answer questions about a file. It was a matter of weeks before ChatGPT implemented this feature.

But I think most founders should look at these foundational models and think “Okay, they’re providing some capability. How do I use it? How do I create value?”

How should engineering leaders think about allocating software development resources?

Opportunity cost and well-defined outcomes are the two most important factors to consider when deciding to allocate engineering resources to develop new products. Too many people think of their engineering teams as a static cost base and they don’t see the opportunity cost of working on one project over another.

I see many startups get stuck in what we, at Netscape, used to call “chasing the cheque”. There would be some development tasks that needed to be completed to close a huge deal. In these circumstances, it’s important to focus on the outcomes of that development work. You need to evaluate whether it is something that gets you closer to your main objective or is something that’s not going to be valuable to your other customers.

I talk to a lot of engineering leaders about this, about how a lot of their job is to surface the actual cost of software to product and business owners to understand. It can be a lot more complex than one might think. For example, something could take 2 months and 3 engineers, and business leaders do the math in isolation, evaluating whether it’s worth it for that particular feature. But there’s more to it. Maybe it’s a new complexity the engineering team will have to manage forever. This complexity is very easy to underestimate.

It’s the understanding that you don’t always have to build the biggest, most complex piece of software to solve a particular problem. I always implore leaders to think about “Do we actually need this? Can we solve it in a simpler way? Can we solve the problem in a different area of the business where it might be easier or cheaper to maintain the solution?” At the end of the day, the goal is to profitably create value for your customers. Writing endless lines of code and creating overly complex systems is not always the best solution to a problem.

When hiring software engineers, what skills and qualities should founders look for in a candidate?

In my opinion, you should focus on flexibility and fungibility. If you think about it from a resource perspective, you want people who are eager to use their software skills wherever they can to solve the problem. You don’t want folks who are one-hit wonders and siloed in their thinking.  It’s not helpful to have a big data person who thinks the solution to every problem is a new big data pipeline.

Flexibility and fungibility are sometimes hard to interview for. A lot of the interviewing we do as an industry doesn’t actually tell you much about whether you’re going to want to solve hard problems with them or trust them to make good decisions with the resources of the company. I think we underweight the social skills and folks’ ability to communicate.

The job is not to figure out if they know how to do X or Y. It’s to use the interview time to learn more about their interests, how they think, what they can do, and what their limits are. These are the pieces of information that will help you determine whether you want this person on your team or not. 

When I conduct interviews, I like to ask candidates a series of questions about a particular project they worked on. Some of the questions I use are the following:

• What was the hardest thing to test?
• How could you have changed the project framing to make it more effective?
• If you could go back, what would you change?

I also like to ask people about their favourite JavaScript framework or networking library, for example. Then I’ll ask what they think is the worst thing about it. These questions help me see how critically they think about systems and truly understand if they have flexibility and are eager to create value.

When scaling engineering teams, what’s something that some might underestimate?

In fast-growing teams, it’s critical to bring on managers earlier than you think. There is so much communication and fast decision-making that you need somebody who’s going to stick up for the team and say, “Hey, this process sucks. We can’t keep doing this. We need to invest in X or Y.” You need an engineering manager who can communicate effectively with the rest of the leadership team.

I think there are a lot of companies out there that have 5+ engineers that all report to the CTO. And it’s not always the case that the CTO is a good manager. Sometimes they are, but often they are more focused on the tech. They might just have been the first engineer in the company.

Great managers are franchise players. They enable everybody to be better. They make the whole company use engineering better and support engineering better. With a great manager, you will discover what your engineering team is capable of doing.

What do you wish all founders knew about software development?

Software is expensive. Software estimation is really hard. Almost nobody is good at it. And to get good at it, you have to really invest in it. As a start-up, you likely don’t have the time or resources to invest in it. So, remember engineering estimates are just estimates, not deadlines.

Second, building more and more software is not necessarily a victory. People like to talk about how much software they’re producing or that they’ve built some huge complex thing. As a non-technical founder, you need to ensure that all the complexity pays for itself. It’s your job to think about the entire company and the business outcomes of any software development.

What do you enjoy most about advising startups?

I love being able to see the world through a really interesting and energetic new perspective. I love meeting founders who are enthralled in a problem, which often I have never heard about, and discovering that it is a valuable problem to solve.

Startup founders are such interesting people. They’ve made a really interesting decision. They juggle a lot of weird stuff. They are usually very open to learning and improving. They’re all about growth, getting better, and learning from mistakes. And it brings me so much joy to work with and advise such fascinating people.