Build Context, Design for Serendipity

Transcript

[applause] >> All right. Um next up we have Jantine. So, she's going to talk about builder programs. I think we have been talking about uh builder programs and how to like run those and there's a bunch of stuff that goes behind the scenes when we start these builder programs. So, she's going to give some point of view around how to really build one from beyond the KPIs, beyond the numbers, and go a little bit more on the side of experimentation and some learning curves.

Does this work? Let me see. I do I No, I didn't power it. Uh no, it's PDF. Should I uh Should I Uh

Okay. It's okay. Oh, okay. And okay. Yeah. >> But it's not shared. >> Yeah. Here maybe? Maybe stage?

Like usually. Yeah? Okay. >> You want to extend the display or you want to have the same screen? >> Yes, the same. I see. Okay. Do view and then you can I can do it. Now I hope the clicker still works. Yes.

We're all set. Yeah? Perfect. Well, thank you so much for joining this talk. Um as you see, I I'm doing a talk about serendipity. So, we're going to leave a little bit the the realm of having control over everything. Um my name is Yontina Derksen. I'm running Brew Berlin, um which is a builder program here in Berlin, um and as well a conference, uh if you're still around these days, happening the 20th. Um I would like to talk a little bit about uh why first. Um I want to talk about serendipity, and that I think has all to do with the field that we're in.

So, um a lot of times uh in Web3, people really want to onboard developers or builders or maybe mass adoption even uh to make use of the tools or to build up on the tools that we are actually having available or needing to build. Um what actually I think is here a first thing to realize is that Web3 is something that we're saying is going to change things. We're building something new. We're We're building uh a system that isn't there yet.

Um however, if you design a program, I think you need to realize this. When you design a program, let's say you're building a car, um we know cars. So, currently when you're building a car, you're trying probably to optimize the car. Um then there's no knowns, which leads to optimization. If you would have done this before cars were actually existing, so there were horses, um I think this is a quote that always uh is attributed to Harrison Ford, but not sure if he really said it, but basically he said, "If you would like to uh ask the people what they want in the time of horses, they would have said faster horses." So, in

the case of not knowing exactly what would be the best solution, this would have happened or >> [laughter] >> something would have happened to the horse, but you wouldn't have gotten a car since this was a new paradigm. So, that's why like when we're talking basically about Web3, we're talking about a new paradigm. We have a lot of known unknowns that actually lead you to go into exploration. And then when you go into exploration, you probably figure out that there are a lot of unknown unknowns. And in the case of for example a horse, no one knew actually about a car. But still it happened. And why did it happen? It's because they went into this road of exploration and of

discovery. As you can see, um this looks nothing like a horse. So there is a is a element of uncertainty introduced here that is completely different from the the first optimization approach. So, let me also do one step back. We said, "Okay, builder programs. We We really want people to join and maybe go into this set of experimentation." How do people actually learn? I think this is also a good question to ask yourself.

Um of course we had uh we have been experiencing uh COVID times. So we know actually how it is if everyone just stays in. Um you could optimize your time fantastically. People could probably read all of the documentation available. However, we know and also from experience, we know that people are not really optimized to just passively absorb knowledge. Like we have nowadays even have LLMs. We don't want to compete with that, right? Like this is not how human beings actually learn, be creative, and go to the next. Um basically what um the stages of adult learning are, it's like you experience, you reflect upon it.

You might generalize the the experience you have and then you can apply it. And basically it's some kind of circle. Once you start applying it, you are experiencing it. So basically it's a it's a learning circle that brings people towards the experiential part of the information. And I think this is also something really important because when you're designing a program, I think the experiential part is something that in a lot of programs is not really being seen as as an important one. And this brings me actually to the topic of the success metric.

As soon as let's say a project or someone says, "I want to basically onboard people to my technology. I want to create a program that people maybe must adoption or like experiment with it." The first thing that a lot of people do is saying, "Okay, how am I going to measure this?" So, what are my measurements of success? Um and then like when I started to look for this presentation online into the the success metrics, personally, I got very sad already. I read about KPIs, key performance in the index, uh OKRs, objective and key results, very business-style uh measurements of how to actually figure out if something

works. However, um there is something actually uh in literature which is called the McNamara fallacy. I'm not really sure if I pronounce it correctly. Um not sure if people are familiar with Robert McManar- Mc- McNamara. He was the uh Secretary of Defense in the '60s of the United States. And back then, uh he actually came to go back to the the the earlier example, he actually came from Ford. He was actually an extremely intelligent guy. He managed Ford completely like good. Like they were saying, "This guy, if he can increase the production of

