Cool. Well, first of all, let me say thank you to give me the opportunity to discuss because I have to present it, and I'm quite humbled. So I hope the things that we've come up with here and that we're trying to bring to market are not too far off, and I'd love to get your feedback on the things we've designed and come up with. What I thought I'd do is I'd just say a couple words about myself, then briefly talk about the company, and probably make sense if I show the product to some extent, and then we could get pretty technical to towards the end about the ideas we have around governance and network organizations, which is what we call some fractal boards. And that's sort of the rough agenda, I think. So let me start with saying a couple words about myself. I'm I've been working in software startups for the last ten years. So I studied systems theory in London, wrote my bachelor thesis on viable business model design using the VSM by Stafford Beer, and then founded my first SaaS company, built that up, raised much capital for it. The second company was a platform business. And so I I I I learned a lot about software as a service, as a business model, and then the platform model itself. And the idea behind Recursive is something that I've been sort of shaping for a much longer time period. And, we finally got to a stage where it made sense to sort of develop a product in the last couple months. And it's pretty early days still. We sort of I started working on it full time January. We've just closed a pre seed round with a pretty, I think, a pretty solid venture capital fund here in in Germany. And I think we've got enough capital now to sort of, you know, start actually developing the product and to bring it to market. And that's something I wanna show you guys in a in a minute. What's the idea behind recursives? So what we wanna do is we wanna accelerate the transition to the ownership economy and that with the goal in mind to increase universal basic asset ownership. So I think it's that's fairly clear, but if you own assets and you have access to passive income and if those assets are tied to governance, so voting, then you can obviously have more influence. The second part the second part that's important, I think, is we need to change how value is defined and measured. And that's something we've tested and validated with, with law firms. So we built a, value management application that is more holistic and based on consensus. And we've sort of tabled that for now because, it's it's, you know, basically, because it wasn't a product idea that we could raise capital for. So we shifted to co ownership. That was more enticing, but it's still part of the vision. And the idea is to say, over time, we will roll out a value management application that accounts for value in a completely different way that's not reductionist, mechanistic, but instead based on consensus. So you put people together, you define value based on context, and it's consensus based in the sense that, you know, you get rid of that hierarchy where I negotiate goals with my manager. So that's a part of the the the product vision. And with that value score, so every every person of the employee has a value score. And based on that value score, you either get more or less equity, basically. And that's sort of an an idea that we wanna we wanna implement as well. What we noticed is that that's quite complex and, you know, it's it's a bit of a gnarly issue to to, you know, to get people to switch from KPI based systems, OKRs, to a completely new value management system. So we push that back. And what we focused on, now is co ownership. And the in the long run, the idea is to make sure that most companies are co owned, not just by employees, but, you know, by stakeholders at large. So the affected and affected, as we say in systems systems theory. And the the first product that we're bringing to market is basically a digital ESOP, if you wanna really dumb it down. And what's what's the idea behind that? We want to make sure that we talk to platforms and startups that already that already have this notion of employee ownership, and what we're giving them is a better tool that's a little bit more powerful. So, I'll expand on that in a second, but, basically, we're tapping into existing demand for employee ownership with companies that are quick, to try out new solutions, and that's sort of our Trojan horse to get into the market. Let me show you in a bit more detail what that means. So Exactly. Also, I hope this is this is the right format for for for this for this audience. If it's too high level, let me know then I can switch to the technical stuff. The so the the product that we're that we're we're designing at the moment is, is intended to not just digitalize ESOPs, but also, make it very simple to, to create co ownership pools. And that what I mean by that is, basically, you can go into the web app, you can, say who you are or what business you are, and create a pool, which is a a part of your, company, let's say 10%, 15%, and then you simply invite staff, into that pool, and that way you can make them co owners in your business. And what we are trying to to do here is we wanna really simplify, this process of making someone a co owner. And how we're, how we're doing that is by having a web app, which is just focused on the user experience. And then the back end is basically a mix of, at the moment, manual sort of legal work, but also a open source crypto stack that basically tokenizes your ESOP plan. Right? So the user experience for the for the HR person, CXO, or the or the employee is just the web app. They don't really see the underlying technology and the underlying legal process that happens, but that's sort of the the tech stack that we are that we're using at the moment. And, yeah, it's it's three steps. You create a node, we call it, and, obviously, the wording is still, might might still change, depending on the customer feedback. But you create a node, You define and create ownership pools, and you then invite members to make them co owners. And the asset that you get is is is options, and what we're doing here is we're really standardizing things. So employee stock option plans in our, you know, in our mind are way, way, way too complex, and difficult to to understand, difficult to sell to employees. Every time I've done it in the past, it's been it's been a situation where you sit down with the person that you're offering options to. They are they struggle to understand what it is. I I struggle to communicate the value of it because the value is not clear and future value, and there's really not much you can do with it. Right? So you have two touch points, the first one when you sign for the ESOP, and then the second one if there is a liquidity event, where you can then exercise your options, to get a part of the proceeds. Right? So what we're trying to do is we're trying to standardize that heavily so that when you, set up your recursive account, what you what you can do is you can just draw from a a a bunch of templates. Right? So it would say, here's the Facebook, ESOP plan. Here are the key terms, and here's our assessment of it. And that should make it much more simple for you to roll out a different plan inside your company, and it sort of reduces the complexity behind ESOP significantly. And that's all that's our first step. The the tech stack that enables that is is developed by a company called Neufund here in Berlin, and they've used this internally to tokenize their own ESOP. What it basically enables us to do is to tokenize the options, which means there's a lot more flexibility around what you can do with them. And the the features that will be possible are, you first of all, this is probably the the the most valuable. You can split the options into smaller units, which means you can then tie it to, for instance, OKRs, goals, so you can incentivize and reward behavior, and it just gives gives you more flexibility. It also enables us to create an internal market economy. So if you want to transfer those options tokens to another colleague, sell them back to the company, that's possible. And by a stablecoin in your stablecoin, you'll be able to convert it into cash, basically. Right? So that's the stack that we're using at the moment, and it works in Germany. We'll we'll need to see how we roll it out over Europe across Europe. It will require local market adaptations every time, But, you know, for now, we're just focused on the on the German market. And sharing ownership for us is sort of the first step. What we wanna get to, after that is tying that ownership to to governance. Right? So how we think this might play out is once we've, you know, convinced, an existing startup to use a ease of, solution, then it becomes more easy to entice them to use a different tool to run governance. Right? So for instance, once you've created the pool, you can then say, okay. I need to involve the team on a decision that is, yeah, from, let's say, product road map. And we want to offer templates for that as well. So basically, you're saying, what are the most critical or common decisions that need to be taken in in certain teams, in certain units? Here's here are the templates that allow you to sort of figure out, okay, this is something I I wanna vote on. How do you best vote on that? And, then people can vote on it. So it's a simple digital interface, and it's not gonna be tied to any, you know, to any real ownership initially. I think it's for us, the first step is just giving people an an easy tool to sort of get people's opinion. And over time, we can then get more sophisticated and actually, you know, implement it in the sense that, you know, it's it's binding as opposed to a sort of guidance. So we're being very pragmatic overall with all of this, and the thing I'd like to show you today is how we the the concept that we've developed that we call fractal boards, which is basically an idea of governance and boards, yeah, board composition, in a network organization. And the parts of it are based on a viable system model, which is obviously a recursive model, and that's what I'd love to show you next. So let me switch to that. Yeah. And I'd be most interested to hear your thoughts on this. So where where does this come from? I had a consulting gig before I started Recursive for the company called InFarm, an indoor farming company. You can call them a high growth startup. They've raised significant amounts of capital, and they are basically setting up small, indoor farms in grocery stores, around the world. And the challenge they had is they had a traditional organizational design, and I went in, helped the founders think about how you could design organization differently as a network. And some of these ideas we tested there, and they this governance model and this blueprint of an organizational design came to a large degree out of that project. But also it's also based on the VSM, for instance. It has elements of the higher model, which is the Chinese company that was acquired by GE. So it it's sort of a mix of of different things. But, basically, what we what we've come up with is a blueprint organizational design. And what we're saying is that a traditional organization has probably uses, you know, certain organizational model, matrix, whatever hierarchy. And that's fair enough. But if you wanna be successful, you need to migrate to a network based organizational model. And the blueprint, what we see there is is a is a simplified BSM. So there's three nodes, we call it, that are essential for any organization to be viable, vision, design, and operations, and they are aligned in that way as well. And how it works is the the vision node is basically concerned with what we want to do. So these are evergreen topics like identity, norms, values, and so on. These are codified and and and and written down. And they also provide the direction. So they're saying, okay. This is what we wanna do. This is the direction we want to move in. And the design node then basically takes that direction and develops develops capabilities to execute to to to basically develop products and services to move in that direction. Right? And then the the operations nodes are the executing are the executing teams, the local teams that are the customer facing ones. And how governance works across this, value chain is you have different teams inside division node, different teams inside the design node, and sales set up an and fulfillment teams inside each operations node. And what happens is the ops nodes are measured and scored based on the customer value that they deliver. The higher the score, the higher the, the value of that operational node. And the governance system then works as follows. The customer facing operations nodes are are scored and ranked, and the highest node has most say in the vision node. So that's how you create a full circle where the vision node is basically governed, to the largest extent by the best performing, highest performing operational nodes and can influence vision and strategy to the biggest extent. And then it flows back down. Right? So you have the, vision node and the board being staffed by the highest performing ops nodes who can now say, hey. Because we're for customer facing, we think this is a better direction to move in. So that's that's the value based governance that we're trying to trying to bring to market in the long run. And based on that direction, the design node can then develop products and services in collaboration with the ops nodes. So what I wanna show you just briefly is the setup again where each node has a standardized interface with the with the next node. And the standardized interface basically ensures that you can be autonomous inside the node so long you agree to adhere to the interface standards. And what that means is the, you know, we the node can be a black box, but the interface is is clearly defined and standardized. So if the vision node comes up with with a definition of a target market to go for, it has to be done in a certain way. And that means the design node can rely on the inputs coming into it, being standardized so they can have be more flexible and independent in terms of how they then develop those capabilities. So that's a standard, part of this design. Every interface is, centrally managed, and that enables, autonomy of the nodes, but still gives you an ability to sort of, steer the overall organization. And this is a visualization where we're trying to make this a little bit more understandable. So identity and direction, part one, you basically define impact goals, focus areas. So these are opportunity spaces. The second part is then design. So you look at the design notes, look at the opportunity spaces, and try to develop the capabilities that are required to deliver on those impact goals. And then the ops nodes can you draw from these capabilities and fulfill the actual actual customer value. So that that's, that's the flow. And then how the how the interactions work is and this is how how the Fractal board works. Basically, because it's recursive, basically, if we say The US node is the vision node, New York is the design node, and then Manhattan is the ops node, every board has to consist of, one member from the higher level, one member from the, from the current level, and one from the lower level. So what what does that achieve? That basically means, you cannot take decisions or you at least have to involve your input interface. So the note that's giving you giving you a briefing, and you have to involve the output interface so that the the note that you're creating or delivering this value for. And that's the the the basic idea of the Frackel board. And these seats aren't meant to say, this is just one seat. It's it's proportionality. Right? So it just means you have to have equal representation from those three nodes. The ideally, these are performance based, so this is what we try to test with the value management application. So if a node has several, customer nodes, output interface nodes, then the highest performing one has more of a say in the in the board and the

