Friday 21 December 2018

Podcast Interview with Emil Eifrem, Neo4j

We've been around the block a few times in this podcast. It has been a fantastic experience to develop this thing from a crazy idea at a booth at Qcon (thanks again, Michael!) into something that has really gained a life of its own. I for one still enjoy making them time after time - I hope they are a good listen/read as well.

As part of that journey,  I have course also interviewed our "Fearless Leader" and "Chief Instigator", aka Emil Eifrem, a few times. We talked in summer of 2015, and then again around this time of the year in 2016 -  and swore expensive oaths not to let another episode be too long after. And we failed miserably. So it felt right to do a longer, more elaborate episode now, which we actually published with video on Youtube too:

Of course the Podcast feed and Soundcloud have the same show episode too:

Here's the transcript of our conversation:
RVB:   00:00:54.475 Hello, everyone. My name is Rik, Rik Van Bruggen, from Neo4j and here I am recording another podcast episode. And I think the other person on the other side of this call is going to agree that it's been way too long.

EE:  00:01:08.540 It has been way too long.

RVB:   00:01:11.428 Hello, Emil. It's been such long time since we done a podcast together.

EE:  00:01:15.399 It has, and we all know who to blame for that.

RVB:   00:01:18.973 It's me. I know. I know. I know. Sorry. Sorry. I apologize. But thank you for coming back. It's the end of 2018. Christmas is upon us. So it feels like it's a good time to kind of review and see where we are. And--

EE:  00:01:37.488 Is this your Christmas gift to me, that you finally invite me back?

RVB:   00:01:42.741 Yes, it is. So, Emil, so many things to talk about, obviously, right? But our dear friend, Luke Gannon, from the Neo4j professional services team sent me this really interesting tweeted idea from a guy called David Perell on things to talk about on a corporate podcast. And it, well, was more for an internal podcast, but I think we can do our own version of that. Is that okay for you?

EE:  00:02:13.910 Sounds awesome.

RVB:   00:02:15.064 Sounds great. So the first thing I'd love to have a chat with you about is a little bit of a historical view, where did we come from, but also vision. What do you think we need to be doing with Neo4j, and what's your more long-term-oriented idea of what we contribute to the industry?

EE:  00:02:40.328 Yeah. I guess there's two parts of that. One is kind of history, looking backwards. The other one is kind of vision and future, looking forwards, right? So let me, I guess, start chronologically then. Basically, I've been doing this for all my professional life in one way, shape, or form. I grew up as a hacker. I really got my probably quasi-professional feet wet, if you will, in the early parts of the internet doing online role-playing games, like text-based role-playing games, so the equivalent of World of Warcraft or something like that. I'm sure there's way more modern and updated versions of that, but like online fantasy-based games, right? But they were text-based. This is in the early '90s. I was a teenager at the time, but really started running these, and they were called MUDs at the time. I started doing them and at one point, I was involved, co-founded one of the more popular ones on the internet. At peak, it had like 100 players at the same time or something like that, which was, hey, that was a significant fraction of the internet in the early '90s, right?

EE:  00:04:03.032 Of course. Yeah. Yeah.

RVB:   00:04:03.647 And then fast forward a couple of years, and I was working as a professional programmer in the late '90s, early 2000s, at an enterprise content management startup based [in Sweden?]. I rapidly grew to become the CTO and found that half of my team-- we were about probably 20 engineers, something like that. And half of them spent the majority of their time fighting against the database. And we used like the classic stack that people used at the time, which was a relational database, a business layer and an application server and then a presentation, web-front-type presentation layer, right? And in all my previous projects, the database had been a help. It had been an accelerator, right? But for some reason, it was really slowing us down, and that reason we now know-- like, I think as an industry, we have a language for it and a much crisper understanding. But it took us a while to figure it out. But in a nutshell, it was that there was this mismatch between the shape of the data that we worked with and the abstractions that were exposed, the building blocks that were exposed by the relational database. So we deal with content management, so that's files that belong to folders and folders that belong to those folders, but just a big kind of connected thing, and then we had this big security hierarchy where we have Rik, and Rik belongs to, let's say, product marketing, which is a group. That group, in turn, belongs to both the marketing group and the product management group. And then you have to connect that security kind of hierarchical, but actually, more than hierarchical, structure with the content structure, which is also hierarchical, or even more than that, and that just becomes a big mess of connected data.