cars, the the innovation in cars, this guy could probably help us win the Vietnam War." So, there we insert Robert And he said, "Yes, okay. I'm going to take a completely measurement approach. We're going to drop X amount of bombs. We're going to destroy the enemy. Everything was quantified." And he said, "As as long as we have all the knowledge, we will have an intelligence that they don't have, and we will win." Well, I mean, he he tried very hard and the fallacy is named after him because in the end the Vietnam War wasn't only about dropping bombs and and having the most intelligence. Um basically, the fallacy is

uh first, you are measuring what can be measured. So, you're going to get as many measurement points as possible, and you feel very rich with this information. Then, you're actually ignoring what cannot be measured. Why? Because it cannot be measured. Then, the assumption that then is it's not a conscious assumption, but the assumption usually that is being made is that what cannot be measured is unimportant. Why? Because you're not measuring it. So, no one is actually putting any importance to it.

And then, the conclusion is what cannot be measured is actually not existing. Well, and here you see the fallacy how to win a war with metrics. Um we all know the mess of the Vietnam War. Um so, yeah, Robert McNamara, he was I'm losing my presentation. Let me I think it's my laptop. Um yeah, Robert McNamara, he was very good in optimizing, but he wasn't very good for the messy situation that is there beyond beyond the optimization process. Um so, then there's actually next to the fallacy, there's actually as well a law uh named after this obsession with measurements. And it's when a measure

becomes a target, it ceases to be good to be a good measure. And I think this is something that we're also dealing with without the fact that maybe we have a wish. We would like to on onboard builders. We would like to have people experiment with the technology. We're also dealing with a lot of reality that is maybe we can call it scalability. We have someone that has a wish that hands over this wish to the next person and the next person and before you know, there's someone that gets a KPI. There's someone that has to chase the number. And this is actually as soon as actually this happens, you actually don't have a good measure anymore. So, this is something to say

about when you have a KPI, maybe you need to always ask yourself if this KPI is actually serving the higher goal or if you're in the end chasing the KPI itself. And unfortunately, this is often a situation that happens and I actually also therefore would like to argue as soon as you hand over the goal for someone's build a builder program, give them the certain autonomy not to give them almost like childlike KPIs, but give them the autonomy to strategically think. Because otherwise, the measure becomes the target and you might hurt the program as a whole.

So, wanted to take a step back here as well. Why am I actually also saying, okay, uh in this case, we're not only doing incremental innovation. We're not only, you know, improving a car. Uh and for that, I want to go back to chaos theory, which basically, I'm sure as well, is a theory you're all quite familiar with. I put a butterfly as a picture there. Basically, chaos theory says, um that how small it can be. It can be the clapping of the wings of a butterfly in uh any um although it has like a fixed set of rules, as soon as something tiny happened that impacts the whole

enormously. And in the the case that they always say of the butterfly, they usually say the clapping of a butterfly can cause a tornado on the other side of the world. So, the idea here is that predictions, what can happen, even if you have all the sets of rules already, like you you made it absolutely your program is structured to the maximum, still there might be something happening. Someone has a coffee with with someone and conversation happens that would never have happened if you wouldn't have that coffee.

Everything changes. So, this is something to also keep in mind that we cannot really control all of the elements when we're having to deal with a builder program. And basically this is the called the control fallacy. So, here we are at the at the second fallacy. A lot of people they have the the idea that the small causes have small effects. And yeah, going back to chaos theory, like I said before, this is not actually the case. Um So, I gave an example here that is maybe a bit painful for me. A keynote maybe forgotten after a week, so you might not think about this at all, but maybe when you leave this room, you bump into

someone, you have this 5-minute coffee, and maybe you found a company in a 1 year. So, you know, we don't know if this is actually the the the knowledge that you're gathering, or maybe it's just a random act on your way out. And this is also something to keep in mind. So, we can design programs, and we can put a lot of importance at the lot of things, and it might actually not be the thing that is actually remembered. Um I have actually one more thing to say about this whole idea of of pro uh uh programs. And while usually I'm going back to the mathematics of it all, because I would say that the mathematics is the most controlled situation that you can

get, and there you can actually already look how they are dealing with modeling and and designing programs. So, basically on the book of mathematical models, Erica Thompson actually already made a case, we should never uh say that a model is reality. Um so, basically all our assumptions are true and uncertainties are quantifiable. This is not how the world works. Um so, basically everything that we also will do during uh during a program is basically a simplification. And this is something that we also have to keep in mind, like we're just showing you something, but this has not something to do with the real world.