Right? So the basically, the the benefit we think is that you can you can define impact at the highest level. Those impact goals are evergreen, and they apply to the entire organization. But if a local node wants to create a product or service, then they can do that autonomously as long as the product or service pays into that, pay pays into those impact goals, and the way the boards are, set up is always the same. The node in focus has to have a representative from the higher level and a representative from a lower level. So that's, in a nutshell, the, the Flaco board, and I think that's it for now. I could tell you a bit more about the technical implementation and how we do that, if you like. But for now, I think that's sort of, what we're working on, and the concept behind, governance and network organizations. And like I said, I'd love to hear your feedback.

A generally accepted business case to to make employees call?

I mean, the the the biggest level we've seen so far is is the HR sales argument where the the pitch is basically, hey. If you want to hire and retain the best talent, you will need to rethink your compensation, and you will need to do that by offering co ownership. And if you do that, you're you'll be able to hire better staff and to retain it. Right? And the the return on investment case, so to speak, I think it will be it will be based on HR, but, we don't have the numbers yet. No.

Yeah. I mean so which we're trying to move away a little bit from these established terms because I think that's what's going to be possible if you tokenize it. Right? So how how this plays out in Germany is we we basically tokenize the existing ESOP and we will need to call it an option initially. But I think over time, if you wanna really change how people perceive co ownership, it probably makes sense to come up with a, you know, completely different language around that. And, you know, it probably makes sense to deviate from from those existing mental models. What that exactly will look like, I don't I don't know yet, but that's, yeah, the the idea, you know, Because ESOPs already are stigmatized at least here in Germany, you know. It's it's seen as second class equity, which is difficult to value, you know, difficult to get. And I think most employees that I've talked to don't really see the benefit of it.

