December 15, 2020
Building a Dev-First Security Unicorn: Fireside with Snyk Founder Guy Podjarny
In this Speaker Series, Snyk Co-Founder Guy Podjarny joined Heavybit Managing Director Tom Drummond for a fireside chat exploring Snyk’s j...
During one of the roughest years in modern US history, Sumo Logic IPOed in September 2020 to great success. But the road to public offering was a long journey – one that relied on widespread adoption of cloud-native practices and emerging trends in cloud computing, required stellar dev-centric design and scalability of a multi-tenant platform, and repositioned what began as clouds log management and monitoring into a holistic continuous intelligence approach.
Heavybit General Partner, Joe Ruscio, sat down with Sumo Logic‘s Co-Founder and CTO, Christian Beedgen, to discuss the failures, successes, and key trends that made Sumo Logic a leader in enterprise cloud transformation.
Joe Ruscio: Thanks everyone for joining us today. I’m Joe, I’m a General Partner here at Heavybit. I’ve been for about the last two and a half years. And hopefully most of you know Heavybit, we’re an early-stage venture firm and accelerator. I’m actually super excited today because in a previous life, I founded a company, in the observability space called Librato and Christian and I used to knock into each other back when things were a lot quainter, a long time ago. Which probably is a good segue.
So Christian, is the very accomplished co-founder and CTO of Sumo Logic. Hopefully you’ve heard of Sumo Logic, it’s a company that recently went public. And he has 18 plus years experience before coming in and building Sumo Logic. The multi-tenant, cloud-native machine data analytics platform, has over 2000 customers, 50,000 users. And I’m really excited, to talk with Christian today Christian, if you could tell us a little bit about how Sumo Logic– you’re now 10 plus years into the journey– how it all started?
Christian Beedgen: Of course. First of all, thanks for having me. It’s good to be in front of everybody even though I can’t see you, but maybe one day. We started Sumo in 2010. Our hypothesis was that machine data and various telemetries– back then, we came at it more from a sort of logging and locks angle– that kind of semi-structured data, is incredibly valuable for analytics, to drive insight across operations.
We thought that that sort of approach was rife. To see a new delivery model, specifically a SaaS delivery model, because the vendors in the space were still sort of stuck in the kind of on-prem, classic enterprise software world. Enterprise software is great but the delivery model has gotten a little bit old again over time. So the reason why we were thinking about this was that my co-founder and I were early engineers at a company called ArcSight.
Joe: At the time, no one was delivering this kind of capability with this model, right?
Christian: No, there wasn’t anybody. It was technically considered to be crazy, which by the way, is often a good indicator that you are onto something. Because if people think it can’t be done, then maybe if you can figure out how to do it, you’re delivering real differentiated value. I remember when the ArcSight founders started, they were told that a security analytics engine based on logs was never going to work. And sometimes engineering is just about making it work.
My co-founder and I were there for almost nine years as early engineers. I’m originally from Germany, kind of came into US as an intern and hung around through the ‘original bubble.’Did a little bit of startup things on the side. I got my H-1 and all of the things that you need when you’re not a citizen, and it landed me at ArcSight as first real job and it turned out to be an incredible growth opportunity, both personally and from a career perspective.
It also helped me understand an industry and then ultimately come up with this hypothesis that, there is a super interesting product with a broken delivery system. So we set out to find a different delivery model. We just looked at what had happened in the market before with ServiceNow taking out Remedy. We knew Remedy from integrations were like, “Holy crap!” The thing is really a little bit long in the tooth. Siebel, the Salesforce at the time, was also being taken out.
Niche by niche, we saw that enterprise software was being disrupted by SaaS startups, and people thought in our space it wasn’t possible because it’s such a data-heavy operation. We had been doing big data for 10 years before we even knew there was a term for it. We were doing logs for security since 2000-2001and people thought that scaling up a SaaS to deliver this type of big data product would be very hard.
We just thought from first principle, it would lead to a much better user experience because all of the set up and manual handling and upgrading and actual maintenance, that’s all undifferentiated heavy lifting. As developers, we want to build a product and ideally also be in control over the execution environment. It’s a good closed loop and we can instead focus on the customer and them getting value out of the product.
We found that access, to some degree, was mostly about upgrading the server and installing the Oracle. I don’t know how many security people we inadvertently turned into Windows storage administrators . So that really was the idea and seems like it was a pretty good idea .
Joe: You hit on something. It’s interesting the unique challenge that these kinds of businesses face. I remember, from trying something similar, that the more successful your customers became with your product, the larger your customers got. The more impact that they place on your infrastructure. Which is not traditional, in terms of software margins economics.
Christian: That’s definitely true. What we found is that if you set it up properly from the beginning in a multi-tenant fashion, and we did that and not everybody does that. Most people try to lift but we would lift and shift their existing products and sell them as multi-tenant cloud. We had the benefit of not having anything. We were able to do the whole thing from scratch and to some degree from first principle.
And so our system was from the beginning multi-tenant. What that means is that, in a single- tenant environment, you pretty much have to provision for the peak for every single customer. Let’s say for Black Friday, you basically have to have that capacity available, pretty much year round, there’s no reasonable way of autoscaling 2000 customers on a one per customer basis, that’s just not going to happen. So you run into this provision for the sort of peak and that tends to be pretty expensive from an infrastructure perspective.
In a multi-tenant scenario, you have to provision for the peak of all customers at any given point in time and what we found is that if you’ve set it up that way, you actually end up with a much lesser cost of infrastructure than if you were to simply take the infrastructure that any given customer needed, and multiply it by 2000 or whatever the number is. So that’s how we managed to make it work and I think we’re running it about 70% cross margin at this point. There was a lot of work to put into it, but it’s possible.
Joe: That’s a great number for the span of services and I’m sure you’ll bring it higher in years coming. So you and your co-founder were at ArcSight before, and the thing that I found fascinating as I was learning that, is that ArcSight was a security company, a SIEM (security information and event management) is what they call them in that category.
Joe: And typically those use log messages as primary input. Splunk is a great example of a company now that is very active in the SIEM categories. So, naively someone would think coming out of ArcSight, like you and your co-founder, “we’ll just build a SIEM as a SaaS” right? But instead you started with something more foundational. I’m interested in how you had the foresight or clarity to actually start with broad log management and leave tackling a SIEM problem for potentially later.
Christian: Foresight and hindsight is always tricky. In hindsight, what I think happened was that, we actually thought about going the security route, including tour discussions for series A and all of that. But more and more, as we looked around, we saw two things. One is that in the SIEM or security analytics space we were in back then, there was already some amount of maturation. A bunch of companies got sold, one company was public, lots of big players in there already been picked up by IBM and stuff like that.
There were 10-15 products stacked on top of each other, grinding out a $2.5 billion annual market. That’s not a bad market at all and we thought that was pretty busy. We were of course familiar and had always been fans of the approach of doing log search. We observed how they created new use cases in sysops and sysadmin in the operations space. We had just come out of ArcSight and we felt it was kind of unfair to just go back and compete with them. We started discussing the direction we should be going and we thought that there was a little bit more bite space on the operations side. We thought that we could probably get traction there faster.
It was also faster from an engineering perspective. From first principle, we had decided that we needed to build a multi-tenant big data analytics system so we knew we first had to put that data platform in place. Being a big, distributed log management platform is still at the very core of what we’re doing today. That ended up taking two years and once it was ready for GA, we didn’t necessarily have some of the expected functionality you would need in order to compete with a SIEM. Full-blown normalization, categorization, lots of security-specific features, rules engine, all of those types of things. We just hadn’t had a chance to build all of that.
We found that what we had a scalable substrate for machine data or logs. We were already able to deliver real value to customers that were coming at it more from an operational perspective, web logs and that type of stuff. So we were like, “Okay, let’s do this. Let’s take the revenue and let’s grow that way.” Of course, our heart was always with the security side and we knew one day we would go back to that.
At the time, when you’re like two or three years old as a company, the fact that it turns out you’re in a $50 billion market now, is incredible. It’s a blessing and a curse. It’s a blessing of opportunity but it’s the curse of figuring out what to freaking do because you can’t do all of these things at the same time. So that creates its own set of challenges. It’s quite interesting, but the security people, even though we didn’t have all of this deep functionality yet at the time, they still saw so much value in just being able to pour their security logs into a platform that they could just sign up for and start using immediately. They didn’t have to become any kind of Windows administrator or Oracle admin. They were able to build themselves a bunch of what they needed for their workforce on top of it.
As we grew and as we became more mature and had more execution capability, we then went back andstarted heavily investing in security again. Today, we see ourselves as an observability and SIEM company. It was an interesting journey but that’s how it happened.
Joe: This is a great segue because my next question is: especially having a background in the category that predates this– the term du jour is observability–there’s now quite a vigorous discussion that goes on about what observability is or what it isn’t. Given how long you’ve been working in this space, what does observability mean to you and where is that heading?
Christian: For me, there’s a couple of ways of looking at it but let me go through it at the highest level. I think observability is a means to an end and the end is to run reliable systems. That’s really the outcome-based orientation that we’re trying to talk about. There’s nothing wrong with observability it’s a fine term. It’s a term that allows us to bring together classic log management with classic time series and on top of it, classic APM functionality, all into one platform. It’s an engineering-driven term.
As markets are evolving, it gives us and our competitors in that space, a way to reframe what we’re doing. It’s like a canopy under which we can do more stuff for our customers, as can our competition. But I think it’s fundamentally a realization that, if you really want to run a reliable system, one type of telemetry is not enough. The one size fits all thing is often just not right.And now, each vendor in the space comes at it from a different angle.
We’re not the only company that started back then, there’s a bunch of other cool stuff out there, for sure. Those folks all have the same problem, they’re running at scale and they all realize that whatever their original telemetry is, that they felt really comfortable with, is not good enough to really run a reliable system at that scale at which you get to of thousands of customers. I think every vendor has their own opinion as to where they stand on it.
Everybody’s basically trying to evolve the thing into a full suite, which I think causes an incredible amount of pressure on product development organizations. What used to be one product, now we need three products. It’s not easy but I think it ultimately benefits the customer. We’re getting a chance to reframe what we’re doing on a higher level, to basically compete for our customers.
Joe: I was thinking about this the other day. You sign lots of big deals with large customers and I was wondering from a marketing perspective if reframing it for executives or the people that sign off on it, helps with the procurement process.
Christian: I think it does. In many ways, whether or not they’re using the same terms, everybody in the market, all the other CTOs will say the same thing. We’re talking about the digital transformation wave. We know at this point it’s a typology that all businesses are becoming digital increasingly. You already have enough of them that it’s like a giant market and it’s just going to grow. So businesses consists of a lot of smart people and a whole bunch of software.
And software, as we know, doesn’t just work on its own. So there’s an incredible industrial process and then once it’s in production, actually running it reliability and securely. But since we’re talking about observability right now, there’s monitoring, there’s troubleshooting, there’s APM, all of these things are required and I think all of these things have always been required and people just got the pieces from different vendors. Putting everything together is a new thing.
For us, the story about reliability and making sure that your software system runs reliably as a precondition for your business to be successful, that’s really the next level of outcome. It resonates. It resonates to a degree where it’s so obvious that I sometimes feel silly saying it, but it really does resonate.
Joe: You mentioned digital transformation. I think a lot of people have observed that it’s one area that the pandemic has had an impact on. Given that certainly one impact is we’re here on a Zoom call and not on some comfy chairs on a stage somewhere, how do you feel the pandemic has impacted Sumo as a company? Just in terms of how you work and get things done.
It’s been a tumultuous year. You also went public this year, which already is a pretty tumultuous thing for a company to do. What’s your kind of feeling on how the pandemic has impacted how we work, down to the customer?
Christian: We can talk about that for hours. First of all, one thing I’ll have to say is that, being at Sumo and for us to do what we’re doing and be able to continue to do what we’re doing, even though it’s a global pandemic and we can’t go back to the office anymore, the fact that we are still employed, as are many of us in the tech industry, we’re really quite blessed to be able to work in such environments, to be able to stay home, fire up our internet, and keep working. Which is not true for a lot of people around me.
In light of all of that, I think what happened this year from a digital transformation point is that, the digital transformation actually accelerated this year. Which is crazy because it was going on pretty quickly, pretty fast.
In many ways, every company now has to figure out how to be digital first. Because they can’t come together and sit in the same chairs anymore.
Slack was worth buying for Salesforce. Look at the Zoom stock and you just don’t even know what to say anymore. Even things that weren’t digital 12 months ago, somebody had to figure out how to make them digital this year in order to keep the business running.
We had an interesting year. We’re, again, very blessed that we managed to get a chance to do the public offering. The company deserves to be public in my view and our employees and our customers deserve to get the benefits from us getting investments to build better products. So in light of this ‘shitstorm,’ we’re sitting in this lucky pocket.
Joe: I’m always curious with businesses like yours. We have a kind of long-term thesis about where this trend is heading and you mentioned Slack. Slack’s one data point in this. What role does the practitioner play? You talked about going way back to traditional enterprise software, a practitioner might have their first experience with the software after the company has literally already purchased a seven figure contract for it.
What role does the practitioner play in adopting Sumo in an organization, and ultimately resulting in a deal for your company?
Christian: It’s obviously a little bit simplified, but we’re a bunch of devs building stuff, selling to devs, right? Devs in this case means DevOps people, but we’re a bunch of technical people building stuff to sell to technical people. I think for executive relationships and the sort of top-down motion, you always want to have some of those connections, for the time that it comes to signing a check. But I do feel for this type of stuff.
Ultimately, you want to evaluate the buyer yourself, you want to have the freedom to figure out whether it works before possibly being called every 20 minutes by somebody who needs a signature because the quarter is closing in. So I think that there’s quite a shift there in how that happened. I cannot speak to how this goes in other industries. In the space that I know, which is essentially Dev/IT-ops, security, etc., there is an incredible amount of bottom-up evaluation and adoption happening and you really need to be on your toes. You need to realize that you can’t shove it down people’s throats. That’s just not going to work anymore.
Being a technical person myself, I love it because a lot of stuff is SaaS, I can almost always easily try it out and figure out whether it’s worth scratching on more.
But again, there’s many different types of shops. You still also need to consider what it takes to get even just a four figure deal, six or seven figures in the larger cases. Send the procurement department to past a founder or a CTO or VP, those folks might not necessarily be the ones driving the evaluation and they will rely heavily on whoever says, “we looked and really liked this thing. We automated our integration with is an it’s already monitoring/serving these three microservices. We really need to go and do a deal here so that we can properly productionize it.”
At that point, the sales person comes in. If it’s only at that point that the sales people come in, it’s also often too late. Because again, you know these are just observability tooling. It’s not a small spend, it’s not la 12 bucks a seat type thing. So I do still think that having sales hygiene in place where you try to get to the folks that ultimately need to write the checks is a useful exercise.
Joe: We tell a lot of our founders that bottom-up go-to-market doesn’t mean no sales. It’s quite the contrary. It’s more about where do leads come from? And particularly if you’re using enterprise as a proxy for where the large deals come from. But how much do they cost you to get them?You still need to meet the customer where they are and walk through procurement with them and have professionals on your team who are skilled at doing that.
So you made the transition, that I think any company that wants to reach the levels of success and distribution that you have, of bringing on that sales hygiene and a sales team to handle those kinds of deals. What was the biggest challenge that you faced in going through that transition as technical product focused co-founders? What’s the one or two things, you wish you could go back in time and tell yourself then how to do?
Christian: When we started adding sales and scaling that up, around 2012 or 2013, this sort of enterprise SaaS thing wasn’t as prevalent as it is today. We thought we were going to sell to enterprises, that was what Oxydata was, it was all we knew. We thought that we wouldn’t go after after three people shops or SMBs. So we just thought to bring in an enterprise focused sales team.
That sales team itself, initially, had tremendous amount of struggle with adoption and selling in a SaaS motion. They struggled with the fact that you don’t just sell to the customer once and then don’t show up ever again. You have to basically prove your value to your customer every year over and over again. The realization of just how incredibly important post-sales and customer success is and how much of your future growth comes from not just the initial sell but in selling again every year.
The flywheel is really what drives our model or the recurring revenue model. And that’s what makes a SaaS company potentially so valuable and sticky, because you go through this motion every year, every year, every year, and you do that and you have 2000 people after 10 years you’ve done that with. You didn’t just sell them a bill of goods and then walk away, that never works. It’s like farming vs. hunting. They’re always going to prefer to go hunting because it’s fun and there’s a big commission. It’s the farming aspect that people had to wrap their head around and learn.
If you look at it from first principles, it’s pretty obvious, but then to operationalize that in a company with leadership is difficult. Just because you think laws of nature are one way, if the folks that you’re working with aren’t privy to that quite yet, just telling them once isn’t going to get them to either because they may have experienced the laws of nature differently for the last 10 to 20 years.
So I would say some of our initial struggles came from, trying to figure out, the right profile of sales and overall GTM approach. But really down to the person. How adaptable were they to selling in a slightly different way from the Oracle way.
Joe: I subscribe to the notion that your early sales hires, as you’re scaling an organization like this are often, somewhat different sales people than the kind later on.
In the early days you need people who listen to customers and are adaptable and flexible to having a product that’s maybe being sold a little bit ahead of where its maturity is at.
Not in terms of like delivering features or selling features that don’t exist, but the fact that it’s early software. There’s sharper edges, whereas I assume later, you’re at a place where you have a very repeatable sales motion that you can probably plug any capable sales person into. On the engineering side, what was the most interesting thing you’ve found scaling from a handful of engineers up to hundreds?
Christian: Let me put it in a sort of Silicon Valley paradox which is that you probably have the best talent pool in the whole world for this type of stuff. But you can’t hire anybody because the competition is so freaking tight. And these days, the larger companies have wizened up and they’ve basically constructed this RSU (restricted stock unit) construct. Now you just wave a bunch of stock options and people are just like, “Okay, whatever.”
The sheer amount of competition, with how well technology is working and how much value is being created, the hiring machines of the big 5. Now, college grads get offers from Google and it makes them rich with minimal risk. All of those things make it a super interesting landscape to navigate and I did not really see it coming. My co-founder is from India and he knew a bunch of people who could start building the product from over there.
We made the decision to do that and learned from scratch what it means to have a product development team. Unlike outsourcing where you send something and they send something back, they were an actual part of the core development team, but they were 13.5 hours away and the time difference was absolutely brutal. But we learned that no matter what you do, you need to build trust with these folks in-person.
It meant being on the plane a lot. That might sound like a waste of your time, but you have to do it. Before COVID, my co-worker running engineering and product, and myself, would go to India and Poland every quarter to build up the second team and hang out for a week. We would do planning and exercises with them. Half of it was just sitting down and having drinks with them so that they could understand where we’re coming from, we could understand where they’re coming from and build that kind of trust that is so hard to establish from scratch virtually.
Joe: Which is something that we’ll find as we emerge from the pandemic hopefully sooner rather than later. But at some eventual point, I do feel like the future of work has permanently shifted to be more flexible, which I think is great. I also built and led distributed teams in the past, before it was cool. I think you’re spot on that as an executive, there’s nothing the human lizard brain, we need the face to face, you need to replenish that human capital that you share with people. You’re right, it feels like a waste of time but it’s probably one of the most important things you can do.
So Sumo, came up in parallel with the rise of cloud, right? In the first wave of cloud, if I remember correctly, was hosted and built on the cloud and AWS originally?
Christian: It still is, yes.
Joe: Ok, so it’s still on AWS. We’ve reached a point in cloud evolution where an entire new way of architectural paradigms are coming up and are using the moniker cloud native. It’s interesting that that’s what we call things that were built on the cloud in 2009. But proper cloud-native infrastructure is, I assumed, things like containerized microservices running on an ephemeral platform, whether that’s a Kubernetes or a Nomad, and maybe there’s some serverless functions in the mix.
How does Sumo span these generations of architectures? What does it mean for Sumo, moving from observing a digital estate to now, cloud-native architecture is a bunch of moving pieces.
Christian: From the perspective of our own architecture of the service, or from the perspective of the value that the product delivers or both?
Joe: Both would be interesting, but let’s let’s start with the latter.
Christian: So here’s another sort of interesting paradox that plays in our favor, which is that, with the rise of cloud and automation, individuals can do even more crazy things on their own, or in smaller groups. Frankly, Kumar and I would have probably not dreamed that we would be able to start a company, a SaaS company, because we’re a bunch of developers. All we know is how to poke a bunch of APIs. We don’t know anything about servers and racks and networking. We know these things exist but we don’t really have any expertise in that.
As a SaaS, you needed to build all this out, but now you don’t anymore. We learned that in 2008 during a talk at Stanford, it was like, “Oh, now I get it. Data as an API, let’s build this thing.”
Joe: Roadblock removed.
Christian: Exactly. This is one of the incredible things about being able to program. You automate the work that a million people would otherwise have to do manually. It’s incredibly empowering. Right now, it’s not just the growth of data growing exponentially, it’s also the amount of power that’s in one’s fingertips that’s growing exponentially. So the good news for all of us in this industry is that, smaller and smaller teams can build cooler and cooler things more quickly at bigger scale.
The flip side is that software was already pretty complex when it was still running on just one machine. Now everything’s distributed, everything’s 24/7. The expectations are that everything is running at web scale. You’re plugging together all these incredible Legos from AWS to Google to Kubernetes and trying to build something. There’s an incredible amount of moving pieces in place. Some of them you own, some of them, you don’t.
I think moving forward, for what we are doing in observability and reliability management and security as well, it’s become more and more important that you can actually have, what we call ‘continuous intelligence.’ That you can actually have insight into what’s going on in the systems that drive you business 24/7. If you’re building a startup that’s building, it doesn’t matter. If you’re building a system that’s live 24/7, you need something like Sumo in order to survive.
Joe: Naively I guess, I always tend to think that, if you think of observability and you think of a hierarchy of needs, the fundamental atom of observability is a log message. There’s all kinds of higher-level, more sophisticated primitives that allow you to do different things, whether it’s full-on distributed tracing, ad hoc queries on more structured data, or APM, but at the end of the day, you always come back to logs. Observability of last resort is your logs. You see that being the case with people driving these cutting edge architectures? Is that still the case?
Christian: Yeah, absolutely. Some folks start with logs and end with logs. A lot of folks started with time series and ended with logs. They always end with logs. That has not changed. You might find that people claim differently, that’s fine, that’s their right. Personally, from what I observe of our customers and our prospects and what they see in industry, I’m a big fan of times series. I argued super hard for us to adopt it into the product and build it into our initial system back in 2010. I’m not a log fanatic, but the reality is that, when it all comes down to the wire, if you don’t have the logs, you’re going to look pretty silly.
Joe: Yeah, that makes sense.
Christian: You can see it in the postmortems. Let’s say half of the internet fails because of Kinesis going down. You look at the postmortem and they’ve got an alarm and then they started looking at the logs. The logs are events and there could be spans and traces and in my mind, it all boils down to a bunch of messages with structure.
Joe: We’ve talked about, and you’ve mentioned, that the digital transformation has accelerated this year because everything’s digital now. The first part of the question is, are you actually seeing that in the business? Are you seeing the business somewhat accelerate because underlying macro digital transformation is accelerating. And then the second part of the question is where you think observability is in terms of its adoption curve of market size? Are we in the super early innings or are we more in the mid-game?
Christian: People have been using APM since the 18th century, they’ve been using time series since before that, logs since the birth of Christ. None of this stuff is actually new. What is new around observability is that there’s a product that brings all of these things together. I don’t really know where in the game that is, I think it’s an evergreen thing. I don’t think it’s early at all because the early part is refocusing from best of free to suite.
It’s a cyclical thing that always happens in software, until somebody figures out a better breed and then everybody goes after that and the suites suddenly look old. We’ve seen the big four monitoring platforms, they were in a very different world than what we live in today. Observability is something that vendors have slapped on their website probably only for the last year or two.
For a long time, a few folks have figured out that, just alerting on CPU usage isn’t good enough. You want to look at more customer-centric stuff, you want to probably have some sort of SLO (service level objectives) in place. As we bring telemetries together in combined tools, it’s more powerful to use a better correlation. Maybe the detection gets abbreviated and the workflows for resolution, get accelerated. But people have been doing it before, except with 50 different products. The need to run reliable services is as old as running services, if that makes any sense.
Joe: I do want to close with one last question, a little more open-ended. At Heavybit, we work with lots of early stage founders who are sitting where you were anywhere from 2009-2010 to 2012-2013. Looking forward to 2021, what advice do you give early founders who are like, “what should we be looking out for? What should we do? How should we think about this?”
Christian: Go for it. Look at where the world is, especially, when it comes to software. We could not live in a better time. If you like to do software, to solve problems, whether it’s for technical people or people otherwise. If software is your way of expressing yourself, whether it’s by actually writing the software yourself or by figuring out a product that the software will instantiate or by figuring out a business model that you will then have product and engineering people help you flesh out, this is beautiful, there’s gold everywhere.
The digital transformation, I don’t want to keep belaboring it but you look at the numbers, it’s absolutely ridiculous. Growing up, I had a little Atari home computer, when I was 11 I taught myself programming. So I’ve been around computers for a long time and computers have been running businesses for a while, what’s new about that? But the digital transformation orientation really is new. And some of us have been living in this privileged world where everything was anyways digital for a long time. But that’s not really true worldwide. This stuff is still rising.
What better time to be affiliated with software. Geat businesses get born all the time in difficult times. Maybe not the very month that the financial system breaks down, but the next month, because it happens. Have no fear, just go for it. I always thought getting funding was impossible. But the reality is, if you are in software, if you have even a little bit of social proof, by being around Silicon Valley or Austin or wherever folks hang out, where you have an ecosystem, where you have folks who understand software and software people and people who like to use software to build stuff. Most people can pull this off.
If you have an aptitude for it then the investors will come to know about it and they will want to talk to you. So never think that you have to go in begging. You have something that’s unique. Or maybe you don’t and you won’t get funded but don’t think that you don’t also have some power in the game.
Joe: Sitting on the other side of the table like I have the last couple of years, I echo you in saying that venture is shifting more and more to a services industry, where we’re competing to work with the best founders and companies and it’s not the other way around, which it used to be. I think you’re right. People should be positive and go build. There’s going to be some incredible companies built in the coming years and the fallout from this. Christian, I can’t thank you enough for spending the time with us today.