Then I want to put like when then designing, because now we said, "Okay, what is this all not?" I would like to go a little bit very shortly and briefly in what it is, because when you're then saying, "Okay, so you cannot really model, you cannot really plan, you cannot really quantify, what actually then stays?" And this is actually going back to what I said earlier, um a lot of things cannot be measured, but they are of very big importance. And I would say that um me myself, when designing programs, I can see that there's a lot of uh value in the fact that there's trust.

And trust actually basically you can also connect it to I belong here. I can be here and I can express who I am, what I think and what I feel. And why I think trust is really the the the most important thing here is the fact that if you don't trust, if you don't feel comfortable, how how are you going to learn, how you're going to share? And this is also something that has been heavily researched. When you don't have trust, you basically share things that are not truthful. So, you might don't share your new idea. You don't share actually the thing that maybe goes from a horse to a car, or you don't share that you actually don't know. And when there's no honesty in this whole program,

basically there there can never be any adoption or any new idea coming from there. And then basically I I've been thinking myself like, okay, what are basically the elements that I say are very important to create like this whole situation where we say, what would be the the not quantifiable, but still important measurements? Um I think the diversity of perspectives is something that is often as well quite how do you say, like when we talk about simplification of reality, often there's already a persona that people want in their in their builder program.

We are often talking about developers, and otherwise you have to be a designer, or someone has to fit in this like whole narrative. But actually it would be really great if you just find adjacent roles. Find people that maybe in your idea don't belong there and see what will happen. Create unstructured interaction. Create moments for serendipity. Create moments that what I said before, maybe this talk will lead to nothing, and maybe when you have this moment together something that will happen. Something will come out of it.

Trust, like I said before, exposure to unfamiliar ideas. Again, introduce uncertainty. Make people think and you know, maybe talk out loud about things they're not comfortable with. And then of course the opportunity for experimentation. I think it's just extremely important and this is the difficult part when designing. basically when you're designing there should be a big part of the program that you don't know, that there is time, and that basically something can happen that you the unknown unknown have no idea what will come out of it. Now, I cannot say how I can push this whole

web three worlds to go into this direction, but at least I hope to have a give you maybe as well like the tools to speak about it. In fact, what if someone says, "Hey, here I have a set of measurements. Here I have KPIs. This will at least lead to some results. What do you have? What do you have to give?" With your unstructured program, I would hope that what we have to give is a lot of experimentation that leads to potential unknown unknowns. Yeah, and I would like to thank you for your attention.

Yeah. >> [applause] >> Any questions? >> No, okay. I have a question for you. So, I know that a lot of teams in crypto do a bunch of these hackathons, right? And I think I was talking about this earlier as well. So, when you run these hackathons, I think the narrative has changed a lot in the last couple of years. Like initially it was mostly like I think EthGlobal pushing you know these bunch of local events, but the space seems to be a little bit more saturated now. So, if you had to organize a great builder program or like a hackathon,

what would be your like the two most important tips or three more important most important tips to these teams so that they can approach it from a little bit more not KPI centric like you know like just get this much of download or whatever, but more like creating impact. Um so basically I think two things come to mind like because of course like um it's good to think a little bit longer about how to organize something and to go into conversation as well, but the the first thing I think when you want to create something with a specific goal in mind, let's say I want to get people in my ecosystem, is that you should also be generally interested in

those people. So if you will treat people like a number, so if you want to quantify them, they will quantify you back. So they will say, "What do I get from you? Where is my money? How how what are my opportunities?" So if you go into this like quantitative relationship, then yeah, you you can probably keep them as long as you keep feeding them with money. And the interesting thing there is that a lot of often time these ecosystems say, "No, we want them to be self-sustainable." So if you actually want these like high-quality people that you say, "Hey, they might have innovative and nice ideas. They might experiment into the direction that we want." Maybe you should give them like uh

an honest like uh relationship with them. So maybe instead of opening uh the hackathon on site, letting them only work, maybe it's nice if you all go for dinner. You know, like create this idea like, "Hey, we are actually interested in you. We have a human relationship with you." So do a dinner before, you know, like get to know the people and they might actually get to know you. So I I think that would be a good thing to basically optimize for human relationships. Um and I had a second thing in mind.

Um yeah, and I I think that the second thing is follow through. So the other thing that I see a lot is, "Okay, we got 1,000 builders and then what?" You know, so like what I see in my years over crypto is that I keep on running into the same people. So we we actually stay, you know, we are actually here. But, a lot of projects they come and go and come and go. And I think if you have a genuine relationship, it is very strange actually if you would be warm and welcoming and then you shut the door. So, I think that's the other thing, continuity as well from your side. Not only expecting the builders or the people to keep showing up and to keep on building.