So let me let me show you a bit more detail on this organizational design. So the the the idea is to say you have sales set up in fulfillment in each ops node, which means the the marketing capacity as such doesn't doesn't really sit in a position anymore where it can influence products. So vision is is the first node. Right? The highest level node. Then you have design. Design is where you have the which typically call r and d. And because that needs to interface and coordinate with the ops nodes, it it's really it becomes very difficult to to just design or focus on products that aren't going to be usable because you involve the ops notes. Does that make sense? I'm explaining this pretty poorly, I

Yeah. So law firms, for instance, I think is is is a good good example. This is where we developed that value management application where traditionally the value is just defined through billable hours. So you make more money, you're more valuable. And that's that's easy to measure because you just count hours. What we what we developed there is a different way to measure value by, getting people in the same room. So the customer, the, employee, and the manager, and they jointly define value dimensions, which is basically the target value that you're looking to deliver. And And that involves those three perspectives. So the customer, the the person executing it, so the employee, and the manager. So that's a representation of that organizational model where you're saying you have vision, design, and operations defining value. Vision is basically represented by the manager. Yeah. This is a kind of customer that we want we wanna work with as a law firm. Design is is basically the employee together with the manager and, the associate that then has to draft the contract, which is the op ops node, the actual person drafting the contract.

Exactly. Yeah.

