The 109th episode of Datacast is my conversation with Nnamdi Iregbulem, a Partner at Lightspeed Venture Partners. His mission is to increase total software output by supporting entrepreneurs building technical tools for technical people. He focuses on investments in technical enterprise software such as developer tools, application infrastructure, and machine learning.

Our wide-ranging conversation touches on his interest in technology as a teenager; his undergraduate experience at Yale; his transition from investment banking to venture capital; his time studying at Stanford Business School; his current journey at Lightspeed Ventures; tactical strategies on scaling Developer Relations; his theses on the developer productivity manifesto and real-time data infrastructure; his obsession with the fat-tailed nature of startups; and much more.

Please enjoy my conversation with Nnamdi!

Listen to the show on (1) Spotify, (2) Apple Podcasts, (3) Google Podcasts, (4) iHeartRadio, (5) RadioPublic, (6) TuneIn, and (7) Stitcher

Key Takeaways

Here are the highlights from my conversation with Nnamdi:

On His Upbringing

I am the firstborn son of two Nigerian immigrants. In that situation, all the hopes and dreams of the family tend to be poured into you. Especially for the cohort of Nigerians that left Nigeria to go to other countries, education is super important. As a career profession, medicine is the thing to do. For most of my young life, I thought of (or at least told people) that I would be a doctor. But in the back of my mind, I was constantly questioning that assumption - whether or not it was the best thing for me. Some of my tinkering and exploration with technology as a young kid was my attempt to find alternative ways of living my life.

I fell in love with technology via tinkering with websites. I learned how to build WordPress sites, modify video games, and build desktop computers to play those games. I parlayed these tinkering and coding activities with entrepreneurship. I have always been very independent and felt that, in the grand scheme of things, I would work for myself (in real talk). That is where the gaming of Google Search came in. I would write websites around certain topics that I knew were high-paying keywords within Google Adwords - where I could recommend products and earn a commission via affiliated marketing.

So I built these websites about topics I knew nothing about, like foreign exchange trading, dog training, and cheap hardwood flooring. I would get these checks in the mail from Google, and my parents would wonder why Google was sending me money (which was kind of funny). But I knew it was important for me to experiment with these alternative means of building in life, and that was the spark for many things that have come since then.

On His Undergraduate Experience at Yale University

I was not sure that I was going to like Yale. I had actually wanted to go to Stanford, which had been my dream school for undergrad. Long story short, I got into both schools, but I was offered a better financial aid package at Yale - which was important to my family. My Nigerian parents felt that Yale was Ivy League and Stanford technically was not, so Yale clearly had a leg up, and I ended up going there.

I had never spent any time on the East Coast of the US (I grew up in Los Angeles) but ended up being surprised. Yale was a great community with a great social scene. I developed a lot as a person and got lucky with whom I got paired up in terms of roommates. I studied Economics because I knew I did not necessarily want to work as a software engineer. This was around the time when we just came out of the financial crisis, so Economics felt like the best way to explore that topic. Economics also was the most obviously employable degree.

In these elite schools, you ended up being pulled into consulting and investment banking - mainly because you do not really know any better. I interned at McKinsey and JP Morgan and spent a year post-graduation at JP Morgan. A valuable lesson I learned is that no one will look out for you more than you. Do not assume that, just because you work with somebody, they will be your best pal and have your best interests in mind. When you show up for an internship, they know nothing about you other than that you got through the interview process. You have to step up and show your worth for their trust. I took some learnings from my McKinsey internship, crushed my JP Morgan internship, got the full-time offer, and was off to the races.

On The Decline of Investment Banking

My biggest learning at JP Morgan was watching the decline of the investment banking industry. The jobs post-financial crisis were very different from the jobs pre-financial crisis. People's viewpoints were backdated to a different era, which played out in different ways - from a compensation standpoint to a retention standpoint. These banks tended to think that they were offering a super prestigious job that everyone in the world would want. But with the rise of technology, you started seeing a ton of analysts leaving their programs for tech companies in Silicon Valley. These banks had to reform their strategies for retention and hiring to counteract the tech threat. Investment banks earn fees for their transactions, which were constantly under pressure to be undercut. There was the race to the bottom.