Where are you, you know? So. >> Makes sense. Makes sense. Yeah. >> Yeah, I've got a question regarding builders and I would say developers program all around the world. I'm worried with you about trust. But, at the same time, for a big change, you're looking for 12 14 countries all around the world. And how you can see this balance in between KPIs, control, and trust?

>> Yeah, I I think I think it's okay to to follow people, right? I think it's a mix. So, I think what you need to do is the following. Instead of saying I want to target 10,000 people, you need to be honest yourself. Are you going to follow up with 10,000 people? Probably not. So, if you will go around the world targeting 10,000 people, those 10,000 people also know if they don't make it to the top, they will be forgotten. So, you I think it's like it's always a mutual relationship that you create. So, if you basically and and maybe the programs that that I'm talking about, they're very focused. So, they will not scale to say, "Okay, we will have 10,000 people directly live doing all the

same." And that's Yeah, that's another approach that also might lead to like incremental improvements. But, I'm talking about the step where you onboard people. And then, yeah, you can follow them, but you will have qualitative information as well. And I think this is the the the like the fallacy I spoke before is you only measure what you can measure. But if you will have qualitative information and there will be dedicated like following up and human connection, this will become part of it. So there will be a balance, but you need to make time and effort and you have to have a genuine interest in having this balance.

>> Mhm. Yeah, I see your point. Um so it's about I don't know, 100 developers, maybe 200 developers max that you could work with. Um but not about 10,000 or at least 1,000 right? >> I I mean like also if we are honest, if we look at what is like what are successful companies or what are successful projects, we're not talking about 10,000 companies neither. It's actually this interesting like idea of targeting everyone and hoping something will happen versus what is actually the reality.

Like if you would have two fantastic teams within your ecosystem, wouldn't you already be happy? So the question is what do you actually want? And if the hope is I want two teams, then maybe you should just really focus on finding these two teams. >> Yeah, but to find these two teams, it's like a part of developers funnel where you take 10,000 people, you going through from top to low, and in the end you will have this two teams, 10 teams, and etc. Okay, yeah. And you speak about this a bit different layer of developers funnel.

>> Yeah, there are two schools of thought. If you would say if we have just the net as big as enough, we cast the net as big as enough, we will actually have higher chance. And this basically is this fallacy that happened in the Vietnam War. If we just drop enough bombs, we will eventually kill them, right? You you just bomb the whole place. Yeah, but if you will actually get intelligence, right? If you go for the qualitative intelligence and figure out what is actually happening, you might actually not need to cast these nets and give us well all of these people the feeling that they have a have a possibility. But maybe they might not have it. So, I'm actually saying instead of just going for the big number, maybe you need to go for the genuine relationship and understanding about

what's happening. >> I see. Last question, sorry guys. Uh and what is um on top of your mind? What is the profile for this team or developer in this team? Uh is it a student who just uh complete I know some technical stuff before and uh open with full energy and ready to deliver or some well-experienced builders or someone else? >> Yeah, so this this is what I said before like um when you design these things to have this persona in mind, this is actually part of the fallacy. Um I think it's like the relationship that you build. Like if you are able to say what you actually want. So, let's say you're looking for two teams.

I think you need to be more honest about your own goals, not only wanting to have the biggest, the most. >> Yeah, yeah. >> Yeah, and then go back from there. >> Mhm. For example, if I need 10 teams who could deliver and expand our ecosystem, what what would be uh based on your experience as far as I understand you got very robust experience. What is the best profile for this developer? >> Yeah, so like Okay, so in the beginning I said the question that you have is are you are you looking for completely new things for example in your ecosystem or are you maybe you saw something in another ecosystem you want to build that as well.

In the first in the second example, you want to basically do the same as in another ecosystem, you can actually already look oh what kind of profile. So, it depends. If you're incrementally like innovating, you probably can target very precisely. But if you're actually saying, "Ah, we have this like new language and we don't know what to do with it." Okay, maybe you can invite people that know adjacent languages, but maybe it's also nice to, I don't know, put someone from from a completely different field in the mix. Um but yeah, like I said, it depends a little bit. Are we incrementally innovating? I would say then you can probably target very narrow. And as soon as it becomes experimental, it's more

about creating environments than knowing exactly who to target. Because that's the difficult question. >> yeah. I see. I see. Thank you. >> Yeah. Thank you so much. >> Thank you, everyone. That was an amazing talk. Um we'll resume after the lunch, so please enjoy uh the lunch downstairs. Thanks, everyone.