EE:  00:05:54.619 And we took all that, which was rapidly evolving - you had to resolve these permissions very rapidly - and just stored that in tables. And that worked. It is mathematically proven that you can store anything in a relational database, right? So it worked. But it was just very painful. It took a long time, just purely from a developer productivity perspective. It was also really slow in a runtime perspective, just purely performance, because you ended up with a lot of joins, which we know are one of the most, if not the most, powerful mechanism you have in a relational database, but also really, really expensive to do. So that was kind of the birth of it. We looked at that and saw that, huh. Weird. Why do only we have this problem? There must be other domains where there's so much connected data. And then we kind of thought a little bit. It's like, "Okay. So probably other people have it today. What about tomorrow? Do we believe that there's going to be more or less connectivity in the world going forward, right?" And ultimately, I guess, data models the real world. As the real world is becoming more and more connected, data will become more and more connected, and connected data exerts this pressure, this tension, on the relational database paradigm. As every day goes on, that pressure will just be stronger and stronger.

EE:  00:07:15.926 And back in the early 2000s, we couldn't say that, "Hey, exactly this particular date, it's going to break for most applications." But we did we feel like we're on the right side of history here. Over time, there's just going to be more and more applications where there's going to be so much connected data. There's going to be so much value in querying across relationships, across connections, that people will start to move away from the relational database. And not abandon it. They will augment it. Put the connected data somewhere else.

RVB:   00:07:48.003 And did that already make you feel like you were going to be able to answer different questions because of that, or was it more of a speed thing that you were looking for at the time? Or what was the main driver there?

EE:  00:08:00.342 Yeah. It was more the latter. It was more that we saw this pain that we experienced already, not to do novel things, but just to do basic things, right? We wanted to do basic things that just involved a lot of connections, right? And we felt that, hey, if we perceive X amount of pain today, there's going to be more people with that level of pain, X, right? But also, in this particular domain, it's going to be even more connected, so we're going to do 10X pain tomorrow, right, for some definition of tomorrow. So we only thought about it-- at least, I only thought about it from that perspective. Now, of course, fast forward to today. We know that this has unlocked all kinds of new things that was just not previously possible.

RVB:   00:08:41.679 All right. Well, let's talk a little bit about that because I've seen you on stage a bunch of times, and we want to help the world make sense of data, right?

EE:  00:08:50.903 Yes. That sounds familiar.

RVB:   00:08:51.685 And it does sound familiar. I don't know who wrote it, I mean. But what does that mean today? I mean, we talk about things like ICIJ, Panama Papers. We talk about NASA. How do you think that making sense of data, how we should look at that today, and how that's going to evolve into the future?

EE:  00:09:14.546 Yeah. I mean, so maybe to back up a little bit for podcast listeners, so help the world to make sense of data is our mission statement, right? And it's fairly [inaudible] worded. It is help. It doesn't say do it, right? So maybe Google's, at least their original mission, was something like, "Organize the world's information. Make it universally findable." Something like that, right? So very clearly, they are going to do it themselves. That's not what we do. We are tool-builders. We enable other people to do things. I listened to a podcast interview with Satya Nadella a couple of months ago, and he said something very interesting about Microsoft. He said, "Basically, when I, Satya, talk to potential new employees and they ask me, 'Hey, why should I join Microsoft? Why shouldn't I join' - I don't know - 'Facebook or Google or whatever, right?'" And what Satya then told them is that, "Hey, it's very simple. If you want to be cool, you should work at these other companies. If you want to enable other people to be cool, you should work at Microsoft." And that's actually very much how I look at Neo4j as well, right? We don't organize the world's information. We don't ourselves make sense of a lot of data, right? But we help other people do it. So that's kind of the help part of it.