It was my first taste of seeing that some industry has changed over time, and they will not be as sexy as their past reputation. Just because some boomer tells you something does not mean it is true. I have had to repeat this in many other instances too.

For folks who want to transition into technology, it comes down to having a sincere interest in tech for its own sake, as opposed to treating it like another prestigious thing. People in tech are allergic to that notion and can smell it from a mile away - if you are just another finance person or consultant trying to break into tech. At the same time, the skillsets of finance and consulting are highly valued in tech. There are not that many places where you can learn those skills. Realize that advantage, but know that thousands of other people like you want to break into tech. Showing true passion for the product or the company that you are interested in can really help in that department.

On Transitioning Into Venture Capital at ICONIQ Capital

ICONIQ Capital reached out to me for an investing opportunity. I knew I wanted to make the jump to tech investing and being in the Bay Area. It made much sense from those perspectives. In addition, as I was looking to make that transition, one question came up: What is the best stage to get involved in? In investing, people typically think of the split between the early and growth stages. Today, I am an early-stage investor, but at ICONIQ, I was more of a growth-stage investor. The companies had revenue and had been in a scaling mode. I thought that was a nice entry point to tech investing from a banking background because there is actual data and numbers to look at. I could be value-additive in that way. Versus at the time, I felt like early-stage was this mystical thing. I did not know how I would be valuable when the company was just two people with a PowerPoint presentation until I had more knowledge and expertise.

Learning to be a good investor in the first place was an accomplishment. Coming out of investment banking, I learned quickly that I did not know what I was talking about. All the corporate finance skills came in handy in terms of doing analysis. However, how to think about what makes a good company versus a not-so-good company and a good investment versus a not-so-good investment were relatively new concepts to me, so I had a pretty steep learning curve in my first year there. Getting over that curve was a big personal accomplishment.

Another accomplishment was finding my product-market fit among technical founders and technical companies. I had always been a self-taught programmer fascinated by tools that make developers' lives easier. I was one of the few people on the team who had that disposition and pushed them to invest more in these areas - developer tools, open-source, data infrastructure, data analytics, etc. I developed expertise around those topics, which culminated in investments like GitLab, Alteryx, and Fastly.

Speaking of those investments, I would highlight GitLab, which I had chased for many years while I was at ICONIQ. I had initially met Sid, the CEO, over Google Hangouts virtually. The company is fully remote. I was not sure by the end of it whether he liked me. But we developed a relationship over time, and I continued to stay close to the company - given its impressive product velocity and growth. Two years after I first met him, that culminated in an eventual investment that we led.

On Getting an MBA from Stanford GSB

I was so excited to go to Stanford GSB because I wanted to be at the center of technology and innovation in Silicon Valley. Similar to what I mentioned about finance people trying to break into tech and the words of differentiating yourself with passion, I wanted not just to be another MBA student. I wanted to take advantage of all the technology-related resources at the school.

As mentioned, I have been a self-taught programmer for most of my life. It is always good to verify that you actually know what you are talking about when you are self-taught. Taking Masters-level courses in computer science at Stanford was an excellent opportunity for me to compete with the best and ensure I actually knew what I was talking about. This was around the hype and excitement in AI, machine learning, and deep learning. CS 231N is the marquee computer vision deep learning class at Stanford, and CS 224N is the marquee natural language processing deep learning class there. Those are the two most important ones I wanted to take. There was a ton of work, much more than a typical MBA class. I was one of the two MBA students in them, did well, and got an A in both classes. I also connected with folks in the computer science department.

I served as the Co-President and Vice President of the Venture Capital and Tech Clubs, respectively. Having come from venture investing and being reasonably sure that I would go back, being part of the VC club made a ton of sense. The VC club brought venture investors to speak on campus. Naturally, being the president means you get to meet all these people, even if you were not involved in booking and getting them to campus. From a networking perspective, I ended up being the hub between the venture community and the Stanford business school, which was really nice and helped expand my network among venture investors.

On The Venture Ecosystem at Stanford