And this works at every level. Right? It could be teams, or it could it could just be individuals. This blueprint of vision design operations.

Thanks. So first question oh, it was awesome to see the viable systems model and some of the cybernetic ideas. So the first question I had there was who needs to know what and whether it'd be possible, especially with this multiscale approach, to have different kinds of nodes that interface on a trust basis but might not even be in the same institution or in the same organization. And then the second question was about conflict between nodes or stakeholders and how that would get resolved. Whereas biology just sweeps those systems off the table, but we wanna design systems to succeed.

Wow. These are good questions. So who needs to know what nodes exist? Is that that function sits in the vision node. So it's a system design node that basically is concerned with managing the interactions to the interfaces and the basically, the glue of the overall system. And by managing those interfaces, and the also the impact goals and what's generally true, you control, how new ops nodes can be set up. So that's sort of the the the vision node steering the rules around the interactions and how new nodes can be created. And how that then plays out or how did it play out at infirm is we defined certain criteria that would allow the for the creation of a new ops node. So because they were setting up farms inside retail stores, you have naturally a limiting factor, and that is people are going to travel a certain distance to get to that store to pick up their fresh groceries. So what what we what we would say is, unless there's sufficient demand density around, that store, it doesn't make sense to set up a farm. Right? So sales basically, is the first part of the ops node, sales set up fulfillment. If sales hasn't created enough demand density, then it doesn't make sense for fulfillment to get into action, delivering the farm, setting up the farm, onboarding the customer, which which then means the fulfillment team also doesn't doesn't exist. Right? So that's how it flows. And the that ops node, that was, you know, how how that was set up was steered centrally. So the management would say, we wanna go to The US. Yeah? So that's a geographical market we wanna tackle. So then you set up the first the first team to assess, okay, which which cities are, you know, smart to to tackle, and then it flows from that sales setup fulfillment. Does that make sense?

Okay. So only the vision node has the entire org chart, but somebody who was contacted on the Edge would only know who they were contacted by.

Yes. Yeah. I mean, in my mind, it should be different, but, you know, there's the operational reality that you can't just share the the the org chart with everyone, and they were pretty yeah, they they wanted to make sure not all parts of the organization know everything about the organizational design. And then resolving conflict, in this particular example, it was it was not solved by the by the VSM, and it was not solved by the design. So that's definitely something that still needs to be worked out. We came up with a system design where you you basically we we drew from some systems theory models like strategic assumption surface testing, the SSM. But all of that was seen to be too complex and cumbersome to generate consensus and to sort of resolve conflicts. And in the end, you know, it typically reverted to hierarchy.

Sure. So the the regulations we had to work around are basically the the existing ones around employee stock options in Germany. So the design we had to come up with had to fit within within that. So the how how that, played out is the lawyer that we're working with is also cofounder at a company called Neufund. They what they started a couple years ago is developing, a product which with which you could tokenize, all equity. And what happened is that, they basically didn't get approved by the regulator of the Baffin Financial Services Authority in Germany, because it was seen as a, you know, too far away from employee stock options and too close to actual equity. And that's basically the reason why the company didn't work out. So what we then did is we just took the option tokenization, and we just used that because that's currently what the only thing that's possible to roll out in Germany. So if, you know, if we had a wish list, I think, ideally, I'm pretty radical around that, but, ideally, I'd go for complete deregulation around that. So anyone can create ownership assets. Anyone can market them. Anyone can sell them. Anyone can buy them. And you just build some safeguards in that that are basically voluntary, I think that would be sort of if you're asking for for wishes item, that's how I think I would answer them.