EE:  00:10:40.852 And then we say-- I don't think I need to talk about, make sense of data, why that's valuable. I think a lot of people appreciate how important that is in order to have kind of data-driven, fact-driven discussions and decision-making. But then we say the world, and that's ultimately very ambitious, obviously, right? But it really is how I think about it. We don't just want to build tools and technologies for, I don't know, big pharma companies in North America, right, or financial services companies in London or hipster startups in South Hill market in San Francisco, right? Ultimately, we want to help everyone make sense of data, and that's really, really ambitious. And we try to be smart about it and you don't go to the market by building something for everyone. That's just not a smart way to do it. So there's a sequencing involved there, right? Currently, as you well know, we're focused on businesses, I mean, particular on the commercial side. Primarily, we're focused on big enterprises, right, because that's just a smart way of starting things out. But two, three decades from now, I can definitely see us targeting much more broader than that.

RVB:   00:11:59.517 Absolutely. Well, I mean, maybe that's a good segue to talk a little bit about our industry, right? It's been two years since we spoke and man, has that changed a little bit, right?

EE:  00:12:12.533 It has.

RVB:   00:12:13.975 It's been quite a journey. But you see lots of other people starting to talk about graphs. Every man and their dog has a graph feature these days. Then you see big behemoths like Amazon with the Neptune offering. You see other companies offering new technologies. What's your view on the industry these days? How do you look at that?

EE:  00:12:45.578 Yeah. And it's a good question. So when we got started, we came up with this kind of crazy notion that you could build a new type of database with a new data model, right? And we weren't the only people that saw that the world was connected and that like a graph perspective, a connected data perspective, was valuable. A notable example is the RDF people, right? So RDF, I don't remember anymore off the top of my head, but I feel like RDF was probably formalized in like '97 or something like that, right? So a long time ago, even before we got started, right? So there's been a lot of other people who have thought of it in that way. But we really moved it into databases, and kind of our particular angle on connected data was what's now known as the property graph model, right, which I think is standing the test of time in terms of adoption as a really pragmatic approach, a really developer-friendly approach to model connected data. But back when we invented it, it wasn't clear how we would bring it to market, right? You could imagine, for example, that we could've brought it to the market as something like, "Hey, we're a database accelerator. We live right next to your real database," also known as the relational database, right, "and we make some queries go faster," right? [crosstalk]--

RVB:   00:14:05.992 Like a cache or something.

EE:  00:14:07.455 Yeah. Like a cache or like an index or something like that. That would be a completely viable path to market for the technology we had invented in the early 2000s, right? But we felt that no, this is so important and it's going to be increasingly important over time that it deserves its own category, right? So Neo4j is an X. Solve for X. What is X, right? You could call it a database. That kind of undersells it because it's qualitatively very different from the relational database and ultimately, of course, you know this story, what we ended up with was graph database. We tried out a bunch of different things. We tried network-oriented database. We tried netbase, like network plus database. We tried a bunch of different things and it didn't work, but then when we used the word graph database, it just connected with people, no pun intended. But it just resonated, right? And when you choose a category creation approach, initially, you're all alone, right? My most recent example for this is Levi Strauss, right? When they invented a new type of pants called jeans, right, they were the only ones who had jeans and they could've called it pants, but that would have [inaudible]-- they are different than other pants. Of course, they are pants. They're different than other pants, right? And so initially, they were the only provider of jeans, right? Now, of course, fast forward to today and all the pants companies or whatever [inaudible], they now carry jeans, right? They have their own model of jeans and that's exactly what we now have seen unfold for us, right?

EE:  00:15:46.807 Basically, all the big enterprise software vendors, right, now have graph database offerings with various level of maturity, and that is a sign of success. As you well know from the inside, I've been saying forever that hey, you know what? We're very alone right now, but the only way that we can stay alone is if we're not doing something that is valuable enough, right? Because if it's valuable, then other people will come in and compete against us. And I think what we've seen, what has been pretty mind-blowing to me, it's been two years since we did this podcast that, I guess, was end in '16. Two years preceding that in 2014, Forrester did this research note on the emerging graph database market. And they were very early at the time of looking at this. And they made this amazing prediction that you've seen me use in slides a gazillion times back in 2014 where they said, "Three years from now, in 2017, 25% of the world's enterprises will be using a graph database."

EE:  00:16:55.557 And I remember back in 2014 when I saw that, I was like, "That's awesome. Yeah, yeah, yeah." And to myself, I'm like, "Those guys are crazy. It can never go that fast." And then, of course, a year ago, when I was on stage at GraphConnect, our annual conference in New York, as I was prepping for that, it was very timely because Forrester then released an updated report where they interviewed over 2,200 enterprises and asked all kinds of questions about, "Are you using graph database? Do you plan on using graph database?" and so on and so forth. And the result that came back was that over 50% - I think the exact number was 51% - of the enterprises, the 2,200 enterprises that they surveyed, were actually using a graph database. [crosstalk]--