Classically, Stanford is like the meme of VCs walking around campus and prowling for the next Facebook. But it is true to some extent. It is a big attraction for why people want to go to the business school there since the perception is that it will be this launchpad to break into venture investing. I would say it is not as simple as people find when they actually arrive on campus. Every other eager Stanford MBA also wants to get into venture. These VCs got inundated with email messages and cold outreaches from Stanford students who want to get into venture, so it is a bit tricky to get their attention.

A big purpose of the venture capital club is to serve as the conduit between the students and the VCs. The basic value prop is: rather than responding to 30 cold outreaches from students, they can just come to a classroom and talk to all of them. To use the data analogy, it is a batch process. It is more efficient for the VCs, and the students also get a lot out of it. Because we speak for the school, the typical VC is likelier to agree to do that than a random student reaching out to them.

We also foster some connectivity via events. We had this annual mixer between the VC club and the Bay Area venture community. During an evening of orders and drinks, people could chit-chat and hopefully land a business card or two.

On Working at Confluent as a Product Manager

Confluent was a company I had heard about for a while, given that data infrastructure was one of my focus areas at ICONIQ. I was a novice when it came to streaming and real-time infrastructure. I was introduced to the product team there and impressed them. Even though I was an MBA student, I actually knew what I was talking about. They were just shocked that I could even hang with them - as far as understanding Kafka, topics, brokers, distributed systems, and whatnot. So I was able to get the job there.

Confluent had been a very engineering-driven organization up until that point. They started a product team because there was more work to go around that they needed to deal with. I got a great experience being a first-time product manager there. My skill sets marry both being business-oriented and technical. It was valuable there because there were many people who were just technical, and there were also many people who were just commercially oriented. But few people could hang with both. I was the liaison between different parts of the organization, which was pretty cool.

A key learning for me was that the networking you can do in the operational context is so much better than networking in the more transactional sense. I was not at Confluent for that long, yet the network that I built was pretty amazing and arguably higher quality since I worked with these people and have been in the trenches with them.

On Joining Lightspeed Venture

I had known about Lightspeed for a long time, partly because the enterprise team here had backed many interesting companies in the DevTools and infrastructure space over the years. The firm made a lot of money investing in these companies as well. As someone obsessed with this part of the software stack, it seemed very much a natural fit for someone like me. I could come here and focus exclusively on those things where the firm had a lot of strength.

Lightspeed is also first-principles-oriented in terms of how we make investments, which aligns with my personality. It was a great fit from that perspective.

Lastly, Lightspeed had historically been an early-stage firm. Now we are multi-stage, but we started as early-stage and have a lot of DNA in the building. I was at a point where I wanted to transition to earlier-stage investing and learn that side of things, so being at a firm that has been doing that since the beginning, with expertise around what a good company looks like at the early stage, was really important for my learning development.

On Forming His Early-Stage Investment Thesis

Part of the rationale for going to earlier stages is the opportunity for me to flex my product and technical sense. At the early stage, the product has a lot of technical risks. Being able to understand that side of things is very important, in addition to being able to endear yourself with technical founders.

One of the best ways to a technical person's heart is through nerding out the technology. Early on, I showed up to a meeting and said credible things - like I have actually used your product, I did "pip install" a few weeks ago, I did npm or whatever. Being able to have familiarity with these concepts and talk the talk of a typical developer would definitely make me stand out, even though I have never been paid for my code.

Having worked at Confluent, I helped lead Lightspeed's investments at Redpanda and Materialize. That has enabled me to be helpful to them. It all goes back to my core passion for technology, which is helping make the lives of developers easier.

On Investing In Ponder and Voltron Data

If I were to collate all the code I have written over the course of my life, the vast majority would be in the data science and analytics context. I am a big Python/data science nerd. I love doing ad-hoc analyses via Jupyter notebooks. I really like Python as a language: it has many advantages over other languages but also carries some disadvantages. A big reason a company like Databricks exists is to help solve those disadvantages of Python when you are doing large-scale analytics or ML in a distributed context. My rationale for investing in Ponder and Voltron data is to give people alternatives to shipping workloads off Databricks and Spark.

Ponder helps you scale up Python-based analytics with Modin - a data frame that sits on top of Pandas, the most used data frame in the Python ecosystem. It is an extremely popular library but does not scale well to massive datasets since it does not fit in memory. So Ponder helps you do that but keeps it within the Python ecosystem. You no longer have to worry about shipping code off Databricks or learning Spark. None of that is necessary if you have something like Ponder.