that? No. I think that's a perfect, summary. And, yeah, there there are two parts to it. So the first one is very pragmatic, tapping into existing demand, not requiring a a shift in mindset. And the second part is is the more ambitious one where we're saying, wanna roll out a organizational blueprint that's pretty different to the things that you're using at the moment. How we get there isn't isn't completely clear yet. Right? And I think, as you can tell, there's a lot that still needs to be validated in in terms of taking this concept into and turning it into something that's that's a usable product. So I think the rolling out a different organizational model will be more challenging, and we haven't we definitely haven't figured out how how to do that.

Yeah. I mean, I think with most of the governance systems, at least to me, it feels like the user experience really isn't is is cumbersome. So I think the biggest challenge is is is that how do you make it how do you make it easy to to get people to vote on things, and how do you use technology to achieve that. So I think that'll be the biggest biggest challenge. And I don't I don't know what that's going to look like, but I think it'll go into the direction of, yeah, template standardization for certain decision making processes. And that's certainly the direction that we're going to take where Mhmm. We'll say, we make it very easy for, let's say, product team to look at a template and say, okay. I wanna I wanna decide on product feature prioritization, and here's the template that I can use. We recommend the people you should invite or the roles you should invite, and you can then invite them. And we recommend a way to run decision making process. And I think that's probably going to make it easier for for customers to adopt, different governance systems.

Yeah. I mean, that's a that's a key part in in governance. Right? Who decides? Who decides? Who decides? Yeah. Obviously, in the long run, it'll it'll be necessary. I think the the approach that's probably most likely to be successful is this benevolent dictator approach where you ensure to the you clearly communicate to the management, to our customers that, hey. You're not losing control here. You you know, you're not moving too far away from from what you're used to, your hierarchy. There's a fail safe for you to sort of, you know, step in and still do what what you want. And that that applies both to our go to market approach where we have to sacrifice on the principles in the sense that that obviously isn't the idea behind co ownership. Right? But if you wanna pragmatically bring a new governance system to market, you need to you need to be flexible on those principles, and you need to, yeah, do things that you you might not morally agree with. So for instance, yeah, bringing out a governance system that isn't actually tied to to to voting and the technicality the technical system behind it. Yeah. So we we really wanna focus on user experience and just taking it very taking very small steps towards actual distributed governance and a system where what you call phase three, you know, ops nodes or the employees can also vote on who decides who decides and but I think that's that's that's way down the line.

I had a question about ownership. I posted a few legal definitions, and I totally understand using technical affordances to move beyond concepts of words. But how do you juxtapose some of the first things that you said, like the transition to an ownership economy and to have ownership when ownership is related to several features like another entity that enforces that capacity ownership or the ability to be sovereign over what is owned. Whereas if somebody owns something that's shared, it's in a gray zone between ownership and specifically not being owned.

So what we mean by co ownership is not necessarily that one ownership asset is shared. Each ownership asset is unique and can only be owned by by one person. But if you look at the the system at large, then obviously, you know, you have several asset owners, which makes it a shared asset. But that's based on the yeah, on the node or the u the unit. Right? So if you have a to make it real simple, if you have a team of 10 people, which are represented by a, let's call it a company, right, then that's that's the shell for the ownership assets that reside within it. And those can only be owned by one person, but the, you know, the the shell is then shared in terms of ownership. Right? So I'm I'm not a 100% sure if I, sort of understand what what exactly you're asking.

So just ownership, meaning, like, an individual on a team owns the NFT for one tenth of the shared asset. But and then the two aspects are the ability to control and to have another entity sort of enforce that ownership. Just we're exploring what ownership means and then, you know, you mentioned co ownership, but then in the beginning, you said it was an ownership economy

Mhmm.

Not a co ownership economy, but then they're very related, especially as we rethink what ownership means. So just an interesting area.

Yeah. Yeah. So I think the the employees should be able to create ownership assets independent of of central control, meaning if I've come up with a, I don't know, a standard operating procedure or a call script as a sales rep or whatever, and I I I can turn that into an ownership asset, which is then owned by me personally. Right? And the more it gets used by others, my colleagues, the network at large, the the more it increases in value. So that's, that's an ownership asset that I've created and owned, but the team that I'm a part of is a collection of individuals, and this team is, again, represented as an ownership asset, but that to me is shared across the team.

Yeah.

Cool. Yeah. Pleasure. I think the the the cybernetic approach and the the BSM, it definitely needs to update it. And, like, most of the system theory methods, I think you need to be flexible with it. And that that definitely applies to BSM and the, yeah, and how it needs to be integrated with ownership.

Thank you, guys.

Cool.