RVB:   00:17:44.601 [crosstalk] way more.

EE:  00:17:45.975 Even more than what I thought was kind of a crazy thing. And I'm, of course, kind of the relentless optimist about graph database options, right? And so when you look at something like that, then you realize that of course, Oracle is going to enter the market. Of course, Microsoft is going to enter the market. Of course, Amazon is going to enter the market. And as kind of the early defining, the, I think, objectively-- of course, I'm extremely biased here, but the objectively, we're the leader today if you look at any kind of external metrics. That's both a scary and an amazing thing, right? It is scary because it's competition. It is from some of the biggest companies on the planet: Amazon, Oracle, Microsoft, right? But by and large, it's much more of a positive than a negative thing because I think I 100% still believe that the biggest competition that we have is unawareness. It's people that have a problem because of connected data but they don't think of it in that way. They think, "My database is slow," or, "My fraud detection application doesn't detect enough fraud," or, "My recommendations are too bad," or something like that. I mean, so they think of the symptoms, but the actual root cause is that they have connected data trapped in a form that is not good for it, for example, a relational database, and they can't operate on it, right? And more people that can preach that and get the word out of that is a massively net positive for us.

RVB:   00:19:28.999 Couldn't agree more. Well, and that kind of begs the question, how is Neo4j as a company doing, right? I mean, we had this fantastic announcement in, I think, 1st of November was it, when we closed another funding round, [E-round?]? Which obviously, for us internally is always a great validation. We're happy about it. It enables a bunch of things, but as a company, at the end of the day, someday we'll have to make money and we'll have to make sure that our shareholders get their fair reward.

EE:  00:20:09.142 Yes. Because both of us are shareholders. Yeah.

RVB:   00:20:13.486 Very, very correct. Yes, absolutely. Yeah. But I just want to get your perspective on how is the company doing from your perspective? I mean, it's 250 people these days, all continents, spread all over. Big engineering group. Big sales group. How is the company doing from your perspective?

EE:  00:20:35.123 I think we're in a really healthy spot right now. I think that one of the things that we talked about back in 2016 I remember was we had just raised funding back then. Is that your algorithm, by the way? You're only willing to speak to me on the podcast to raise money?

RVB:   00:20:51.215 [inaudible].

EE:  00:20:53.083 Because that means it may not be another podcast episode [inaudible].

RVB:   00:20:57.058 Well, we'll see IPO, right? IPO, that's when [inaudible].

EE:  00:20:58.951 Yeah. Post-IPO. Then I'm worthy to be invited back. No, but one of the things that I remember us talking about back in 2016 is that we've always approached it a little bit differently, right? And being a Silicon Valley company but with European roots, if you look around in the Valley, one of the things that you see is that there's a very tried, true, and proven model for how to build these companies, and it's basically you raise crapload of money, and that's a technical term, by the way. A crapload of money and then you build a product, and you open source it if it's an infrastructure, kind of developer-facing product. Or you already open source it. Then you raise money on the back of that. And then you build up a small organization, you get it out there in as many, many hands as possible. You talk about maybe eyeballs. You talk about download numbers, adoption numbers, and things like that. On the back of that, you raise even more money. And then maybe you start selling a little bit. And then you sell the company.

RVB:   00:22:02.718 Yep. Before [inaudible].

EE:  00:22:04.320 Yeah. And that's a little bit tongue-in-cheek because there's a lot of great companies. There's a new generation of open-source companies that I admire. There's some more recently public ones like MuleSoft, like Elastic, like Mongo, that I think are really high-quality companies. There is a crop of private companies as well, like Confluent, the Kafka company, for example, that are building it in a different way. But by and large, that's a little bit the value model. And I've never subscribed to that. I've always felt that yes, of course, it's infrastructure software and when you go up against huge competitors, Amazon has a massive balance sheet. Oracle has a massive balance sheet, right? Then it really helps in order to have investor funding. But by and large, I want to run this in a customer-funded fashion, right? I want to grow alongside our customers because that's just a much more healthy way of building a business, and I'm trying to kind of do this mix of, let's call it a more kind of European way of running it versus a more Silicon Valley way of running it. And I don't want to be exclusive in either bucket. I think there's a happy middle path in there. And I think so far, I've been extremely happy with how we've executed on that.