Similarly, Voltron Data gives folks an alternative to other big data analytics platforms by enabling heterogeneous programming languages to do analytics with heterogeneous hardware. Whatever your lingua franca of languages is (Python, C++, Rust, etc.), Voltron provides a common interface to speak to them and deploy their workloads on any underlying infrastructure (CPU, GPU, FPGA, etc.) This is a similar thesis of meeting folks where they are in their analytics journey.

The founders, in both cases, are brilliant individuals. With Ponder, the founders came out of UC Berkeley's Ph.D. program, the RISE Lab specifically. With Voltron Data, the CEO (Josh Patterson) came from NVIDIA, and his co-founder (Wes McKinney) is the creator of Pandas, which is the thing that Ponder is making scalable. It is just fun to be involved in both companies.

Furthermore, the open-source communities in both cases are exploding. Apache Arrow's downloads across the different languages they support have exploded over the past few years. Modin's downloads have been up to the right. It is really exciting to us, as open-source investors, to see that kind of traction and love in the community.

On Investing In Redpanda and Materialize

Both companies have brilliant technical founders:

• Alex Gallego at Redpanda is one of the most brilliant, high-energy engineers I have ever seen. He wrote the initial version of Redpanda entirely himself. It is shocking how performant it was for being written by one person.

• Arjun Narayan and Frank McSherry at Materialize are brilliant engineers and scientists who know how to make big data systems work at scale and make real-time infrastructure a viable alternative to batch-based processing.

In terms of their products, having come from Confluent, I was very turned on by opportunities around streaming data and real-time infrastructure.

• One of Redpanda's core features was something that I had worked on at Confluent: getting rid of Zookeeper - an open-source technology that helps you manage the distributed system. But it has its own system with a set of nodes that you need to spin up when you are running other products. Many problems can come up when you have to run two systems together. Most folks would just prefer to run one. Kafka, until recently, depends on Zookeeper. It is slowly removed, but it has been a slow process. Redpanda, from the start, has never had a dependency on Zoopker. They use the Raft algorithm, which is attractive to me as someone who is concerned about the developer experience. And Redpanda has an amusing developer experience.

• At Confluent, we have a product called ksqlDB. I saw over time the belief that Confluent had in that product and how much the opportunity around a real-time database was. Materialize made a lot of sense in that context - being an independent company that offers a real-time database and works with any number of streaming technologies.

On Real-Time Data Infrastructure

There is this ongoing transition from old-school batch data systems, where you process all the data in one big bang that takes some amount of time and leads to delays in the data's freshness. In the past, real-time was not technically feasible due to how these systems were architected. Slowly, it became feasible, but building these systems involved stringing together various independent technologies that only the most sophisticated organizations like Uber or Netflix could do. One of the most exciting things about this space is that there is now a set of tools that have abstracted this underlying complexity. You no longer need an amazing data engineer to implement this stuff. The bar is slowly lowered year by year, and more people are getting access to real-time infrastructure. That is one way of looking at the market from the technology side.

On the demand side, the use cases have grown a ton over time. More and more organizations are finding reasons to leverage real-time data. It has always been an interest in the context of highly transactional and high-velocity settings, such as consumer companies, marketplaces, and e-commerce sites. But you are also starting to see more cases within B2B, especially in financial services, which leads to growth in the overall space. It is still the early days, like most organizations frankly do not have a real-time use case right now, but they increasingly do. So our rationale has been: Let's get ahead of this curve and invest in some foundational technologies within the space. So far, it is working out.

On Advice In Hiring Decisions And Navigating Growth Strategy

As far as hiring, our mentality generally is keeping the bar very high. One of the things that our companies run into is folks who have alternative offers at big tech companies. As a result, they have very high expectations in terms of compensation versus what the typical startup can provide. That is often frustrating for founders because they have someone they would otherwise be really excited about, but that person could always work at Google, Microsoft, or Amazon. I often tell founders that: if someone is comparing you to those options, maybe they are not the best fit. The fact that they would consider working at a big tech instead of a high-growth startup maybe say more about them. Maybe you should not compete for those people since they are just looking to optimize different things.

