Mr. Andrew Miklas co-founded PagerDuty, Inc. in 2009. He joined S28 in December 2017 and serves as a Partner. Mr. Miklas holds a BSE in software engineering from University of Waterloo from 2001-2006, and an MSc, in computer science from University of Toronto in 2006-2008.
Claudio Pinkus: Thanks for taking the time to talk to me today. The first question is what is it that you think makes for successful companies? What are the most important ingredients? Please narrow it down to the essence.
Andrew Miklas: I think the traditional answer - “founders, market, and product” - is pretty close to the right one. More specifically, my partners and I have a theory that for any successful startup, there are probably only seven or so unique factors that drive its success.
Those things will be different for different businesses, though they will relate back to the general “founders, market, and product” trinity I mentioned above. To give an example, at PagerDuty, I believe one of them was the way we became positioned as one of the flag bearers for DevOps – a movement that swept through the engineering community starting in around 2010. Another was our focus on putting the practitioner first in our marketing message & product design in an industry where that often wasn’t the case.
CP: What do you mean when you say that those things drive a business's success?
AM: Our belief is that businesses do well based on the strength of those few special observations or ideas baked into them at their start, and are therefore surprisingly resilient to problems outside of those things. Put another way, a whole lot can go wrong and a whole lot of mistakes can be made as long as the seven things or so things that are “right” about a business continue to be true.
CP: You’re suggesting that even if you have a great team, if you are swimming upstream you’re going to be facing obstacles that you don’t need to face had you picked a market that is secularly moving in the right direction?
AM: Exactly. When I see a company that is targeting a market I perceive is shifting to something else I ask what the market might be like in ten years. People say stuff like “there’s still of lot businesses like X so it will make sense to target that.” The start-up might be making millions of dollars targeting that industry. I’m very reluctant to invest in that. I’d much rather invest in something where I feel like there’s a story for where it’s going to be bigger in the future, even if revenue and metrics in that business are much smaller today.
CP: How long have you been a VC?
AM: I’ve been investing personally for a couple of years, and started investing professionally last year.
CP: You were an entrepreneur for a long time and now you have a very different hat on as an investor? How is that transition?
AM: It’s still kind of weird. When I talk to people they’ll say “oh you work finance?” I still think of myself as a technologist and engineer who just happens to be investing. One of things that’s very different right now that I’m still getting used to is depth versus breadth. As an engineer all you do is think about one very particular problem. As an investor it’s completely flipped. You’re expected to have a great deal of breadth to understand many industries. As an investor the idea is that you’re able to piece together what’s going on across many areas of the economy, but what happens is when you’re talking to somebody you very quickly run off the end of your understanding their particular zone.
The way I used to work, if there was something I didn’t understand I’d just lock myself in a room for 3 hours and study or play with it. Figure out how this new library works just by doing. That doesn’t work as an investor. There’s not enough hours in the day to do that.
Another shift that I’ve started to get a little more used to is the feedback cycle for investing. When you’re working on a company you find out very quickly if you’re doing the right things. You have this agile process - you try something, put it in the market, and if it doesn’t work you try something different. With investing it takes years to understand if you’re any good at all. That’s sort of a disconcerting feeling for me.
CP: I totally get that. I cook every evening. And sometimes I'm asked why I do that even when I am busy. I could be doing something else with my time. The answer is that I spent so many years investing in long term things that I needed something more immediate that gives me short term results to feel a certain level of satisfaction. (laughs) And you can just chop something up and throw it in the oven and an hour or two hours later, you eat it. And that feels like the immediate gratification that investment does not give you.
AM: Yes. Definitely not. Another difference is that as an engineer I had this drive to systematize and construct. I’m not going to solve this problem just once, I’m going to figure out how to do it repeatedly and build a system so that I don’t have to do this again. I sort of initially approached investing the same way. When you go to raise your next fund, you want to be able to say “here’s what I did and here’s how I know I can do it again.” But I’m also realizing how resistant the the field is to that. So much really is just dependent on happenstance. Everyday is so different. The companies you’re seeing are so different. It doesn’t lend itself to automation or systematization that an engineering mindset sort of creates.
CP: It kind of ties back to what you said to start with. Which is, if your most important criteria for deciding to invest in a company is that it's on a good market trajectory, then it follows that all kinds of other things are just dependent on whether you found something that has the potential to become a big thing because of its market. Even an average company in a good market is better than a great company in a shitty market.
AM: Yes. Yeah for sure. Even when you ask, what specifically about this opportunity, this investment opportunity makes you drawn to it. I try to talk with other investors and ask: what is it that you see here? Or not see here? And I try to predict what they're going to say. And it's very hard because I don't even know if in their minds they have a clear framework for how they look at things. And at the same time, I don't think it's all luck. It's not like I'm sitting here saying the great investors just get lucky time after time. But whatever it is they're doing, at some level, defies pure systematization.
CP: As a former co-founder of PagerDuty, what would you advise founders at the early stage of their company to focus on? What’s most important to their success?
AM: Number one, it’s building a team. You need a good co-founder and the question is what are you looking for in a co-founding team? Things like a complementary skill-set, working well together. Respect for one another without the cagey stuff that feels like you can’t question one another. There’s a very careful balance. You need to really understand why you’re solving the problem that you’re trying to solve and why the team is uniquely suited to doing so. A team of two engineers who only worked on writing code in their life may have a business plan that is going to require conducting million dollar plus sales to a bank. That can be very difficult with their skill set. Also, do they have the right blend of perseverance and flexibility. You want people who aren't going to give up at the first sign of resistance, but you also don't want someone who's going to be like, "This is the way that this problem needs to be solved and I am solving it this way and it doesn't matter what anybody tells me."
CP: What you’re pointing to is that you’re really creating a culture that is going to permeate your organization if you’re successful. Perhaps you know what that is. Perhaps you don’t. But it’s happening anyway.
AM: Yes. What becomes the culture are the points of commonality between the founders that they don’t necessarily even realize that they have, because they’re the things that you don’t talk about. When you hear people at an early stage company start to talk about culture it’s usually something aspirational. Much later on at an organization, maybe even after the founders have left, you try to ask yourself what’s different about this place? You trace it back to the founding team. It's the things that the founders would have never thought to call out as something. Because it's so baked into how they operate that it almost doesn't seem worth talking about.
CP: Let’s shift to something different. Macro trends. What do you feel are the macro trends that are driving growth today?
AM: Essentially, how the automation or optimization of industries through software still has a very, very long way to go. It’s not anywhere near done. One of our portfolio companies, Social Construct, is looking at how to build interiors of apartment buildings more efficiently. They're almost applying software engineering workflow principles to the process of construction. That is an amazing idea, and an amazing approach that they're taking, by essentially taking software into businesses that historically have not had it.
CP: It seems that software development is still too much of an artisan type of job. I think that there is a lot of time wasted on things that could be automated and we end up with situations where the tools that software developers are using continue to be less efficient than the tools that they make for their customers. As in “The barber has the worst haircut in town.” What is the right balance and where do you draw the line between creativity and automation?
AM: There's an aspect of software development that's almost accidental, basically. It's just a result of the interactions between the tools: the tooling and the language choice you're going to use, how the database interacts with this other database and all that. To me, those problems are actually the ones that are right for better tooling to reduce.
It used to be that there’s a distinction between software engineers and systems analysts. Those fields have come closer together. Software engineers are no longer sitting there hand assembling flow charts. Now software does that. There’s software that handles a lot of operational aspects. Whereas before you used to have assistance wiring computers together, now we have AWS, and we’re actually moving on top of AWS again with layers of extraction where you don’t really perceive there being an actual system beneath it. Going back to the original question, when I look at developer tools or operation tool companies, it's about understanding “What are those things for other people?”. Specifically, our software engineers' minds have to focus on the sort of intrinsic complexity of the problems they're working on, rather than the dealing with how to actually make the thing work.
CP: How are things different today than they were a decade ago?
AM: A decade ago AWS was just a few years into its run. You had the ability to pay by the hour for hosting but you didn’t have these higher levels of abstraction. The amount of effort it took to get a startup off the ground was definitely less than a decade before, and certainly cheaper than a decade before that, but still not as easy as I think it is today.
Another big change is the way capital is raised now, especially in the early stages. It is pretty different than what I was used to. You got a bunch of angels together, maybe you got a seed investment, and then that was kind of it. Twelve to 18 months later, you had to do a Series A or you wouldn't, and that was that. Now, the when and what that goes on in the pre-A stage of financing is much more fluid. You have small seed funds, big seed funds, companies that do one seed and then do another seed, then maybe another seed, and it's just a more fluid process as to what's going on in there. Once you hit 'A' things sort of settle out more similar to how they'd worked traditionally.Another big difference from seven years ago is how much bigger A rounds are!
Another change is that people outside of tech have an opinion on tech, and I don't know that that was happening 10 years ago. Maybe it was happening during the first dot-com bubble; I wasn't here for that. But now it seems there is much more - I almost want to say tech is a power to be reckoned with. Google and Facebook and all these guys were considered reputational-y in a positive light. There's sort of this shift that's happening where they're almost now - People talk about Google and Facebook like- I'm going to say 'big data', or perhaps 'Big tech', right? In the same way they talk about 'big oil' or something like that. It's weird to see these things, in some sense, see yourself, realize that other people see you kind of as the villain. That wasn't true 10 years ago.
CP: Definitely wasn't, but they were thinking about it because Google would not have chosen 'don't be evil' as their motto, otherwise.
AM: That is true. It wasn't as pervasive. You didn't open the New York Times and read three articles about how ‘tech is going to destroy democracy' every day, right? Now as the technologist, I'm thinking about these things. Did we actually build things that are going to be not net-positive for the world?
CP: I think we already have. The only question is, is it something that's irreparable? Some damage was done by us, too, to at least parts of what's considered to be valuable in society.
AM: An example is the almost behavioral modification thing that happens, especially in consumer products like smartphones where you're pushing engagement at the expense of everything else, and it almost retrains people’s' minds. I used to have a longer span of attention than I do today.
CP: We'll see how we can somehow contribute to the improvement of those situations.
AM: I think that would be a good area for investment work or something. I'm sort of on the lookout for companies or groups of people thinking about this problem space.
CP: Last question. You’ve invested in CodeStream. What is it about the opportunity do you find most compelling?
AM: There’s multiple answers here but the strongest one - When software engineers build software, there's the actual code that they produce, and then there's the mental processes that go on in their head, and that framework, about what they did and why they did it and how to extend to all of that. The difficulty is that software engineers typically are coming and going between companies, basically switching jobs every 18 months, and when they leave, you get to keep the code, but you don't get to keep what was going on in their head. Whoever comes takes over the code, you now have to figure out how to get to what was going on in one person's head into the new guy's head before they can really start to produce code themselves. We obviously know how to capture the actual source code. I’m hoping that CodeStream will be able to capture and transfer more of what’s going on inside the engineer’s head, if that makes sense.
CP: It does. As we tend to say, we are about the ‘why’, and to the extent that we can capture the ‘why’, we’ll be answering a lot of WTFs along the way.
Thank you very much for your time.
AM: You as well.
Please share your thoughts and feedback @teamcodestream.
CodeStream helps development teams discuss, review and understand code. CodeStream links comments and issues directly to the code blocks they refer to, making them instantly available to everyone on the team.