RVB:   00:23:30.443 Well, I would agree, right? I mean, I remember actually, not long after we did our last podcast, there was this blip in the submarket in Silicon Valley, early 2017, right? And internally, we went through this phase where actually, we turned to cash [inaudible] really, really quickly, right? It was a really great example of how you could actually control your own destiny much, much, much safely that way.

EE:  00:24:00.142 And I think that is just a really important constraint for me. That's how I look at it. No matter how much money we raised, and obviously, the series like $80 million, that's a lot of money, right? But no matter how much money we raise, I always want to make sure that we can get to cash flow positive without drastic things like hey, let's RIF, which is in America, RIF is like reduction in force, right?

RVB:   00:24:25.645 I don't [inaudible].

EE:  00:24:26.483 Yeah. Yeah. Let's lay off a third of the company. Then, of course, you can get to cash flow positive, but no. I want to be able to get to cash flow positive and control our own destiny without anything drastic like that. And I'm the last guy you should talk about when it comes to predicting the stock market. I am consistently wrong about that. But I do feel, look, we're at ten-year, all-time high type thing, and as we're recording this in December of 2018, the past month or so, you've seen a lot of fluctuation on the stock market. In the next few years, again, I've been consistently wrong when I've been predicting stuff like that. I still think that there's going to be something pretty dramatic.

RVB:   00:25:13.830 Some [correction?].

EE:  00:25:14.666 Yeah. There's going to be some big correction. And then, being able to meter your investment and come back to cash flow positive if you need to is just a really fundamentally healthy thing.

RVB:   00:25:27.533 I agree. I have two more things that I wanted to chat to you about. And this other guy, David Perell, he was suggesting that we talk a little bit about how decisions are made inside a company. And it's a really fascinating one because [internally?] [inaudible] about this whole idea of trying to get the consensus without gridlock, without deadlocking, and making sure that we get things done, but at the same time respect each other in getting to those decisions. And recently, I mean, the last twelve months, we've done some massive changes to our leadership team, right? And people that make decisions like Lance Walter or Mike Asher or Denise Persson, now on the board, those are really important people because they will influence decisions in a major way, right? So I was wondering how you look at decision-making, but also the changes that you've made to the management team, to the board. Interesting topic, I think.

EE:  00:26:39.617 Yeah. Yeah. For sure. Yeah. This is always the topic that we could do five podcasts just on this one because I spend a lot of time thinking about this and I have pretty strong opinions about it. But I mean, I think in a nutshell, there's always this balance, I think, in an organization between a more authoritative way of running the company versus a more consensus way of running the company. And I think there's no doubt that at both of the extremes are really bad. I think most people would agree to that. However, reasonable people can disagree kind of in the very broad midrange of that spectrum where you should be. And in that broad midrange of the spectrum, I gravitate much more towards consensus, and consensus is a funny thing, right? Because as you know, I'm a freaky mix of European and American, right, in that I've lived whatever, eight, nine years of my life in the US but I was born in Europe. And what I've learned in American business culture, consensus is seen as a very, very bad thing. And what it took me a while to understand was that what people perceived as consensus was waiting for everyone to agree before you execute. And that's horrible. If that is your management style, that's a really, really inefficient-- I mean, Darwin will make sure that those companies [inaudible].

EE:  00:28:12.678 So you don't survive for long if that's how you operate. But having said, so I call that bad consensus. And what I call good consensus, however, is when you have a very clear decision-making process that for every single decision, it's very clear who owns that decision, who is accountable for that particular decision. And when the people then execute along that, let's say there's a project with 3, 4 people who are going to do something, right? And maybe it is an internal systems cleanup. Maybe we're migrating to a new CRN or maybe it's a customer project. Maybe it is like a product road map project or something like that. If you have a tight, small group that is going to execute on that, as long as you hire smart people who are really committed, it's way more efficient. They will execute much, much better if they are aligned with that direction, if you get them to buy into that direction. That is always what I optimize for. I want those people to agree.