In terms of navigating growth strategy, in the past, I have been a big nerd around unit economics - what is the profitability of the marketing dollar revenue? Early-stage companies typically do not have a great handle on what that looks like for them. Growth-stage companies generally have a better handle on it. But even then, there is much confusion, and people do not always know how profitable their business actually is. So I am always harping on that. Since I focus on developer-centric companies, developer relations have been a big theme of mine. I am the DevRel guy here at Lightspeed. I encourage all of our companies to hire these folks as early as possible, even as one of the first employees to evangelize the products. DevRel is increasingly formalized as a field, but it is still a little Wild Wild West. But I think companies that do that very well create a lot of Alphas, as far as developer-centric investing goes.

On Scaling Developer Relations

This role is extremely hard to hire, so I advise founders to think about DevRel as not just the people you hire to do it for you but something your entire organization is oriented towards. Content is a nice way to bootstrap yourself to DevRel. In fact, even without a ton of folks on staff, content is a scalable asset: you do it once and pay the fixed cost upfront to write the thing, then it can get unlimited traffic.

My experience has been that content scales non-linearly. In other words, more is more. You put out more content pieces, and a fat-tailed distribution of outcomes can happen. Most of your pieces might not do that well in terms of traffic, but a small percentage of them will make the rest of them worth it. Something will go viral and hit the top of Hacker News, for instance.

It is also important to be creative in terms of hiring DevRel folks. Almost every DevRel person is a former engineer, so you do not have to look at only current DevRel people. You can meet people who are currently engineers and might want to make DevRel a part of their daily work. You should look at your current engineering team and consider leveraging them to put out DevRel content. This is oftentimes under-utilized by companies to scale out DevRel initially.

I spend a lot of time meeting with and reaching out to DevRel folks I come across on Twitter, YouTube, etc. to build relationships with them. A big reason why it is hard to hire these folks is that: you do not know who is out there because there is a big selection bias or recency bias. DevRel folks you are most likely to hear about are those most in demand because they put out a lot of content and have big audiences. But there is a long tail of DevRel folks who may not have as large of an audience but can be perfectly good for your company. So I focus a lot on those next-tier folks and build relationships with them. Periodically, we have events at Lightspeed, where I bring together founders and DevRel folks to chat about best practices and make connections where they are appropriate. People enjoyed those since they were valuable. DevRel folks are extroverted, nice, and curious to learn new things - which is my kind of people.

On The Developer Productivity Manifesto

This idea came from both my interests in developer tools and economics. I spend a lot of time reading economics research when I am not investing. This married those two parts of my mind. Basically, the developer productivity flywheel is this virtuous cycle between creating more software developer productivity tools:

1. New developer productivity tools make software developers more productive.

2. Higher developer productivity drives companies to hire more software engineers.

3. More developers working at higher productivity levels ship more software, a subset of which is developer productivity tooling.

Then, this loop continues. An important element of this is that I tend to emphasize productivity more than bringing more developers into the world - even though I am very much in favor of enabling more folks to become software developers. Applying more developers to the same problem does not always lead to solutions.

• There is a diminishing return regarding the number of developers you can assign to a given project before you run into the classic scaling issues associated with any kind of knowledge work (but especially software development work). The work is an indivisible unit of work: doubling the team will not solve it any faster. Thus, it is super important not to necessarily throw more bodies at the problem.

• There is also a diseconomy scale with complexity issues that you run into when you start building large software development teams with complex software systems.

Another thing people do not realize is that many folks drop out of software development after a couple of years. There is a big leaky bucket issue, which would suggest that nearly expanding the number of developers out there and the number of developers entering the profession will not solve the problem - since many of them will turn out in the first place.

Lastly, if you take what we could be doing in terms of development productivity that we are currently doing and think about people who are not yet software developers, you can write the math which would suggest: there is something on the order of $700B in software that is not produced annually (that we could be producing if we were trying to optimize on these different dimensions). That sounds like a big number to me and a problem worth focusing on. That is the intellectual rationale for why I am so focused on this space.

On The Fat-Tailed Nature Of High-Growth Startups

