RVB: 00:00:00.946 Hello, everyone. My name is Rik, Rik Van Bruggen from Neo4j, and I'm super, super, super, super, super, super happy to be on this graph value quest with my partner in crime, Stefan. Hi, Stefan. How are you?
SW: 00:00:17.834 [inaudible]. That was a drumroll that you all requested in the previous episodes comments. It was me beatboxing. Let's make sure that that never happen again. It was painful. It was annoying. But I am happy to be here seeing the end of the line or the beginning of a new journey, maybe.
RVB: 00:00:40.807 I know. I know. So yeah, this is the fifth episode and final episode, I think, in this series that me and Stefan were trying to develop to try and help our graph community to better understand, better develop, better communicate the value of graphs. It's a bit of a interesting set of material that we've put together, by no means scientific, but it's been a great journey so far. So we talked about, "Why are we doing this?" first of all in the first episode. We created a little bit of a map with some techniques to find the graphiest use case. We talked about how you build the case and some techniques to build the value case in actual fact. And then last episode, we talked about some of the presentation techniques that you might be able to use and communicate that value case. And I've got a frog in my throat. That's great.
SW: 00:01:46.854 That's great. So let's talk a little bit so the frog can turn into a prince. Are you good to talk now, Rik, or should I just keep talking? By now, Rik is already dead, so I'm going to pretend to be Rik. Hello, this is Rik Van Bruggen. Oh, hello, Rik. How are you? I--
RVB: 00:02:04.257 I'm doing--
SW: 00:02:04.414 --have a frog in-- oh, he's back. He's back. He's back. Very good. We should, of course, cut that out, but we won't--
RVB: 00:02:11.497 Yeah. We won't.
SW: 00:02:11.898 --because it's all about putting it out there, so.
RVB: 00:02:14.208 Damn it. So no, what we're going to do in this episode when the frog disappears is to kind of wrap it all up by talking a little bit about, okay, so if we have this fantastic graph value case, if we've got this fantastic graphy idea and we have put the numbers together to articulate the greatness of that idea and we have communicated that, we have presented that to our different stakeholders, then the most important thing and the final thing that we absolutely, absolutely need to do is to make sure that that value materialises. Right?
SW: 00:02:54.793 Exactly.
RVB: 00:02:55.910 It would be such a shame if we did all that work and then have it all fall apart. Right?
SW: 00:03:03.019 Yeah. It's like this old kind of quote miscredited to Yogi Berra very often. In theory, there is no difference between theory and practice. In practice, there actually is. Right? And I think this is a good reminder. Right? Just because you sold it, it doesn't mean it's done. Right? Because you will eventually learn that some things actually needs to change and so on. So super interesting. Let's see how we actually make it into an actual valuable graph project.
RVB: 00:03:35.114 Yeah. That's the thing. Right? So theoretical value has no value. Right? We need to actually make it happen. And so that means that we have to translate it into some kind of a project. Right? I mean, these things don't automatically appear from one day to the other. We need to run a little bit of a project. It doesn't have to be a huge project, but it has to be some kind of a project, usually. And if we want to maximise our chances of success for that project, I think structuring it the right way is crucially important. So my question to you, Stefan, is-- and I bumped into my headset there. My question to you is, what do you think are some of the key things that we should be doing to structure the graph project in the right way?
SW: 00:04:21.430 Yeah. I think always, as we talked about, value very, very quickly, right, and use tools for demonstrating that. It doesn't have to be a finished solution. And there is this very good quote that I pick up from Baba at Stanford about prototyping. Right? So if you build a polished prototype, others will see flaws. If you build a rough prototype, others will see potential. And this is a good reminder that if you're not keeping the people in the loop and present a final thing, maybe it's the final thing to the wrong problem that they are not interested to have been solved. So don't wait until the last second, but really take people into consideration in the beginning. Right? Start small and then kind of expand and traverse out from there because that will take you to places you didn't know that you wanted to go to, which is the whole idea of the graph. Right? You have more knowledge than what you know that you didn't know that you wanted to know kind of a thing. So that's a very good point, and that leads very quickly into the different kind of ways. Right? If you're going into unchartered territory or into the unknown, it's very hard to use a process of waterfall. Right? You need to have an agile process. But very often I see that we think that we have an agile process but very often we actually haven't. So kind of be open and think about those things and--
RVB: 00:05:49.498 Yeah. I think it also relates to some of the discussions that we had in previous episodes in the sense that when we are choosing the project, when we are choosing the use case that we're going to develop a value case for, right, you should be mindful of the fact that, yes, graphs are everywhere, but don't effing put them everywhere all at once. You know what I mean? You kind of have to start small and build it from there in order to maximise for success.
SW: 00:06:22.461 Like a structured way. Right? It's like any kid alone in the kitchen. We all know how that's going to look when they make a cake. It's going to be a complete mess if they do ingredients everywhere. It's the same with graphs. Right? Think structurally. Make a cake, make another cake, and then all of a sudden, you have seven different small cakes, which is a classical thing to do in Sweden. I don't know if you have that in Antwerp.
RVB: 00:06:45.138 I need to move. I need to move to Sweden now.
SW: 00:06:47.950 Move here. Get some cake. No, but I think this idea of starting small and kind of expand from that initial minimal kind of use case or value case. Right? And very often-- or at least, I did wrong totally in my life. Right? I wanted to be competent. I learned in school that I need to be competent. I need to look good. I need to make things pretty. Very often it's the exact opposite. Right? It's the exact other way. Think of the value. Right? Make it valuable. Does it solve any problem easier or faster? Because that's the money-making part. Making it pretty, that's the easy part. But we over-index on, "Oh, it needs to look perfect. It needs to be good," and so on, instead of just looking for those things in the beginning, so. And I think that's the cool part with graphs. It's like it fits so good in this approach. It's like it ridiculously fits so good in this. And very often this is also the problem with a lot of technology. You have a technology that is built for waterfall, and then you try to work with that technology in an agile way. So basically, there is a stretching going on here, and the stretching part is you and your team, and that is not nice. We all know that.
RVB: 00:08:03.772 I mean, maybe you can talk a little bit about some of the technical approaches that you can take here. I'm quite a fan of making some considerate and deliberate choices there because I know that the technical choices that you make for any kind of graph solution are going to be important for you. There's no doubt about that. Right? So maybe we can talk about that a little bit. And the first thing that I would like to kind of articulate is there's always many ways of building a graph solution. I mean, you can kind of see that in Neo4j specifically. There's drivers for Java. There's drivers for .NET. There's Python.
SW: 00:08:58.735 For everything.
RVB: 00:08:59.971 It's just there's so many ways that you can actually build a graph solution that sometimes you really have to kind of step back and say, "Okay. I need to kind of choose a direction that aligns with me, with our team's competencies, with our team's best practices." And I think the main reason why you would do that is because in an innovative project like this, you really don't need and you really don't want to add any more uncertainty in your environment. It's just, "Just keep it simple, stupid." I would really, really think about that and make sure that the technical approach that you choose for building the solution is in tune with your own organisation. That's the first thing that I would do, for sure.
SW: 00:09:58.465 Cool. Any second topics that you can share on that?
RVB: 00:10:02.871 Be careful because I might go off on a rant here, but--
SW: 00:10:06.685 Very good. Let's rant. I love this.
RVB: 00:10:09.507 No, I think the second thing that I always think about is I know and I have seen this time and time again that graphs are very-- people can learn how to do graphs quite easily. It's not that difficult to learn graphs. Right? But you can always, first of all, hit a brick wall. Right. I mean, the first time that you do something, there's always something goes wrong. The first time I tried to pump up the tyres of my bike, I screwed it up.
SW: 00:10:47.558 What? No, but it's like that Dunning-Kruger effect. Right? First, you start. It's all easy, and then it's all--
RVB: 00:10:55.615 [crosstalk].
SW: 00:10:55.858 --fun and game, and you're up on the top or the peak of Mount Stupid, as I call it. And then you go into this Valley of Despair, and I think that's what you mentioned as the brick wall. But how can we kind of get out of that or--
RVB: 00:11:10.677 Well, I mean, I think--
SW: 00:11:11.363 --reduce the pain of it?
RVB: 00:11:13.611 It's pretty clear that, with time, people can learn how to do graphs, but they can just avoid that brick wall and make the learning curve so much faster if they would just call in the experts for the expert topics. It's, I mean, not that difficult. It's not expensive. There's a community out there that, in many cases, wants to help you out for free. There's always a way to ask a question. And I think the worst thing that you can do is to keep bumping into that brick wall and expect the wall to give. That's not going to happen. You're going to have to figure out a way to get over or around the wall. And maybe you think that, "I will just learn this myself, and I will get through it myself," but in my book, the more efficient way of doing that is just to hire an expert for an expert topic. And then you will have worked through this very quickly, you will have learned your lesson, and next time, you will not hit that wall again. So I think that's the second thing that I would definitely suggest here is don't be afraid of asking for help.
SW: 00:12:28.766 Yeah. And I think I'm going to actually repeat that. Don't be afraid because it's so inherent. We want to be competent. Right? So it's easy to say, but I struggle with it all the time. So maybe kind of remind yourself and work upon this in a safe environment with the team before. So very good on that. But then is that all, or do we have any kind of third topic to do?
RVB: 00:12:54.790 Well, the last thing-- and it's very much related, and obviously, I've been thinking about this for a while. But if you're hiring or if you're looking for that expert assistance, right, I think you really need to be careful on how you structure that assistance. You should really not expect things like fixed-price projects and those types of things. It's just not appropriate for an innovative project. We've seen this time and time again. I'm much more of a fan of this agile way of working where we chunk it up into iterations and we make sure that every iteration adds value. And we can also make sure that at every iteration we evaluate the cost-benefit, the risk structure of the next iteration and determine whether or not we want to continue with it, yes or no. Right? That's a much more sensible way of doing it. And it doesn't happen often anymore, but I've seen specifically large organisations or government organisations, they have this idea of, "Let's put out an RFP." Right? That's my favourite.
SW: 00:14:17.678 It's the box. Right? It's the table. It has to go in this.
RVB: 00:14:23.391 And it's very difficult, I think. That type of approach really works well if you know all the ins and outs of your process, and when you're doing a graph value project, I think it's just more difficult. I'm not saying it's impossible, but I think it's more difficult, and it's not to the benefit of your project.
SW: 00:14:45.403 And I think that's the part I would like to stress. You have a structure then that doesn't support what you're doing, and I think that's awfully painful in many cases. So you're adding friction to something that doesn't necessarily have to have friction. Right? So--
RVB: 00:15:00.263 No. No. I think we've made so much progress now, both on the technical and on the functional side, to better understand, how can you deploy these types of solutions? And--
SW: 00:15:12.532 Cool. Yeah.
RVB: 00:15:13.494 --I really think it's something that is much better understood and that we actually apply all of our knowledge quite efficiently.
SW: 00:15:23.051 But you mentioned deploy. I'm super curious to hear about your thoughts on how to deploy? Should we go prem or in the cloud, or what's going on? What do you think?
RVB: 00:15:32.506 Well, I think the last two years, this has changed dramatically in my world. What I've seen in the past few years had really kind of overthrown and reinvented the way that people can start using innovative technologies like graphs very efficiently. And yeah, I think in the old days we would probably have recommended, "Why didn't you grab an old laptop or a Raspberry Pi and install Neo4j on it and have a go at it?" Right? That's what we would have said a decade ago. Nowadays, and especially with all the investments that companies like Neo4J are doing in it, you can just spin up a Neo4J instance and be rocking and rolling in a couple of minutes. Right? The cloud deployment model is so powerful, has so many cost advantages but especially also, I think, innovation advantages.
RVB: 00:16:47.313 You can just do these things very quickly without having to order a server or find that Raspberry Pi. You can just spin it up. And it's literally dirt cheap these days. So I feel that for people that are trying to articulate and are trying to develop a valuable project with graphs, they should really consider that. And the logic here is that by doing so, we dramatically reduce the perception of risk and the costs of that initial deployment, and as a consequence, we make it so much easier for people to overcome that mental hurdle and to really start investing into these innovations. And I can't stress that enough. I think what I've seen in the past couple of years is that all of the big enterprises have adopted this model, are leaning into this model. There's always caveats, but I think it's really accelerated, and I would recommend it to anyone. I think it's a fantastic way of getting to value more quickly.
SW: 00:18:02.588 Yeah. That's super true, super true. And it was also nice that you touched upon a little bit of your-- or at least my favourite formula from prospect theory, that kind of classical-- that perception of value needs to be significantly higher than the cost plus perception of risk. Right? Such a good one. I spoke about it yesterday at the university here in Stockholm.
RVB: 00:18:22.388 Oh, cool.
SW: 00:18:22.827 So it's one of my favourite tools, so.
RVB: 00:18:26.794 So I think we've covered a lot here, Stefan. It's been a fantastic journey, and this episode was all about making sure that people are able to achieve the value. We've had a lot of conversations by now, and I had a great fun time recording and discussing them with you. Obviously, there's more to be said about this.
SW: 00:18:51.942 What?
RVB: 00:18:52.858 Yeah. And obviously, we can probably detail this and make it a little bit more scientific or whatever. But for now, I think we are going to try and wrap up an initial thought-provoking set of exercises for people in our community. And I really, from the bottom of my heart, want to thank you for going on this journey with me. [crosstalk].
SW: 00:19:18.562 Yeah. It was a nice rollercoaster. And I learned and a lot, and hopefully, all of you learned, I mean, in this. And if you haven't, why? Seriously, ask why because that's going to be on you, right, because it's very often that we have this binary system, "I didn't like it or not." That is of no interest for anyone that is curious. Right? Think about, "Why didn't you like it? What happened inside you when we talked about presenting? If you hate presenting, why do you hate it?" and so on.
RVB: 00:19:53.365 Why? Why? Why?
SW: 00:19:54.267 Why? Why? Why?
RVB: 00:19:54.785 Cool. Hey, Stefan, this was so much fun to do together with you. Thank you for taking the time. Thank you, everyone, for listening and for tuning into this series. Hopefully, we'll be interacting with you a lot more online, or offline maybe even, in the next couple of months, and we look forward to continuing the conversation. Don't be a lonely document, and talk to you next time.
SW: 00:20:18.966 Relationship matters. Let's do it. Bye.
RVB: 00:20:21.644 Bye. Cheers.