EE:  00:29:24.215 Now, if you're looking at 200 people, you can't get 200 people to agree. But anyway, 200 people aren't working on a singular task anyway, right? But if you have that small group of people and you can get them all to agree that this is the direction that we're going, they will just execute better. And why? Because ultimately, I think one of the strongest powers in the universe is intrinsic motivation. Intrinsic motivation. When you do something not because we dangled dollars or Euros before you, but you do something, you want to go to a place, because you intrinsically believe it's important to go there, right?

RVB:   00:30:03.020 You want to go there. Yeah.

EE:  00:30:04.239 Exactly, right? And part of unlocking that is getting people to agree that that's the best way to go. Now, it's really important to pair that up, and this is to your point about bad consensus, which has these deadlock problems, right, which actually has all kinds of symmetry with distributed transactions and things like that, which let's not get into that. [inaudible] avoid that, you need a couple that would disagree and then commit. And disagree and then commit is the fact that for every one of these decisions - I mentioned that before - it has to be clear who actually owns that decision. And it's up to them to say, "All right. Hey, guys. We've debated enough. We're not going to get to agreement here. Now, let's disagree and then commit." And then we need to have a really strong culture of actually, when the person who's in charge of making that particular decision is pointing in that direction, now it's not a democracy where I'm going to disagree but I'm still going to commit to that direction. And so that's one of the most important tenets, or how I want to run the company. So I think that was 1A of your question.

EE:  00:31:13.757 And in terms of 1B, yeah, I mean, there's been a lot of changes, I think, since early '17. Like half of the management team has changed in some way, shape, or form. Fawad Zakariya joined us [inaudible] leader in, I guess, summer of '17. You mentioned Lance Walter who joined us, our new CMO, I think Jan of this year, so I guess about a year ago. Mike Asher joined us, our first CFO, this summer. We've done a lot of changes on the board in conjunction with this funding round. Also added a new independent, Denise Persson, who's the CMO of Snowflake. So there's been a lot of changes in the past twelve to eighteen months, and the way that I look at that is just as a very natural part of the growing up process, right? You now look between the board and the management team, you have a lot of people with experience taking companies public, but also selling companies to bigger companies, right? And as you and I have talked about many times and as I talk about in onboarding and actually, also in interviews with candidates is that obviously, we've raised money and we talked about kind of fiduciary duty to shareholders before. I mean, that's one of the most important jobs of the CEO, and I do take that really, really seriously. This is a lot of real money that have gone into the company, like pension fund money and I mean, that's not nothing. And I think it's really important that we return that capital, right, and give them really good returns.

EE:  00:33:01.554 Having said that, in my day-to-day, I don't think about that. I don't think about IPO. I don't think about selling the company. I think about building a really high-quality, good company, building a product that people love, solving real problems for real customers who are willing to part with some of their lovely dollars because it's so valuable that we solve those problems, right? If you do that and you focus on that, all else will follow.

RVB:   00:33:31.553 Such a beautiful note.

EE:  00:33:33.738 [inaudible].

RVB:   00:33:35.644 [inaudible] [end of the year?]. [inaudible]. We could've ended there, but I have one more thing that I wanted to ask you. It's about the future. It's about plans for oh, the company, but also the products and what's driving our success in the market really, right? What's your take on that? What's your crystal ball say?

EE:  00:34:06.479 Wow. That's a broad question.

RVB:   00:34:09.803 Well, I'm curious way you'll take it.

EE:  00:34:13.531 I mean, there's a lot to say. That's another four, five podcasts if we so choose. Well, I guess let me choose one particular angle on it. Let me add two things together that we talked about in the podcast so far. One is that Forrester prediction, that 25% that they predicted back in 2014 that ended up being more than 50%. And then let's take the recent round of funding that we did. So if you look today, over seventy-five of the Fortune 100 are now using Neo4j. Twenty of the twenty-five biggest banks in the world are now using Neo4j. Seven of the ten biggest retailers. Four of the five biggest telcos. These are some pretty amazing numbers, right?

RVB:   00:35:08.943 Of course. Yeah.