My interest in the topic was sparked by reading all of Nassim Taleb's books - "Fooled By Randomness," "Black Swan," "Anti-Fragile," and "Skin In The Game." He talks a lot about fat tails and how they turn your natural intuition on its head. They are everywhere, serving as the norm rather than the exception, especially in technology. Since you see it so often, it was worthwhile to take a more rigorous view of these dynamics that people have seen but have not necessarily had the tools or mental models to understand and explore.

There are a few ways that this topic of fat tails comes up:

• The distribution of returns in venture is very fat-tailed, where people observe the power law distribution.

• SaaS monetization tends to be very fat-tailed in your customer base.

• Product-market fit (how well your product fits the market) and company performance (a derivative of product-market fit) are also fat-tailed. A small improvement in product-market fit can vastly improve business performance.

We need to take this concept seriously. The idea of the average is a very misleading concept when you are dealing with fat tails. Many folks talk about revenue per customer. That is not actually a meaningful metric when the underlying distribution is fat-tailed. You want to explore its implications for understanding unit economics, modeling the revenue of a software company, and identifying customer concentration risk that a software company faces. These are topics that I want to continue exploring.

On Weighted ACV

The easiest way to think about weighted ACV is the difference between being at the geometric center of an object from being at its center of mass gravity. If you are doing physics on this object, you should care about its center of gravity, not its geometric center. Similarly, if you are doing physics on a company, you want to model its evolution going forward. You want to focus on its center of revenue rather than just the average revenue. That means focusing on where the revenue actually comes from. For most businesses, this comes from a small subset of customers.

You want to come up with a metric that gives you some sense of where the average more of revenue comes from. What side of customers the average dollar typically comes from is a very useful metric because it tells you where the risk is in the business and who is buttering your bread, so to speak. It tells you whom you should focus on from a potential expansion standpoint.

It can help, in some cases, make the company look a lot better than it would otherwise. Let's say a company has a bunch of free and low-paying users, but then a small number of users is meaningful with enterprise scale. Looking at the average, you might think this company does not monetize very well. Their average revenue per customer is low. If you look at the weighted ACV, it might be the case that the average dollar revenue comes from $100k-200k customers, which is a strong monetization. So I think this is a metric that folks start to include within their framework for how to think about their companies. It can be used in conjunction, not a replacement, to the regular average.

On His Credibility As An Investor

These various forms of recognition are vanity metrics, and I sometimes question how valuable they are. But I think of these awards as recognition of past behavior: you have done enough to earn the credit, and if you do, then you should get it. But past performance is not a predictor of future performance. I am always a bit wary because Nassim Taleb says these awards are given at the peak of that person's career. So I worry that I have already peaked, and it is all downhill from here.

But more seriously, it is nice to be able to point to something that says: I am a competent, thoughtful investor who has made good bets in the past and will hopefully make good bets in the future. It is a way to open doors and provide a bit extra credibility as I am going out and trying to win these deals and the opportunities to work with these founders. If I do that enough times, then I will have accomplished my mission of increasing total software output.

My routine has mostly stayed the same over the years. I spend some time meeting exceptional founders, some time doing due diligence and understanding their product/business, and some time being helpful to my portfolio companies in every possible way. On top of that, I spend some time nerding out and going where my nose naturally takes me - whether learning a new programming language, exploring a new library package that I heard about, or spending time on Hacker News and Reddit. I just try to hang out where developers hang out in order to stay at the forefront of things. It is important because the software industry changes so frequently and quickly, so I spend a lot of time keeping my skills and knowledge up to date.

Show Notes

• (01:32) Nnamdi shared formative experiences of his upbringing, where he spent countless hours building computers, coding up websites, and finding ways to game Google search.

• (04:54) Nnamdi described his undergraduate experience studying Economics at Yale University and interning at McKinsey and J.P. Morgan.

• (08:10) Nnamdi reflected on the decline of the investment banking industry - given his one year working for the technology, media, and telecommunications group at J.P. Morgan in New York.

• (12:52) Nnamdi discussed his career transition into venture investing at ICONIQ Capital, where he deployed over $500 million into high-growth technology companies.

• (15:00) Nnamdi reflected on his proudest accomplishments during his four formative years at ICONIQ.

