“What a Long, Strange Trip It’s Been.” Transitioning from Operating to Venture Capital

In September of 2018, I joined Index Ventures as an investor focused primarily on Machine Learning and software infrastructure. As someone who had spent his entire career working in Engineering and Product, this was a pretty major career shift, and since joining I’ve received a lot of questions from former colleagues, hopeful investors, and a lot of very curious friends. While the breadth of questions I’ve received has certainly been broad, I’ve found that there’s one question in particular that has risen above the rest: “How has your operational experience translated to your time as an investor, and how should I, as an operator, frame my skill set for a potential move into venture capital (VC)?” I’ve reflected on this question frequently, and at just a year past my first year anniversary with Index, it felt like the right time to take a crack at an answer.

I was fortunate enough to get exposure to a wide variety of roles and projects during my time as an operator, which in turn gave me the opportunity to learn from some truly incredible peers and mentors. It’s impossible to summarize the countless things I learned during this time in just a few pages, but, if forced to do so, I’d focus on three key takeaways:

1. Empathy
2. Perspective
3. Network

I’ve found these learnings to be incredibly useful and try to exercise them on a daily basis in my new role as an investor.

Life as an engineer gives you empathy

To save you the requisite LinkedIn stalk, I’ll start with a quick background. I began my career as an Engineer at Palantir Technologies, where I worked on a wide range of products spanning Federated Search, Distributed Data Sharing, Data Integration, and Access Control. Following Palantir, I joined MemSQL as a Product Manager, where I focused on Deployability, Data Ingestion, and all things related to user-interface.

By the time I joined Palantir, the company had already been around for about 10-years. Its massive legacy codebase provided a fascinating glimpse into the wild, hectic, and often quite disorganized world of professional software development. The experience of fumbling around a real, professional codebase is a bit of a right of passage for any newly-minted Computer Science graduate. It is a metamorphic moment when you leave the snug cocoon of boilerplate academic assignments and solitary pet projects, and step into the airy void of professional software. Your days of conflict-free git pushes become nothing more than a faded snapshot in the photo book of life, and you end up spending much more time fixing bugs, writing tests, and doing all of the other necessary but unsexy tasks that form the foundation of professional-quality software development.

I spent the vast majority of my first year at Palantir convinced that I was the only one trying to find my way around. Now a bit older and (hopefully) wiser, I’ve come to realize that this feeling is shared by pretty much everyone during the first few months of their career. The experience of struggling to get up to speed taught me a tremendous number of things, the biggest of which is empathy for how hard it is to build things. I can’t pretend to postulate as someone who understands every single pain point of every type of developer, but I do feel that having a set of shared experiences, vocabulary, and the ability to go deep(ish) into technical details have been an incredibly useful set of skills. Early-stage startups are largely about product development, and having the battle scars of being in the trenches helps you connect with the everyday struggle of trying to create something from nothing. While my personal experience has been in Engineering, this stress is a reality whether you spend time in Engineering or Marketing, front office or back office, consumer or enterprise. You’ve stayed up until morning debugging, left work with your head throbbing over things that aren’t working, and missed the deadline because you were overly optimistic. This is the reality of trying to build something.

Engineering leadership gives you perspective

After about a year as an individual contributor, I was promoted from an IC Engineer to an Engineering Manager, now responsible for a group of individuals across a couple of different development teams. As anyone who has made this transition will know, management is an entirely different beast from writing code, presenting a totally different set of challenges that you definitely didn’t learn how to tackle in school. Responsibilities shift, you write less, -- if any, -- code (or your role’s equivalent), and the name of the game changes. Your priorities become 1. empowering your team, and 2. setting the strategy. If you are looking at code/copy/process, it often comes in the form of code reviews and pair debugging, both of which are important tasks to grow your people and make yourself irrelevant. While it can be tempting to look at management as “being in charge” or being in a “teaching” role, I found it to be much more of a learning experience. If you have the good fortune of working on brilliant teams (as I did), you spend the majority of your time learning to ask the right questions to get enough of an understanding of what they are up to so that you can effectively remove roadblocks and communicate progress to external stakeholders. You get more exposure to strategic decision making and what is going on throughout the rest of the company, noting what works, what doesn’t, and what really doesn’t.

This perspective lends itself incredibly well to investing. It gives you a great sense for what pitfalls to help your portfolio avoid, and arms you with the basic pattern matching required to effectively sort through the firehouse of companies that inevitably come across your desk. You are intimately involved in interviewing and hiring, so you know what a successful candidate (or founder) looks like. You’ve had to give direct feedback and have had difficult conversations with the folks that work for you, an experience that comes in handy. Engineering leadership, in particular, helps you understand how feasible an idea is technically and, more importantly, how long it will realistically take to build, a key skill in separating the realistic ideas from the ones that might be overly optimistic.

Product Management extends your network

After a year of Engineering Management, I made my final stop before my transition to VC: Product Management. The decision to move into Product Management was driven largely by a realization that, for me, the beauty of code has always been in the creativity that it unlocks. The bits and bytes were certainly intellectually interesting, but the real driver was the ability to type a few words into a text editor and magically create everything from a boggle game, to a beautiful website, to a machine learning model, to a heap allocator. The fun part was coming up with what to build: the endless sheets of scribble covered computer paper, the back and forth with designers, engineers, and users. My product management experience also taught me about the importance of focus (maintaining team focus is the #1 job of a good PM), doing things 100% instead of 80% (cough documentation is extremely important cough), and reinforced my interest in and passion for design. Not to mention the Kanban boards...

My time as a PM was the most lucrative period of my career from a networking perspective. PMs have the opportunity to work with amazing people across almost every business unit, often acting as a translator between these groups to coordinate efforts and build the best product possible. Raw exposure to a higher number of people across a broad number of business units is obviously quite valuable from a networking perspective, but even more important is the exposure you get to how these different people think and operate. How does a marketer think about the world? How do I get a designer excited about a particular project? What are three things that make a great account executive? How do our customers think about procuring software? These are all questions that one must ask as a first-time PM, and doing so pays off big dividends in investing. Whether it’s recruiting for a portfolio company, interacting at a board meeting, or attending an event, you meet a ton of different people, and being able to easily switch from speaking with a designer to a salesperson to a customer success leader in an intelligible way is an invaluable skill. Product Management is one of the only roles that give you this breadth of exposure, and it’s something that is advantageous no matter where your career might take you.

Why it matters as a VC

Fast forward to the present day, to my role as an Investor at Index Ventures, the most rewarding and challenging one I've had in my career. I certainly wouldn't be here without all of the amazing people that I had the opportunity to work with during my time as an operator, all of whom taught me a tremendous amount about technology, teamwork, and about myself. The most valuable gift my time as an operator has given me is not empathy, perspective, or network, but rather the glue that ties them together: humility.

As an investor, it can be tempting to forget what it’s like to experience the pressure, stress, and personal setbacks that happen every day in the trenches of a high growth startup, where a million split-second decisions slowly sum together to create a game-changing business. Investors often see the high-level strategic wins, the deals closed and products launched, the quarterly investor updates and long conversations with founders over hiring and growth. But too often it can be easy to overlook the thousands of little things that happened along the way: the IC engineer pulling an all-nighter to ship that feature, the sales team coming together to close that last-minute deal, the customer success manager making that tough call to keep a customer from churning, the sweat of a village coming together to turn a founder’s vision into a team’s reality. It is these small, everyday victories of dedication and teamwork that are the highlights of working in startups, the tools that can turn a tiny village into a thriving metropolis. It takes just such a village to raise a software company. All I can do is pick up my new set of tools and do my best to help.