EE:  00:35:09.668 And it speaks a lot-- it says a lot about the value of using connected data, right? And the way that I think about that is that I now look at the past ten, fifteen years of my life, and I see two broad waves of graph adoption. And what I start seeing right now is this early embryonic phase of a third massive wave of graph adoption. And the first wave was very clearly what happened in the early 2000s in the consumer web, right? This is the stuff that we've talked about so many times where Google came into the web search market and they said, "Hey, we're going to do everything identical to how Yahoo and AltaVista and [inaudible] and all these other search companies, how they do it. We're going to download all the web pages in the world, and when you search for Rik Van Bruggen, I'm going to look inside of each and every one of these documents. But on top of that, we're also going to extract how they're connected and we're going to rank the search results based on that." And that's page rank, right? That one innovation unlocked the most valuable company of that era, right? Google, right?

EE:  00:36:31.093 And the same is, of course, true for LinkedIn, which, if you compare it to the other professional kind of, I guess, recruiting sites - [],, and so on and so forth - the one innovation that LinkedIn had was not only did they store the profiles and the jobs that were available, but they stored how people were connected to each other, the professional network. And we can go on. There's so many examples of this. If you just add up some of the most obvious examples of companies that have gone into their respective market and reshaped it around connected data, used connected data to build much better products, that's over a trillion dollars worth of market [inaudible]. Over a trillion dollars worth of market [inaudible]. That's pretty amazing. I see that as the first wave of graph adoption.

EE:  00:37:17.651 The second wave of graph adoption is what we are surfing right now. That's the seventy-six of the Fortune 100. That's exactly the same thing that happened in the consumer web, but in the enterprise, right? And that's the enterprise taking their existing, standard use cases, things like fraud detection, which existed before connected data. It just used isolated data. And then they start building much better fraud detection with this, which exerts competitive pressure on the banks that aren't using connected data for fraud detection because the ones that do capture more fraud, right? And that means something in the market. And the same with recommendations, right? There were recommendations before people used connected data, but now with connected data, they can do better recommendations, which would drive more top line for the retailers, which would exert competitive pressure on them. So that's the second wave of graph adoptions.

EE:  00:38:10.528 What I see right now is what I believe is the third wave of graph adoption is what's going on in AI and machine learning. And one of the most exciting research paper that was published, I think, this year in that world was really, an amazing group of Blue Chip AI researchers. These are the Google DeepMind people. It's a bunch of people from MIT. And there's just this absolute top-tier AI researcher-authored paper which basically says, in order to take the next step in deep learning and machine learning, we have to look at graphs. And of course, one of the key things that we see emerging right now - and you see it out in the field, right, and I see it; I talked about it at GraphConnect - is people using connected data to provide better predictive capabilities for AI and machine learning. I think that is as big of a wave as what's been going on for five years now inside of the enterprise, and the enterprise is taking their standard applications-- not new applications, standard applications, and power them with connected data. Right now, we're starting to see the early, the first innings, if you want to use a sports metaphor, a baseball sports metaphor, which I'm as clueless as you are, probably, fellow European. We're in the first inning of that happening in AI. And that, I think, is going to be just this massive wave for anyone in the broader graph technology landscape over the next ten-plus years to come.

RVB:   00:39:49.621 We've seen some fantastic examples of that already, right, with customers and users of [inaudible]. It's been really great. Well, that's a really positive note to end on.

EE:  00:39:59.630 I thought so.

RVB:   00:40:00.743 I think so too. Thank you so much for joining me, Emil. It's been a pleasure talking to you again. And again, we're going to end with one last promise, right?

EE:  00:40:11.742 Yes. Let's not make it-- last time we said let's not make it eighteen months and then we made it twenty-four months.

RVB:   00:40:18.006 Exactly.

EE:  00:40:18.561 How are we going to live up to this now? I think we've lost our credibility here.

RVB:   00:40:23.070 Damn it. Damn it. But at the latest, after the IPO, right?

EE:  00:40:27.401 [inaudible] after the IPO. Okay. [inaudible].

RVB:   00:40:30.954 We'll talk before.

EE:  00:40:32.543 At least now we're sandbagging the numbers, so for sure, we're going to be able to deliver on this one.

Subscribing to the podcast is easy: just add the rss feed or add us in iTunes! Hope you'll enjoy it!
All the best


No comments:

Post a Comment