• (17:35) Nnamdi talked about his excitement for GitLab, one of his investments.

• (21:27) Nnamdi touched on his time getting an MBA from the Stanford Graduate School of Business.

• (24:21) Nnamdi also completed coursework in Stanford's Computer Science department (such as CS 231N and CS 224N) during his MBA.

• (26:37) Nnamdi explained the venture ecosystem at Stanford, given his experience serving as the Co-President and Vice President of the Venture Capital and Tech Clubs, respectively.

• (28:57) Nnamdi unpacked his experience working at Confluent as a product manager and conducting independent research on trends in developer productivity.

• (32:23) Nnamdi reflected on his decision to join Lightspeed Venture in mid-2020, investing in early-stage software startups to enhance the productivity of technical knowledge workers.

• (34:17) Nnamdi shared how he proved his value upfront in potential deals and started forming his investment theses as a new investor at Lightspeed.

• (36:24) Nnamdi dissected the key factors that triggered him to make investments in the seed rounds of Ponder and Voltron Data (in the domain of developer tools).

• (40:36) Nnamdi explained his Series A investment in Redpanda and Materialize (in the domain of real-time data infrastructure).

• (45:45) Nnamdi shared advice he had been giving his portfolio companies in hiring decisions and navigating growth strategy.

• (49:07) Nnamdi walked through his 3-part series on major industry trends, top strategic priorities, and biggest challenges for software and infrastructure startups pushing the developer productivity frontier.

• (52:37) Nnamdi shared advice to startups thinking about scaling their developer relations, given the challenge of hiring developer advocates for dev-focused startups.

• (56:27) Nnamdi unpacked his 3-part series on the developer productivity manifesto that introduces the developer productivity flywheel, explains how more developers lead to lower productivity, and argues that we are leaving on the table $670B of software by not maximizing developer employment and developer productivity.

• (01:01:26) Nnamdi examined his obsession with the fat-tailed nature of high-growth startups, such as why VCs don't index-invest, why Saas monetization is concentrated on the tails, and why product-market fit gets harder to achieve the longer you search for it.

• (01:04:26) Nnamdi explained his new and improved SaaS metric called Weighted ACV, which is the weight of the revenue that a customer represents and tells founders where to look if they want to best understand the revenue of their businesses.

• (01:07:53) Nnamdi thought about his recognition as equal to his credibility as an investor on a mission to increase total software output by investing in technical tools for technical people.

• (01:11:03) Closing segment.

Nnamdi's Contact Info

• Website

• Lightspeed Profile

• LinkedIn

• Twitter

• GitHub

• Medium

Lightspeed's Resources

• Website | Twitter | LinkedIn

• Global Presence

• Medium Blog

Mentioned Content

People

1. Mike Volpi (Index Ventures)

2. Keith Rabois (Founders Fund)

Books

Nassim Taleb's Incerto Series:

• Fooled By Randomness

• The Black Swan

• The Bed of Procrustes

• Antifragile

• Skin In The Game

Notes

My conversation with Nnamdi was recorded in May 2022. Since then, many things have happened. I'd recommend checking out:

1. Lightspeed's announcement of the new three funds last year

2. Nnamdi’s new series on software valuations (1, 2, 3)

3. Nnamdi’s recent posts on the reality of tech layoffs and the need for more startups

4. Nnamdi’s recent investment in Select Star

About the show

Datacast features long-form, in-depth conversations with practitioners and researchers in the data community to walk through their professional journeys and unpack the lessons learned along the way. I invite guests coming from a wide range of career paths — from scientists and analysts to founders and investors — to analyze the case for using data in the real world and extract their mental models (“the WHY and the HOW”) behind their pursuits. Hopefully, these conversations can serve as valuable tools for early-stage data professionals as they navigate their own careers in the exciting data universe.

Datacast is produced and edited by James Le. For inquiries about sponsoring the podcast, email khanhle.1013@gmail.com.

Subscribe by searching for Datacast wherever you get podcasts, or click one of the links below:

• Listen on Spotify

• Listen on Apple Podcasts

• Listen on Google Podcasts

If you’re new, see the podcast homepage for the most recent episodes to listen to, or browse the full guest list.