In this episode, you'll learn how you can transition from journey maps as a single-use artifacts to being the backbone of your customer experience strategy. Here's the guest for this episode. Let the show begin. Hi, I'm Florian. Welcome to the Service Design Show, episode 168. Hi, my name is Marc Fontijn, and welcome back to the Service Design Show. When our guest, Florian, former, told me that he and his team are successfully managing hundreds of journeys and even more innovation and improvement opportunities, I had a hard time believing him. Because from what I'm seeing, most organizations struggle to manage anything more than a handful of journeys. So can you really do journey management on such a large scale? Of course, we have to find out. In the conversation you're about to hear, Florian openly shares that they definitely didn't start out this way and that it took them a few years to get to this point. But today, rather than having to convince stakeholders that using journey maps will make their lives easier and help them to deliver more customer-centric services, people from the whole organization are knocking on his door to work with his team. So if you stick around till the end of this episode, you'll learn how you can build a solid repository of journey maps, even when you don't get that task or resources to do that. What the key criteria are for selecting the right journey management tool and how you need to tweak the service design process in order to reach 100 percent journey map coverage. I hope you're ready because now it's time to jump into the conversation with Florian Volmer. Welcome to the show Florian. Hello Mark, how's it going? It's going great. You've been on my invitation list for a long time. Multiple people have recommended you, including actually our previous guest, but it's just a coincidence because your name was on the list longer than that. Florian, I'm looking forward to this conversation. But as always, we'd love to start with a little bit more context about who you are. Please, could you shine a bit of light on what you do these days? Yeah, what do you do these days? What do I do these days? I do two things. I am the service design lead at NCR, a global technology company. We're about 30,000 people around the world, and I lead a team of really smart service designers within our experience design team and managing complexity on a daily basis there. Fascinating stuff. It's a company in transformation as well. I'm sure we'll talk more about that. And then I teach service design, brand and value creation over at Georgia Tech here in Atlanta, where I live currently, to some industrial design students and human-computer interaction students. Sounds like a busy, busy, busy life. It is, at least for me. Yeah, that's the most important thing. Florian, I don't know if you know, but we also have lightning round, five questions to get to know you as a person, next to the professional, a bit better. Just the first thing that comes to your mind, brief answers will not dive into these answers more deeply, just let's see what comes up. Are you ready? All right, I'm ready, yeah. All right, first question, Florian, is what is your favorite food? My favorite food is anything that involves cheese. Next question is, what was your very first job? My very first job was probably when I was around 16. Our neighbor walked over to our house and said, hey, I'm a photographer. Would you like to learn database programming for me? I need a program that helps me manage my photography practice. And I was like, sure, I can read two books. And then I built him a little mini business management system within, I think, maybe five or six months. I think it was. Hmm, cool. Is there a book that you can recommend to anyone to read? Right now in the state the world is in, I'm just rereading Donella H Meadow's thinking in systems. One of those classics, but a really, really important one for us to just keep it top of mind to just think about the impact we have as humans, as designers, and be careful with our planet. I can plus one on that book for sure. I read it first time last year and yeah, a classic. If you could work from anywhere in the world, which place would you like to be? Oh, I just had that conversation with my wife. And I think we would love to be down in New Zealand, just as far away from where we are as possible. Sit on a sit on a volcano, I guess. OK, who knows? Let's keep in touch and see where you are next year. And the fifth or final question is, do you recall your very first encounter with service design? Yeah, actually, actually I do. So I have sort of an interesting schooling history. I went started off in Birmingham in the UK, then then Berlin. And then I did a guest semester over at the Cologne International School of Design, where I met Birgit Mager in 2000. And service design was a really, really new thing there. Moritz was around at that time, too. And I had some really great conversations with those guys. And then I forgot about service design for a little while and then came back about 10 years later to it. Interesting. 2000. That's the early days. There are really early days of service design. But it's sometimes good to mention that, although it's still a new discipline, it's not like super, super new. People have been doing it for quite a while. Yeah. Oh, yeah. Oh, yeah, for sure. So, Florian, let's dive into today's topic. And I love the title, which you gave it is Service Design at Enterprise Scale Equals Journey Management. That's how you sort of pitched it to me. And I was like, sure, that sounds that sounds great. Now, we're going to talk about journey management, about service design and scale, topics that have crossed sort of the schedule or the agenda of the show more often. Really interested to hear your experience. But first of all, the first question I wrote down on my notes was, OK, so when we talk about service design at Enterprise Scale, how big are we talking about? So what do you mean with Enterprise Scale? How scope, scale? Yeah, for sure. Let me paint a picture of sort of my recent and current challenges. So. But in this role for about three years now and have grown this practice pretty significantly. And we started off doing what I'd call service design for UX. So service design for new product development, really focusing the creating journey artifacts or service and artifacts broader that would lead into a UX digital product development process. Mobile screens, stationary screens and everything in between. For the last year and a half, we've really expended that to also include EX, the employee experience. We've been working with our chief human resource officer directly to do some cultural work and do some employee experience work. And then most recently, really partnering with our CX function and looking at the end to end customer journeys, discovering NCR, buying from NCR, being onboarded to NCR and then being a customer and upgrading and so forth. End of life when that happens. So really having that dimension. So it's the CX, UX and EX that we navigate that triangle these days. And we NCR is a complex global company, like I said before, we have three lines of business, banking, retail and restaurant. And we are driving synergies between those three. So when you go to a grocery store, you don't really have that much of a different experience sometimes these days. And when you go in the restaurant, many have a hot bar, many have a little counter where you can get a coffee, that kind of thing. So we bring in these experiences together and we partner with these three lines of business, restaurant, retail and banking. And I checked on our platform. We have about 250 bigger journeys and nested journeys and not differentiating that with that in that number. And about 500 innovation opportunities that we manage and 500 capabilities slash solutions that are in the system as well to just give you some numbers. My direct team is relatively small. We are lean machine, the extended team, the matrix or whatever you want to call that the community of practice is large because we are believing in democratizing service design and partnering with people really from all functions. Sure. Yeah. Still a lot of unanswered questions, which which I'll ask you now. When you say you have 250 journeys and more sub journeys and 500 solutions that you manage, what does that mean? What do you manage? So that means that we are documenting current state that we are driving a series of workshops to define future state that we then go in and say, hey, where are the biggest innovation opportunities that really drive change in those experiences and what are current or future technology or otherwise capabilities that will make that happen that help us execute against that. We I'm in the process of carving more and more space out for our service designers to be just that designers to be innovators, to be thinking about the future three to five years out and saying, where do we want to go with all these different journeys and why and how to some degree and then partnering with other functional areas to see if they if they can't come on board with us to say, OK, we are helping you manage these journeys. We are connecting this to Jira issues. We're connecting these to other project management solutions to to drive daily progress against that. So another thing I'm curious about what you just said is you said we manage this. You do all these activities, thinking about future state. Can you shine a bit more light on who is we in this case? Yeah, absolutely. So my team, I really think of this as a team of service designers and I've been hard at work to say, OK, what do we need to do to bring the design back into service design? Having them really think about three to five years out into the future, use their interplay between abductive and deductive reasoning, use their systems, thinking approach and everything else to define those North Star future state journeys and then partner with other people in the business to come in as journey managers, project managers, whatever you want to call that to help us execute against those North Star journeys. Can I is it correct to sort of say that your team is like a staff function? So it's it's serving the rest of the organization. It's providing a service to other departments. Yeah, that's right. It's a core it's a core central team that's coaching, that's providing the platform, that's teaching, that's taking on key projects to define best practices. But then we're really interested in this before this notion of democratization and helping others to contribute just as much as service designers as we can, just because of the scale we face every day. That's the current situation. Now, let's rewind the tape and go back a few years. I'm assuming that you didn't start out with mapping 250 journeys. It's even amazing that you are that far. So can you sort of take us back to that moment? How did this all start and what was like the context back then? Yeah, absolutely. So I joined NCR five years ago in a very interesting role initially. So before that, I was a design entrepreneur, ran my own agency, pivoted to a service and agency, and then I came over to to enterprise to to continue my personal learning, learning journey, just to give you some background there. I came into NCR and as part of the sales function, actually, in these large international corporates, there is a thing called pre-sales. That is the technical side of the sales organization. And those are the people that have sort of what I'd call them was the design skills. They have the people skills. They have the technical understanding to say, OK, here's your need. Here's your customer experience that you want to drive. And here's our technology. How do we bring all these together? So we taught that group essentially services and light, some basics of journey mapping, some basics of design thinking, collaboration and so forth. And it was clear to me then, all right, we have so many journeys that we are creating with these different restaurants, with these different retailers, these different banks that are they are different for each bank, but they're also very similar. Right. So early on now, I started experimenting with actually air table and said, hey, can we have a situation where journey mapping joins database thinking and my standard banking journey is 90 percent the same for most of those banks out there. And then those 10 percent, you know, can modify those. So can I just simply click copy on that originating journey and have that being adopted to the next banking need to say with that example? It was really cool. It worked really well. I geeked out on the air table. The problem was that I geeked out on the air table and that my immediate team got it and understood how to work with it. But from a usability perspective, it wasn't really all that scalable. So for a few years, I was sort of on the hunt for a platform that would work well from an onboarding perspective that would enable me to do that journey management at scale without, you know, having somebody in training for three, four weeks. So that's the that's the initial journey. They are that air table database and it worked really well. As I said, I put like a little project management module to it. We had a central inventory of pain points and gain points and we were able to reuse different components of it. But again, I wasn't it wasn't scalable. So I sort of retrenched said, OK, what did we learn from this? What do we need to do to do things differently? And that's where we that those were the beginnings of where we landed today. Super interesting. Yeah, again, I'm going to try to summarize this in my own words. So it started out in sales and pre-sales. And I'm assuming that you were creating journeys back then to sort of lead clients through this process to uncover opportunities with them. And not to say to design or redesign their service, but to discover opportunities, right? That is that correct that that was like the context? Mostly, that's correct. And sometimes we got to redesign their experiences as well, just based on our expertise and working with an entire industry, essentially. Sure. But the journeys back then sort of served as a way to help you bring in more work and find new clients. And and you were creating these journeys anyway. Like there were a helpful tool in the sales process. And you figured like, let's make this more efficient because we're seeing patterns across multiple clients. And I'm not going to, quote unquote, waste my time redoing the same steps over and over again. So you decided I know a bit about Airtable. Let's see if I can put my work and journey maps into Airtable on them. When a new prospect or lead comes in, I'll just pull up the journey map and we'll start from there again, correct? That's correct with one addition. So post sales then in the pain points. OK, we're hearing the same pain point from this client, from this client, from this client, from this client. Shouldn't we be thinking about a new feature in the core product that solves these clients needs? So that's where we bridge the gap between sales and partnering with our clients to actually informing new product development. And that's how I ended up in the experiences I'm team. Yeah, so let's talk a bit about that because I think this is really interesting. And you almost use sales as a research tool, which I think is super, super smart. And you had all these journeys, maybe isolated to you and your team. Let's talk about the making the leap from. You, your team, to finding adoption and use within the wider organization. Because I think this is the space where most people, where we see the most casualties among professionals. How did that go? Like, can you talk us through the steps that you took to find broader adoption? Yeah, absolutely. Step number one was really stepping back from me and saying, OK, OK, where am I? What impact have I had in this pre-sales group? And yes, we've created all these journeys. Yes, we trained hundreds of pre-sales engineers in the foundations of design thinking around the world. Awesome. How do I grow my impact? What else should I be doing? So I looked, quite frankly, outside of NCR and within NCR. And I just talked with our design lead at the time and said, hey, you know what? I've done all this work. I think it makes sense for me to come over to the experience design group and sort of take what we've built over there and be a lot closer to new product development and at the same time move from sort of post-product development implementation upstream to actually more of the strategic bucket and informing new product. And at the time, she said, yeah, that makes sense. Let's do this. And I came over. This is about three years ago and a whole world of new challenges opened up. And I guess I got more than what I bargained for it to tell you the truth. And, you know, we started just porting some of those journeys over from these pre-sales days and then doing a lot of a lot of groundwork, doing a lot of sort of development of different journey formats, working on what we call a topography journey, a topology journey that has sort of software architecture next to a journey, a hybrid journey that has the customer experience path with some screens where I built in and a few variants that helped us actually inform UX work a lot more seamless, because really what we found speed was the name of the game. Nobody has time to take three, four, five months for, you know, a drawn out journey documentation process. It's it's it's a lot closer to sort of real time service design. And that's that's what we did. We sidestepped that catalog for a second. We worked in a number of different tools, whatever the situation required. So we I think the team was very, very resilient, very, very adaptive, not very pedantic, if you will, and just very practical. And at the same time, we never forgot about this notion of like we do in service design at scale and we want to drive reuse. We want to drive pattern recognition and we want to drive scale. So early on, we were doing things and in mural a little bit in mural in Excel spreadsheets and PowerPoints and I'm forgetting a few, but on the side, we built a consistent journey inventory just with having a database doesn't matter at table, but made that searchable and accessible for the enterprise. And that helped us stay connected. And then that all led pretty quickly to the first sort of marquee engagement, if you will, where the restaurant lead restaurant product lead came to us and said, hey, I'm new to the company. We have all these different restaurant products and they're great, but they have been product centric. Can you come in and partner with us to build a set of journeys that are depicting the different restaurant journeys persona centric, not product centric and saying, OK, what's the day in the rest? What's the day in the life of a restaurant manager? What's the month in a life of a regional manager? What's the shift beginning of of a greeter at a restaurant? What's the day of a server look like? What's the day of a line cook look like? And we did that work and that then informed, you know, iterations to the overall product strategy, a real time service design. I like that term. That's a really good one. We need to impress. Yeah, let's try it like. Yeah, yeah. Now it's so you're you're not being asked initially for journey mapping. You're being maybe asked to assist with other challenges. But as a byproduct, you sort of mapping journeys and saving them for later use. And then at some point, somebody walks in who actually has a challenge that is related to journey mapping and maps and you have already the inventory. Now, the crucial part here is most people even struggle to just work on the actual challenge. Where did your team find the time to even to also map these journeys? Because that's, I think, like, how do you do that? Yeah, it's it's it's a daily daily struggle. It's we have to remind ourselves to work proactive in a world proactively in a world that is responsive at best and reactive many times. And it's not always easy, Mark. So we just have a cadence where we say, OK, what else may we be able to do? Where what else is going on that smells like a journey where the journey may be helpful and can we cover out the time? Do we do we succeed 100 percent? No, but do we succeed more often than not? Yes, also, again, comes back to this notion of democratization and saying, OK, how can we partner with people and product, with people and professional services, engineering and show them the value of this approach and have them jump right into the platform and say, hey, this smells a lot like a journey. Would you be able to just take, you know, an hour to just document this along this timeline and will then take it from there? We do that quite a bit as well. And last thing I want to say is we had to get a lot more flexible in terms of the process. Traditionally, discovery, right? Doing the research and so forth. And then you do the journey. We've reverse engineered journeys quite a bit, too, where we've come into a situation where an entire feature backlog already exists in Jira line or Jira and the product team has prioritized it for the next half year or year. But we know it's coming at some point. So we just take that backlog and create a journey based off of that and then and then start the sort of validation research and additional discovery research as we as we go along and then come up to speed without, you know, having to take all that upfront time investment. Yeah, so maybe sometimes making assumption based maps, but that's OK, as long as you know that they are assumption based and having a starting point. I'm really curious about the chain of command here. So what is what is the brief your team has to actually work on this? What is I don't know, what are the KPIs? What are they? They're OKRs like because they are working essentially on quite indirect things when you map journey maps that aren't that people aren't directly using. Yeah, so I should also say that that is the that is the ad on work. There is a core a core set of projects that we are directly asked to like help with the project. And that's the bulk of the work. So those have the traditional KPIs of like, you know, do the two week sprints and, you know, whatever sees it through to the to the product and then customer satisfaction, NPS and so forth. The chain of by design, my team is sort of matrixed in to a lot of different organizations. And I just have regular meetings with product leads, with engineering leads, with PS leads and and see what their needs are. So it's a it's a bit more informal than you would expect at a global enterprise like that. But do they have does everybody have the task to map out journeys? Or is it something that happens intrinsically because people know that in the long term, this will be important or valuable? Yeah, so I've been I've been really successful in painting a vision of saying, OK, if we really want to be customer centric as an organization, we want to have 100 percent journey coverage of all of our products that are out there that we offer to the marketplace so that we can iterate in a meaningful way, listen to the marketplace of a meaningful way, have a home to contextualize quantitative and qualitative information and then prioritize future iterations of these products and services based on journeys. And somebody said, yes, 100 percent journey coverage, which I again, also a great term said, yeah, we think that this is valuable and important to do. Yeah. And I guess that's the sign of that I was looking for. And again, coining that term, like 100 percent journey coverage, I can totally sell that to a CEO. That sounds like it sounds like a very appealing sort of benefit to have. So great. OK. Does this hundreds of journeys that you have already in your inventory, keeping updated? I see that service design professionals are comfortable using this tool, know how to use it, see the benefits. Where does this fit into the workflow of everybody who isn't a service design professional? So how are you managing to get the rest of the organization to actually use this? It's a mixture of different vehicles, right? Sometimes an executive briefing may just have in look at the sort of macro high level journey. And here are top five innovation opportunities that you may want to be thinking about for next year and the following years. For a specific product manager, it may be diving into sort of more of the micro journeys and saying, OK, here are the dozen or so priorities that we think are here for the next year. What's really interesting is that I'll be the first to recognize that journeys can very quickly create cognitive overload, right? And I even go back to a journey that I may have created half a year ago. And I'm like, OK, what was I thinking? What is all of this? What were these comments? So we've also found with the platform that we're using, we also found a way to sometimes use the journey and sometimes not use the journey and just look at a matrix overview of the connected innovation opportunities and say, OK, here are the top five innovation opportunities. High impact, high effort, low effort, high impact. You still want to maybe prioritize there. Low impact, low effort, maybe don't do that. You know, you stand at two by two matrix and then a product lead may just interact with that sort of executive summary as well. And then with the more technical leads, we come back in and say, OK, so we have with our T group, with our software engineering group, we have conversations on the capabilities level and say, OK, we need to bring in single sign on. OK, don't have that. What do we need to do? What's that technical capability? OK, by the way, it shows up in 80 steps in 25 journeys. So must be an important capability to have kind of thing. And that's the interesting thing when you do this at scale and when you can sort of identify something like a technical capability, a single sign on. Hey, this is impacting a lot of journeys. What's the business impact? And that only happens when you actually have some mass and have some data and have done the research. So it is like the big challenge is that it creates mapping these journeys. That's the upfront investment that you sort of have to make and have to believe in that this is important. Somebody needs to have the same fate as well in that. Let's migrate the conversation for a second into the shiny object syndrome area. Let's talk about tools. So you started out with air table. It sounds like you actually, you said it yourself, you geeked out on air table and was able to do a lot. What did you stick with air table? Yeah, I mean, sorry, one question. Some people I'm aware might have no clue what air table is. Maybe you can give a bit of context on that first. Yes, yes, absolutely. So remember the story when I, when my neighbor came over and said, can you build me a database for my photography studio? So that back then was in a database that's actually made by Apple FileMaker Pro. And for years, I did some basic database programming in that. So it's a relational database. You have a couple of tables. You connect them. You can build catalogs and so forth. And air table is a modern web based version of that, essentially. So it's a relational database on the surface. It may look like an Excel, but you can do a lot more. You can connect your inventory with your addresses, with your pricing catalog and create these many to many relationships. You change something here. It has this ripple effect through the entire system. That's maybe the shortest way I can say this. I've been interacting with the air table since their early days. They've come a long way as well. And the power there is that it's all very customizable and that they're bought in scripting and so forth and that you can essentially build exactly what you need. And I think there was probably almost like also the downfall because just because we could build it, we started building it. And it wasn't as visual as we needed it to be. It didn't behave like your typical program or web based app that somebody may be used to. It was sort of, you needed to have a database mind to interact with it. And what we found is that our internal onboarding to the tool was just, people took them a long time to understand it. And then it was too hard for them to actually keep a top of mind to stay with it. So that was essentially it. So there's a philosophy here. If I want my service design team to just be irreplaceable 100% and if I want everything to funnel through us, I can make that a good thing, right? I can make us all the experts and everything has to come through my team and I can probably hire a few more people just to interact with the database. But I don't subscribe to that philosophy necessarily. I subscribe to philosophy of doing the right thing and doing it in a lean way and in a scalable way. So we retrenched from that. I did a big scan of the market maybe three, four years ago. And what I found then was essentially mostly still on a normal insult anybody but mostly glorified journey mapping tools still that would do journey mapping really well. But it was just that. It was a singular map that was just there then in the system. It looked good. You could print it, but it lacked the management side of things. And then on the other side, there's this entire world of products that are really journey automation, right? Logic-driven marketing automation. Like if the customer does this, send them that email, send them that text message, blah, blah, blah. And what I found was essentially a gap in the middle there between journey mapping in the traditional sense and journey automation in that more marketing-driven sense. And that's what I call today with a high level of confidence, journey management tools. And we landed on a platform that made sense for us. It's a relatively young successful startup. There are a handful of solutions out there. I think it's a category that's being created as we speak. I did some research earlier this year on it and published something over at DMI Academic in Toronto. I'm just speaking with experts in the field and saying, okay, what are the terms between journey ops, journey orchestration, journey management? What may stick here? And it seems like journey management is the most robust term for this and most successful term for this. So we have our platform and we're happy with it. With regards to introducing new platforms, there's always that, oh, here's another tool or platform, software solution, fatigue. Have you experienced anything like this internally that people see another tool coming on and are sort of hesitant to start adopting that as well? Yeah, it's always something. One of our design ops guys is joking about a few years ago we were, the experience design team was in there, what did we call it? A TRE, a tool rich environment because it seemed to be somebody wanting to buy a new tool at every turn. And he was the one tasked with the procurement and everything. So we went through a phase of consolidation and all the UX tools consolidated of infigma and so forth. So it wasn't that environment that I pushed the other way and said, hey, we need this dedicated tool and it made so much sense for people that I got it through the system. And I'm assuming that this tool is also being used outside of your team, that that's the whole purpose. That's the whole purpose, yeah. And we have 40 licenses right now where it may be project-based where we give a few licenses to people that come into a project and that's a roll-off. They all disable those licenses and we have a number of permanent collaborators as well. Okay, great. Now, this sounds again amazing that you're doing it on this scale, that people are using it, that you've sort of found and that it's become, it feels like it becomes a pull request from the organization rather than you having to sort of push it on to people to start using maps. Like the evangelizing, maybe you're still there but it's, I feel that in your story, it's shifting. It's translating, people are finding you rather than you having to convince everybody to use maps and journeys. Yeah, it's amazing. I don't know what the timing is exactly but the Q3, Q4 of last year is when we got finally over that hump. I'm saying, okay, it used to be like a half hour conversation until people got it. I can now just do a five minute summary and like, yes, this makes so much sense. How do I get to collaborate with you? Okay, what was the tipping point? Can you now, in retrospect, looking back on this, what changed like in the Q3, Q4, except that you probably had been evangelizing for the last five years? Yeah, I think in short, it's our ability to really profoundly stop talking about it and just taking people into it. And not a PowerPoint slide or keynote slide and not a description of a process, not a high level summary, but say, okay, one setup slide, let me take you into the tool and let me show you how this journey connects to this journey, how this journey connects to five opportunities or 15 opportunities and how these opportunities then connect to all these capabilities and solutions. This is how you can work with it. Wouldn't that be amazing? And that's sort of, I think about this a lot when we teach design thinking like, okay, prototyping, right? Prototyping is not present at presentation. Prototyping is something where you take somebody through the experience so they can really experience it. So in some ways, we've been prototyping this process and now we're at that point where we can just bring people on quickly and easily. Oh, what's the thing when you guide them through this process, maybe even let them do it? When do you see that spark in their eyes when they go like, yeah, I need this? The spark is really when we just remind them about the complexity of the task and how there is very few other methods, frameworks, tools that allow us to sort of a, simplify the customer experience and stay focused on the customer experience but then also layer on that systems thinking and that simplifying of that immense complexity that we have behind the scenes. And then like, okay, if we have, say hypothetically three to five tools across the enterprise that do essentially the same thing. If we can show that across a number of different journey maps and if we can then make a recommendation this is the best in class tool. So what do we need to do to roll off those four that are essentially just a cost center then it makes economic sense as well, very quickly. Yeah, so a simplifying complexity and especially within large scale organizations where there are so many systems, processes, structures, people, divisions, silos, it's impossible to see it all in your head but when you have something that you can help to visualize that. And I guess people start to see how it's going to make one, their lives easier, how they can achieve their goals faster and how they probably will be able to do a better job and achieve the goals that they wanna achieve. That's what I would assume. Yeah, and how this is not an additional thing that we ask them to do but how it actually can fit into their workflows and how at the end of the day can actually save them time and effort down the line. Yeah, so that's a really good point that you bring on here because that's what you hear a lot also. Like what's stopping the adoption and use of journeys is people feel that it's another burden, another administrative task for them and it doesn't sound like that's happening over you at least not anymore. At least not anymore when we really stay with it. Of all the journeys that we have, I will not say that every single one of them is 100% up to date all the time, right? I don't wanna mislead anybody but I think you spoke about this three or four years ago where you used that analogy of a business spreadsheet and where it's like, okay, nobody in their right mind creates a business forecasting spreadsheet or business management spreadsheet and creates it and then looks at it a year later, right? And we had that a lot happening with journeys in the past as well. So that's the other part of that value proposition is like, this is an ongoing weekly, monthly management tool that helps you stay with it. I literally had one of the internal stakeholders that, you know, he sponsored an engagement with an external service and agency. Great, they created a set of beautiful personas, beautiful journeys and half a year later he comes to me and said, Florian, I have all these journeys and I love them. I just don't know what to do with them. I'm like, okay, yeah, we can help. We can turn them into actual business management artifacts. Yeah, I can, I love that term. You've been using a lot of good terms from people. Please make notes throughout. Listen to this episode again and make notes business management artifacts because if you're in a business, that's what you need. You need things that help you to drive decision making, that help you to make smarter decisions, faster, better, cheaper and journeys are just that. There are means to an end rather than the end itself. Of course, we've been repeating this for many, many years and it's easy to say but we've seen that in practice it's really hard to get away from the journey as an art piece and go into a journey as a decision making to a business management and management artifact, yeah, absolutely. One other question I have for you is with the experience that you have now, let's imagine you transition to a new company and you can sort of start this journey all over again. What are the most important lessons that you're going to take with you or if you sort of could start over again? That mindset, what would you do differently maybe? I think I would probably take a little bit more time upfront truly looking at every single aspect of the landscape. We just, we dove right into a few specific projects and staying and observing and analyzing a little bit more at the beginning would have been probably additional time spent without showing actionable artifacts but then we would have been able to engage quicker with the right stakeholders and the right projects is one of the learnings.  So being more, I think I'm now being more realistic with time estimates, both from an overall duration and also from the effort that it takes from the team to do so. And I think we've done a pretty good job building a community of practice. The big thing that I find that we continue to struggle with to be honest is sort of this notion of coaching and saying, okay, we train you in fundamentals of design thinking and journey management. Everybody feels good about it. We've done this with hundreds of people, fantastic. And then that moment where we set people free and say, hey, do your own workshop, build your own first journey. Sort of this notion of an agile coach for service design is something that I'm still looking to fill on my team actually. I wanna go back to the first thing you said about taking more time to maybe find the right projects or can you elaborate a bit more on that? Like what did you rush and what would you like to have done maybe more thoroughly? Yeah, so I mentioned earlier this project for the entire restaurant portfolio. We pulled that off within three or four months and it was a crazy load with dozen, dozen, dozen stakeholders, all these rough journeys that we created and then refining them and briefings and interactions. I think in that example, it would have been better to just focus on one or two experiences, build them all the way through and say, okay, here's the restaurant managers, day in the life, week in the life, month in the life. Okay, here the resulting innovation opportunities, here the resulting capabilities that we need and see that through end to end as one journey, show that to all stakeholders and then go on to the other journeys. What we did is we did all these journeys in parallel and whatever course correction we had to do, we did because we didn't get everything right, nobody gets everything right at first, but then we had to do it for a dozen of journeys and not just one or two journeys. And what kind of difference would that have made if you focused on one or two and do them end to end more thoroughly? I think we would have gotten adoption of the framework faster because they would have seen the so what earlier and simpler. That's a good learning, I guess. Now, as we're sort of heading towards the end of our conversation, I'm curious, what's next? What's next? So I focused a lot on sustainability and circular economy through the year from a learning perspective, but we have some really interesting approaches to say, hey, journey management meets sustainability. I believe there is a, observe, not believe, observe there's a big gap between what a company will put out as a net zero goal and empowering individuals or mid-level managers to do something about it. In some areas, it's really obvious and really simple and some other areas, it's very opaque. And I believe we can do a lot through the power of journey management, giving individuals a specific catalog of interventions that they may consider to green their experiences. Fascinating. I've seen that, I'm seeing this as well, so sort of slowly creeping up. Maybe it's beyond a weak signal, it's becoming a stronger and stronger signal and there is more and more appetite. So, yeah, super interesting to see how journey management will play a role, well, yeah, will play a role there. Maybe a sort of pre-final question is, what is keeping you up at night around this topic? What are some questions that you still have on your mind that you wanna figure out and maybe get some help from the community with? So what keeps me up? One, the ongoing management of it is easier set than done to have the right people to partner with that, have that sort of mindset of coming back to something on a very regular basis. I think a lot about the implication set AI is having on our practice right now, both from an analysis perspective as well as an automation perspective. And last but not least, it's, I think a lot about the dance that service designers have to go through, that dance of, one, we are appreciated for our deductive systems thinking, the very analytical thinking. And on the other side, many of us see our highest best self when we are allowed to be really creative and in the zone. And just recognizing that those are two different parts of the brain and quite honestly creating some space for myself to dance those two different dances and create some space for my team to have those moments of true psychological safety where the systems aspects of politics and everything else just suspended for a little bit and we can purely think about what should be and then come back and say, okay, I don't know literally how did we get there. So that dance and just being mindful and maybe a little forgiving with ourselves as well that that is not an easy thing to pull off for anybody in this world.  Yeah, very good point. Very, very, very good point. The service design dance, again. If somebody is on Twitter, they can get a lot of one-liners out of this conversation and you're absolutely right. I was over the weekend, I was sort of recalling again that innovation is inherently inefficient and when you wanna innovate and wanna do that within an organization which is focused on scale, growth and efficiency, then you're going to have a hard time. So that's, I think, related to what you are saying, like on the one hand, the analytical thinking being efficient and sort of finding the solution but you also wanna be messy, inefficient, like that's you have to be. Cool, and that's a very, very interesting question to Ponder upon for sure. Now, we've covered a lot of ground, Florian. Let's sort of summarize with this final thing and that is if somebody made it all the way to this moment in the conversation, what are your hope is one thing they will take away? The one thing to take away, there's so many things that go through my mind so it's a little difficult of a question but I think there's beauty in simplifying the complex and it goes back to this other part of the dance, right? I find it fascinating to dive into a deeper conversation with the software architect and understand all the nuances that are needed to then just create that one little simple element in the journey. There's beauty in empowering others. I cannot think of a more rewarding time in terms of in my practice, when we wrap up one of those training workshops and people just have these glowing eyes and like what do we accomplish in three, four days in terms of just getting a taste of the journey and then have them be empowered to be true collaborators. And the discipline over time. Now it was three things, but I'm hoping that the discipline of managing things over time. So the journey of journey management itself, thinking about this at a meta level and thinking about how and when these journeys show up with other stakeholders would be the last aspect of this. Really interesting. Will it be difficult for me to find a good title that captures all the things we've discussed so far but yeah, no, I'd rather have too many options than too little so it was great Florian. I know we could have talked for another hour for sure. I think I haven't even covered half of the questions I had on my notes, but who knows, maybe we'll do a sequel in some time.  I've learned a lot and I've found it a very fun and interesting conversation. Thank you, yeah, likewise, love being with you. I'm really inspired by Florian's journey and I'm really curious to see where they will be in a year time. If you were able to find a nugget of wisdom in this episode, make sure to leave a comment and let us know what it was. My name is Marc Fontaine and I wanna thank you for tuning in to The Serbs Design Show and I'll see you in the next video.


the Ruger LCP Max. Check that out. They made some improvements, primarily the magazine capacity. The LCP Max carries 10 rounds. Without making the grip that much wider, a 12-round magazine, doubling the capacity of the original LCP-2, adding three-finger contact. Papaki carry this pistol, okay, as well as the original. You know, kind of made for that.  Accuracy that you get with, or the better accuracy that you get with usable sights is substantial. Five pounds, nice crisp brake, 14 and 5 8 ounces.


Nothing official yet with Brady to Tampa Bay, but it looks like it's done They just haven't announced it yet, and he's joining a team that has a lot of offensive weapons to really good wide receivers a very good young tight end a Very a good coach when it comes to dealing with established quarterbacks Bruce Arians has dealt with so many of them But I think that at the end of his Tampa Bay stay He's gonna look back on this and say this is a big mistake Tom Brady because he had something great in New England and He's going out of his comfort zone, which is probably what he's looking to do I know that but this is a mistake for him It's a mistake for him and if New England pushed him out I think it's gonna be a mistake for them But if you ask me what teams gonna win more games this year New England's gonna win more games not Tampa Bay I think New England's gonna go further in the playoffs not Tampa Bay And if all that happens what exactly does Tom Brady have to hang his hat on? Oh, look, I got 4,000 yards and I 35 touchdowns with those two great wide receivers. Okay, great good But he's never been a selfish guy. He's always been about team and this is a move that I just can't figure out And that's why I spoke about it yesterday in that way, too I think he's gonna look at this and say now that I made a mistake I should have just stayed and unless we ever get to the real bottom of it none of it makes sense to me I don't get it. I don't understand why he would leave a good situation a great situation and now he's going to the unknown He's got to learn new players and here's what makes it even tougher for anybody. That's changing teams right now like a Nick falls Who was traded to the Bears? Well, and and Phillip River is going to Indianapolis. There might not be training camps You might not ever be able to work with your people. They might start the season on time But you're not gonna have that time to work with people over and over throw them footballs get the timing down You're gonna start off really really poorly I think you those that stay put if Brady had stayed put in New England a system that he knows players that he knows Coaches that he knows. I think he'd be better off. He's gonna look back on this I really believe and think that it was a mistake. I hope I'm proven wrong Love to watch the guy play, but I think he's gonna look back and say this was a big mistake You are putting all the eggs in your discussion into the Super Bowl basket Like that's the only thing that he should be focused on the only thing that would absolutely make him happy and Maybe there's other things that he's looking for The one thing I will disagree with and I agreed with you yesterday but upon further review I kind of changed my mind on it. Yes, there could be a delay to training camps and Getting a chance to work and understand the new system But it's not like there's a lockout or strike where you're forbidden to do that I would think by the time we get to when training camps can open that he could he could talk to Bruce Arians They can kind of go over things Maybe he can you know work out privately with Bruce on some things because I think that's part of this Arians is really important because maybe Tom Brady looks at himself and says alright I'm a great quarterback, but at 43 I'm gonna have to figure out a way to best utilize what I have here And maybe he just has faith that the faith that Bruce Arians is gonna get more out of him Than what they had in New England and because there are weapons Maybe he feels like hey if I go out there and throw 40 touchdown passes. Yeah, we might finish eight and eight But that's not necessarily my fault. Look, I was able to prove that with weapons last year Wasn't the down end of Tom Brady's career It was the fact they didn't have any weapons to throw the ball to but now with weapons Yeah, they may not win a championship Michael, but if he puts up monster numbers I don't think that makes himself fish. It just I want to be able to show people but I still have it And I believe I can I can I can do better as Tom Brady under Bruce Arians with these weapons in Tampa Then I can't stay in New England Also, the question is what does Tampa look like if you remove? 75 80% of the mistakes that James Winston made last year I mean, this is a team that offensively had games that they were absolutely insane Throwing for 500 yards five touchdowns. They offensively were really explosive But as we saw he had a 30 touchdown 30 interception season So I don't know Don it feels like maybe there's a chance they are a pretty good team with Brady Well, think about it Honestly, I think you would have to agree with this Michael that Tom Brady can look at what James Winston did last year and say Well, I could throw more than 30 touchdown passes because I think I'm a better quarterback than he is with those weapons And I'm not throwing 30 interceptions So he might look at that offense and say if I'm on it I can throw 40 touchdown passes and 15 interceptions and they went nine and seven If I could do that then maybe we can go 11 and five 12 and four compete with the Saints to go to the playoffs Well, and also you look around look at look around at the division Drew Brees on the other side of it granted he has Michael Thomas and they're still a fierce team but this but After that Carolina, no idea what they are Atlanta the second half of the season was much more like Atlanta than they were the first half But over the last couple of years, they haven't been the team that the Patriots played in the Super Bowl So you really look at it from a divisional standpoint. It might have been one of the best opportunities to go get a division Do you believe that they're better than New Orleans? No, I don't believe they're better than New Orleans. However, if if it turned out to be the best version of it and Brady's looked like Brady again. I believe they could be in the conversation with New Orleans Now you talk about the 30 interceptions with James Winston and that was a problem. They still finished seven and nine But he had a big arm. He could stretch the field now Brady's quarterback rating For long passes last year was not as bad as you would think it was in the high 90s not bad But he doesn't have the arm that James Winston has so maybe you're taking away some of the stretchability of the of the field With Tom Brady, it's I think it's fascinating. It's gonna be fascinating to watch I'm sure that if there's a football season that Tampa Bay is going to be on national television an awful lot He's a ratings grabber But I just think he's gonna look back and go that was a mistake


the joy of your salvation and uphold me by your generous spirit and we're gonna focus in on 13 says then I will teach transgressors your way and sinners shall be converted to you and I just felt the Lord spoke to me said Spencer this joy isn't just for you but it's actually available to everyone and so we're gonna intercede with our song and our dance that those who are far from God would be converted and we'd be grafted into the joy of the Lord's salvation so let's begin to prophesy with our song with our dance with our clap and say hey those out there those lost you need this joy you need this joy let's begin to prophesy with our song lyrics to intercession I want us to prophesy over the world you will find your joy in him and no one else will take it away let's begin to lift our hands in the sanctuary let's begin to prophesy this chorus over the earth that they will awaken to the joy of the Lord you will find your joy in him Michigan you will find your joy in America we say you will find your joy in the Lord


She's just open for 24 hours a day, seven days a week, so you can get in contact with us anytime. We have a range of clients, we have private sector clients, government organisations, emergency services, anybody that someone may need to contact will be able to get through. In DIAC, for the Community Status Resolution Service, we need to use an interpreter to help facilitate a lot of our clients' immigration status. We need to determine the pathways the clients may have available to them and also any particular issues the clients may be having. The program that I'm involved in targets clients that have been in Australia for less than five years, so obviously some of them are still learning English or have no level of English at all, so in order to communicate with them to work out what their needs are, we need to use the interpreters. They are very dependent on us when they first arrive and for them to make us to understand what they want, we always encourage them to use these. A telephone interpreter can assist us with an on-the-spot interpreting service, so if our clients will often walk in off the street and it gives us a chance to quickly access an interpreter and manage their case effectively. We have a card that is provided by T's which they can put it on the fridge or somewhere which is accessible and there is a number and we encourage them to call any time that they need interpreters. It's easier usually to use an interpreter rather than rely on a child or a friend just to make sure that the right message is getting across both ways. Often it's difficult for us to know when to book an interpreter, so having a telephone interpreting service provides us with an accessible interpreter service that we can use at almost any point in the day to attend to any situation. It is anonymous, so our clients when they are talking about personal issues don't have to worry that it's going to get back to their community. There are some clients who would like to know the person as an interpreter, that's why they prefer a telephone interpreter and maybe because the telephone interpreter can be in another state, they don't have any connection with that person, so they see it as a very safe and confidential way. It's just so quick and easy, so as soon as a client walks in the door we can get an interpreter on the phone, we don't have to wait. If they are unable to find an interpreter they are usually able to give me an estimate as to how long it will be. You don't have to wait for someone to come to the venue, so once you ring this and then the person just within one minute or two minutes, the person will be on the phone. It's very easy to get in contact with TIS, all you need to do is call 131450. Using the TIS National Interpreting Service is easy, simply supply the operator with your TIS National Client Code and the language you require. Welcome to TIS National, this is Andrea, how can I help you? Hi this is Stacy, I'm calling from Martha's Real Estate, I'm just wanting to get a Mandarin interpreter for a client of mine please. No problem, do you have a client code? Yep, it's a C... Our service standard is to provide you with an interpreter in a major community language within three minutes. Thanks Stacy, just hold the line for an interpreter. Great, thank you. It's that simple to obtain a telephone interpreter immediately. There's no need to make do with bilingual staff or family members who may not be available when you need them or who may not have adequate language skills. You can use our language cards or poster to establish your client's preferred language. When you've established the client's preferred language, you can provide them with a TIS National I Need An Interpreter card which clearly states the client's preferred language. A TIS National Telephone Interpreting Service can be pre-booked if you have any special requirements. TIS National can also provide an on-site interpreter at a location of your choice. TIS National's policy is to use interpreters accredited by NATI, the National Accreditation Authority for translators and interpreters, wherever possible. TIS National interpreters are bound by the Aussit Code of Ethics to maintain confidentiality, to be impartial and to be accurate in all interpreting without adding or emitting information. Some organisations and individuals can access free interpreting services provided by the Department of Immigration and Citizenship. Free interpreting services may be available to private medical practitioners, pharmacies, members of parliament, local government authorities, trade unions and select non-profit, non-government, community-based organisations. For interpreting services 24 hours a day, seven days a week, call TIS National on 131 450 or visit our website at www.imi.gov.au forward slash TIS.


Okay, next, Matthias is going to present stacking sigmas, a framework to compose Sigma protocol for this junction. John worked with Guelm, Matthew Green, Matthias himself and Gip captured Matthias. Yes, so I'm going to present stacking sigmas, so I can sound it. So first I'm going to be a bit of an introduction, so like the notation for the Sigma protocol and some prior works and where everything fits in. Then I'm going to introduce stackable Sigma protocols, which is the property that we need in order to be able to prove space-saving disjunctions.   So let's get started. So a Sigma protocol is a three-round protocol, it consists of a triple of algorithms, a set and five, such that you know the prover starts by generating the first round message, the commitment, using the statement, the witness, and some random tape. It sends this to the verifier, the verifier, samples the uniformly random challenge, sends this to the prover, and then the prover finishes the transcript by generating the last round message using the witness again, and then the challenge, and the verifier can check that the transcript accepts using five. So what's the goal of this talk? The goal of this talk is to have zero knowledge proofs for disjunctive statements. So where you may want to prove that the first statement is in the first language, or the second statement is in the second language, and so on, until statement L and language L. And what we would like is that if this proving statement is in some language using a protocol PII, requires some cc of a PII, then we would like to derive a protocol for the disjunctive relation, where the communication of the disjunctive protocol is significantly less than the concatenation of the transcripts. What are some applications of this? Applications include ring signatures, magic communication, and witness indistinctive ability from honest verifier like Cyranoge. Okay, so in prior work, there's been a bunch of prior work on like, during disjunctions of Sigma protocols or disjunction, space-faving disjunctions of all the protocols. When generally they sort of fall into two categories, either you have some generic compiler for Sigma protocols, and then communication is just a concatenation of all the transcripts. Or you can get some communication saving, but for a particularly constructed protocol. So then you deliberately design a protocol to get this space-saving. And this work falls somewhere in between the two. So what we do is we get space-saving disjunctions for a large class of Sigma protocols, not all Sigma protocols, where the communication is logarithmic in the number of clauses. Furthermore, our compiler conserves the concrete efficiency. So it's real-world, so you can use that. Note that we can't do this for all Sigma protocols. We can't use the definition of a Sigma protocol black box. But however, it applies for a very, very wide class of Sigma protocols. Here, just like a small handful of them. So like, if it's like of the form of like proving pre-measures of like homomorphism using these classic protocols, if it's like NPC in the heads, then you could probably also do it. And it also includes like the classical protocols, like for graph Hamiltonicity and others. So it relies on like no algebraic structure of the language. And so which Sigma protocols does it apply to? So in order to build some intuition, let's start with this Sigma protocol of proving pre-measures of a one-way homomorphism. So in this protocol, of which you know, Schor is an instance, the proof is starts by sampling a random element of the domain. He then applies the homomorphism since the image to the verifier, the verifier samples a challenge. And the prover computes this linear combination in the on the pre-image side. And since this random pre-image to the to the verifier, within applies the homomorphism to verify that it's a valid pre-image. Okay, so how do you how do you simulate such a protocol? So the simulator, if you gave this like a student and asked him to write a simulator, you know, like it works, you've sampled a third round message independently of set and penalty of the of x sorry, and depending of the statement, which sample a random thing from the domain. And then you compute the accepting commitment for this last one message given the challenge. And so the observation that we make in this paper is that in many Sigma protocols, simulation works similarly. Namely, you sample some like third round message from a distribution, which may depend on the challenge, but doesn't depend on the on the statement, or perhaps depends on some like notion of size for the statement, but not the particular statement. And then, for a particular statement, you can then finish the transcript. You can compute the commitment that makes it accepting for C. So, for instance, an example is in many NPC in the head protocols, the view of the open parties, which is the final set, can often just be seen as like a string of like uniformly random ring elements, like it's a communication from the other parties, and it's just usually just uniformly random. Okay, so let's formalize this slightly. So we say that a Sigma protocol is recyclable has recyclable third round messages. If the distribution of the last round message does not depend on the statement can depend on the challenge but not the statement. So the second property, we say that a Sigma protocol is extended on this verifier zero knowledge. If when I give you a statement, and a challenge C, and a last round message, right, so this is the is where David deviates for the normal definition of special on this verifier zero knowledge. If I also give you a random last round message, you can deterministically compute a first round message that makes the transcript accepting. We say that if both are satisfied, we call the protocol stackable, which means that our techniques apply. Okay, oops. And there we go. So here's here's like the overall idea that doesn't quite work yet. There's some piece missing. But the idea was that when you have this definition, or you have a protocol this form, right, suppose that we have a prover was a witness and you want to prove that you know, the witness on the first statements like in the language is in the relation or the witness and the second statements in the relation. But the idea here is that he proves the satisfied clause using his witness, he somehow obtains a transcript for the satisfied clause. And then he applies the same dissimulator for the other clause using the same last round message. So he has, you know, the same challenge, the same last one message two different first round messages. Unfortunately, there's sort of a chicken and egg problem here that means that this particular example does not quite work. Namely, that, you know, the prover cannot generate the first round message for a to because he doesn't have a witness he needs to see to simulate. At the same time, he cannot send a one because that will reveal which clause is satisfied. And obviously the verify cannot send the challenge before seeing a one because otherwise the prover could just send to simulate both transcripts. In order to get around this chicken egg problem, we introduced the notion of partially binding commitments. So this is a commitment scheme, in which we can have a committer, which is going to be the prover can commit to two tuples, and some index I, in such a way that the prover can later equivocate at the position that is not I, but not in the eye position. So you can equivocate, for instance, if I is one, he can equivocate on V one, but not on V two. So you can equivocate on one of the two positions. The observation here is the crucial thing here is that when the prover eventually, or when the committer eventually opens this commitment, the verify does not learn which position was binding. This intuitively will enable the prover to send to one of the first two round messages, right, because he's going to commit to one of them, or he doesn't know which one. But the verify will never know which one. And now I would like to give you a very, very simple construction. So the construction that I'm going to give here is just from partisan commitments. So in this case, you know, you have some setup that's like two generators, you don't know the street lock between them. I'm going to generate a commitment key, and then equivocation keys, a commitment key is just whatever you're going to use to commit an equivocation, we'll let it be equivocating in one of the exactly one of the two positions. You're going to generate this by selecting the equivocation keys, just a random trapdoor, right, so it's a scalar. And you're going to form this H for the other position. So if I is one, this is like H two, you're going to set that to G two, your trapdoor. And then you're going to pick, you know, H one, but said, when I multiply G two to G two, and H one and H two, I get H. And then the commitment key is just going to be, you know, H one. Then in order to commit, I'm simply going to compute H two from from H, what was given in the setup, and H one. And then I'm just going to commit using two individual partisan commitments. So I'm going to form the final commitment as G two or some randomness, H one to V one, G two some other randomness, H two to V two. How do you equivocate? Well, you equivocate, like you normally would for a partisan commitment. So the one of you can definitely change, you know, the equitable position. It is also not hard to see that if you could equivocate in both positions, using the standard, like the way that you normally reduce the binding of medicine commitments, you will get the discrete log of both H one and H two and G. And then by the relation between the two, you'll get the discrete log of H. Okay. So now with this, with this very simple tool, the new idea is, you know, the proof is going to generate the first round message is going to generate an equivocation key that is binding in the position where he actually has a witness for, for the clause that he has a witness for. And he's going to send the commitment key and this and a commitment to the first round message and some garbage in the other position. And then the verifies can send the challenge to the prover, the prover can then finish the transcript for which he actually has a witness. And then he can simulate the other transcripts using the challenge. And then finally, he can equivocate, such that he opens it to the two of the two first round messages. Okay. Slightly more detail, right? So the prover, he generates a quick commitment key and equivocation key for I equal one in the case. This is the clause for which he has a witness. Then he generates the first round message he sends over commitment. He gets a challenge. He runs set to get the final message of the, of the, of the first transcript. And he simulates the second transcripts and he equivocates using the randomness of the original commitment and his newly simulated first round message. And he sends over the last round message, the random and the, and the randomness after equivocation. And the verifier can regenerate, you know, the first two round messages and you can check that it matches the opening of the commitment. Okay. So at this point, we have a not super exciting compiler that, you know, takes a, a, a signal protocol that would have had two last round messages and it gives you a signal protocol that has one left round messages, one left round message like compared to CDS. But what's the trick now, right? So the trick here is that it, this compiler, it takes a stackable signal protocol for language with some communication complexity, ccf part, and it gives you a stackable signal protocol for the language of disjunctions. So x1 is an L or x2 is an L where the communication overhead is essentially just out of the partially binding commitment scheme. Now the trick here is to say I have a, I have a disjunction of four clauses. I have a disjunction of four clauses. I can mute it as a disjunction of disjunctions of two clauses. And I already have a sigma protocol for disjunction of, for two disjunction. So what I can do is I can simply take the protocol that I was given. I can take pi prime and I can stack it again. So I simply feed it into the, into the, into the compiler again. The second time it comes out of the compiler, right? I'm going to have, you know, ccf the original pi plus two times the overhead of the partially binding commitment scheme. So in general I'm going to end up with like log two of L times some, some small constant time security parameter plus the communication complexity of the original protocol. Lastly, before I wrap up I would like to describe a slight generalization. So it turns out that you can generalize this to distinct protocols as long as they share the same distribution over last-run messages or it's indistinguishable. Or in the case where you can sort of trivially convert one into the other by like packing or padding the last-run message. So how does this work? Like informally you simply finish the transcript for, for, for, for the protocol execution that you, you do have a witness for. You obtain the transcript as before and then you simulate using the same set. So just as in, in the case of a single protocol. So for instance, if you have like an instance of KKW over Boolean circuits and you have an instance of KKW over a larger ring, where you know the size of the ring is like some, some power of two. Then in, in, in both cases you can sort of view the set as just being like a string of random bits. Because of the uniformly random field elements, pack them as uniformly random bits. In this case you can do a disjunction between two, two parallel executions of the protocol. Finally, I would encourage you to see the full paper and I would like to say thank you for your attention. Okay, do we have any questions? So it's very cool that you get the sum result for protocols like KKW. I'm curious though, can you say anything about composition in the, in the sense that some parts of the circuit will be stacked and others will not be stacked? Oh, we, we have thought about that, but it's not super, super easy, but I mean no, not really. Okay, thank you. I mean we've thought about it, but that's not an elegant solution. Any other question? Okay then, let's thank the speaker again.


Hello and welcome to this CamelK demo. We want to show today an example use case implemented with this technology. In this scenario, we'd like to see an automated way of having some cross-functional collaboration between various teams. In this particular case, a strategy team has some questions and concerns that they need to have answered. All the teams in the company can help them so that they can then make decisions for the future of the company. Typically, this team, they would get together into a video link and then they will open a Google Sheets document and all those questions and concerns they can type them in and assign the departments they believe can help them. So what we want from CamelK is somehow build a platform that is able to automatically collect all the feedback from all the teams in the organization and make automatic updates on that Google Sheets. So first, we need some preparations to get this working. So of course, we need a Kubernetes environment ready and then we want to deploy a CamelK platform and this typically involves deploying the CamelK operator who will do all the work. And we have deployed as well a Kafka platform that essentially will carry all the information and all the interactions between the different teams. We need as well to prepare API access to Google Sheets so that we can grab all the data from the spreadsheet and we can make the updates. Also, we have prepared a mail server and with that we will simulate the interactions between the teams and also access to Google Drive because we want to upload some reports as we will see in a moment. So this is the overview of the platform. So we can see at the center the Kafka platform and we have a couple of Kafka topics there that will essentially carry all that information. And all around we see these CamelK pieces that essentially will be streaming in and out from the Kafka platform. The questions and answers from Google Sheets to the different teams collect all those responses and then make the updates. And simultaneously we have as well a fifth CamelK implementation that will replay those streams to produce a report that will reflect all those interactions cross-functional happening in the organization rendered in a PDF document that will get uploaded to Google Drive so that perhaps the top management can inspect and see how well the departments are working. So let's get started with all this. In our first stint of the entire data flow our mission is to use a CamelK building block. We will use a CamelK binding and it will capture the data in Google Sheets and then send that over Kafka in a topic. So let's look at that. So the first thing of course we'd like to pretend that we are one of those team members in the strategy team and this is the spreadsheet we want to work with. And some of our colleagues have already entered some questions so we can see here they say after our recent company's acquisition how will we integrate their systems with ours? So we'd like for example to enter our own question here and we say are we still having problems hiring developers? And we can assign these to the developers development team. All right so the next thing then is that what we want to do is to automate this and so we define a CamelK binding. So a CamelK binding is a resource that CamelK understands where we can just simply configure a data source and a target. So as our data source we indicate that we want to use the Google Sheets source. We have here anonymized the sensitive fields and we define a Kafka topic as a destination. So here's where we are going to place all those questions. So now we can look at our platform and we see that we have a Kafka cluster running and we have our CamelK operator ready to observe resources and then create integrations when needed. So we can jump to our command line and then just simply create that CamelK binding. So we say apply CamelK binding stage one sheets to Kafka. So we need to hit enter and immediately we can see that a port has been spawned. So this is the integration and now it's up and running. So it's probably has already captured the data in sheets and put it into Kafka. So now we can jump to the next stage. Now we need to define a second integration that will consume Kafka events from the topic and send them to different emails to the different teams to distribute the questions. So if we look at the source code of that definition, this just requires one single file and we can see that we define a source with the Kafka connector defining the topic that we want to consume. And so this is the routine logic and basically we extract the correct piece of information to check the team that this event has to go to. And depending on the team, then we use one email address or another. And eventually then we send that via email using the SMTP protocol configured here to send it to our platform server. Right, so with that, then we just look at our mail server, sorry, our client that is connected to the server and we see that we have three different inboxes with one per team and basically at the moment, they're empty. So let's just try to execute that. So we have our first stage already running in OpenShift and from the command line, then we can say Camel run and we say stage two and we just need to specify a dependency for the JSON manipulation. So we say Jackson and we hit enter. So when we hit enter, we see that the operator has instantly spawned the integration and the pod is now running. So if we check our inbox, we should soon then get our emails and effectively we get the alert and each team has received one email. So that's one question per team. So there you go. So we delivered the Kafka events and the questions to the different teams. And with that, we have done this stage and then we can just jump to the following one. Next, we want to build a third stage with Camel K that will implement the collection of all the email responses from the different departments and stream those into a second topic in Kafka called answers. So this building block does not require any implementation. It can also be a cabinet binding. Therefore, pure configuration. So let's look at that. So this is the platform where we have already stage one and stage two running and what we want to do is to deploy stage three. So let's look at that. Our cabinet binding is here and we pick up the mail source as the source cabinet so that it will be collecting all those responses by email. We define a meat way action that will transform the mail format response into a JSON structure. And then we'll use the Kafka definition to place that email into the answers topic. So let's then just upload that resource into the environment and the operator should pick that up immediately. So we say OC, apply, minus F, cabinet binding stage three. We hit enter and the operator, let's see. Okay, so it has now created the third element and that is now ready and running and waiting for email responses. And what I'd like to do as well is also deploy our fourth stage that will consume those events we just placed in the topic and will extract some routine information and then with that information, you will know where in the spreadsheet to place those responses. So in this case, we need to implement some code so we will just define a camel K file. So if we look at that definition, this is the stage four, one source file is enough. All we need to do is just define a couple of camel routes. So the first one, as you can see, we are using the Kafka component from camel and we are consuming events from answers. We extract the information from the subject in the email that knows the role that has to be updated in the spreadsheet. Then we do some cleaning on the body of the reply just to eliminate some verbose information and then we make the Google API invocation. So I've anonymized there the token, the access token and basically all we need to do is just to comply with the API specification from Google. And then we use this time an HTTP call to do the update. So if we go now again to the environment, we can say camel, sorry camel, as we use the camel client and we say run stage four and when we pass the dependency camel Jackson for those JSON manipulation. So when we hit enter, immediately the operator again reacts and we have already our integration running there. Okay, so if we look back again at the flow, then we have enabled the integration that will pick up all the responses from the different departments and then updates the Google Sheets documents. So all is left for us to do is to see that in action. So actually we can go to our spreadsheet. We see that the cells are empty. And if we go to our inboxes, we see that we have the three questions from the three different departments. So we will pretend that we are someone from architecture and that we pick up that email that says after our recent company's acquisition, how will we integrate their systems with ours? So someone can go there and reply and say we will be using camel K to build all our integrations. And then send that as a reply. And if our data flows are all working, then we should see immediately our spreadsheet being updated and it just has happened on screen. So we have our first response is in. Now we can pretend we are someone from development that again picks up that message and sees that strategy is asking, are we still having problems hiring developers? Because typically skills are difficult to find. So we say this is less of a problem with camel K because as we know with camel K we can build camel bindings that just require pure configuration. And these any Kubernetes user can do without any camel knowledge. So we send that response. And again, in no time that should be updated in our spreadsheet and we see that there on the third cell. And finally, if we are someone from operations we can reply to this question from strategy that says have we figured out how will we improve our long running batch processes at night? And we can say our plan is to use Kafka streams to build event driven applications and send that as a reply. And there you go. So we have all our responses fully automated and responded in our spreadsheet, which is the goal that we set at the beginning. So if we look back, we have completed our four main stages that fully automate this system that allows this automatic interaction between the different functional teams in the organization. And then we have a fifth and final integration flow for the video today, as we can see on screen. We want to take advantage of Kafka's ability to replay the streams. So in this case, what we want is camel K to consume from both streams that contain all those interactions between the different teams to crunch that and produce a report that will reflect all those cross-functional interactions in the organization and render that into a PDF document that we will upload to Google Drive. So in this case, there's some more logic than usual to do there. So this would be more appropriate for an experienced camel developer. So if we look at the source of that, then this is stage five, still is a single file definition, but we have a small Java helper somewhere there. But in essence, we can see that we have one consumers from the Kafka questions and we have a second consumer from the Kafka answers. We extract the necessary information from there and then we implement what we call in camel a couple of aggregators. And the aggregators basically, they correlate the events to produce a combination of that. So that's what we need. And out of it, then we have all the info that we need and we just render that as PDF with the Java help. And then we upload to Google Drive using the camel component for Google Drive. These parameters here are anonymized once more and all is left to do is just to go and upload these to Google Drive. So this is the folder where actually it will end up. And at the moment, all that we have there is the spreadsheet, but if we go and launch this integration, then we say camel run, the name of the integration stage five, we pass the Java helper and the definition that we have just seen with some of the dependencies. So we launched that and it says integration created and that is going to do the job and if everything goes according to plan in, it gets all the events from Kafka, produces that report, connects to Google API and uploads the report in here. And as we can see, it just did. So we have a report here as a PDF document on screen. We can pretend that we are someone interested on that document and then we open the document and we can see all the interactions that we have seen during the demo with the questions from strategy and the different answers from the different teams as we replied to them from the mail client. And well, and this is it basically. This is all I wanted to show today on the demo. So thank you very much for your patience and listening to this. Bye.


From the time that I was a kid, I always knew that I wanted to do something really special. I always knew that there was something bigger than me than I was supposed to be a part of. I just didn't know how to be that person.  And most of the time I still feel like 12-year-old Jenna.  But there is a part of my life that I'm really sure about.   And he beats the tar out of him because he can't see that giant angel. The story continues and my minister looked at me straight in the eye and said, how long are you going to continue to pretend that you don't know God's dream for your life? How long are you going to pretend like you can't see the big things in store? I believe that those big things for me are loving people, fighting for justice, loving kindness, and being in the trenches with the people in the world. And for me, that place that all of that starts is in the church. It's the place that it started for me when I was baptized on the front steps in bright red steps. It started for me in the junior high when I was confirmed in that same place. It's always been about the church for me and there's nowhere else that I could spend my time. There's nowhere else that I could spend my love because I believe that God's dream for me and for the world starts in the church. And that's where I'm going to spend the rest of my life in the church.


Good morning and welcome back to Investor Intel on a dreary Friday morning today. We're with Brad Moore from Global Cannabis How are you today, sir? I'm good. How are you? I'm well, you know, it feels like the cannabis industry has been around forever I'm sitting here drinking my breakfast with an old Alamedics mug, but the industry is changing rather rapidly and we see it evolving into a more high-tech area And your company is in that space Yes, it is it's a lot's changed over the last couple years We've gone from lots of growing now into we have to start looking at how we're gonna sell this stuff and what what Products are gonna work best and that's data. So for both the past year Global Cannabis has been working with various forms of Blockchain technology and distributed ledger technology to try to build up data that's saleable. Can you tell us about your basic revenue model? Sure our basic revenue model is we basically look at various forms of data from the anecdotal side the clinical study side We use different forms of artificial intelligence to actually come up with a with a product of data that Dispensary workers LPs and retailers can use to create better Prescriptions so that when you go home you have more confidence that certain products that can help you with your glaucoma or your Or your arthritis or whatever element that you're suffering from Part of the big revenue model comes just from that ability to provide access to people to that data So are you doing the actual testing or are you aggregating test results from third parties? So we're actually aggregating data from two different sources from the clinical studies We will be participating using our own cryptocurrency and funding clinical studies So we're pretty excited about that as it launches And then the other way is we have two input devices which we're launching that will soon have an significant amount of cannabis users on it And we use social listening to bring those anecdotal inputs You got to remember just because 50 people were in a study and they were talking about what products Or sorry how to you know, they're getting studied to see you know for a certain strain to see if it helped them with our Tryters, there's tens of thousands of people online having that exact same conversation Right, and we use cutting-edge technologies to bring it in Nice, you know one of the problems in this space of course is that the government has had a stranglehold on the feet of Cannabis for so long. There's actually very little empiric data out there So aggregating reliable anecdotal evidence is a big part of the data And you have to measure it right that's why the studies that are there are so important So when we look at the way our system looks is we actually look at the individual We don't look and say like 25% of people said this in a study We look at we look at the exact answers so that when we have people online We can pair those and that's where the machine language in the narrow path Neurological pathways come in and actually extrapolating and this is a very common model of finance Very common methodology and financial model with the credit story So we're not we're not reinventing the wheel here. All we're doing is taking a huge amount of Noisy data right hard it out so we can get a better sampling size. Yeah, and if you we've mentioned That you're involved in some blockchain technology people here blockchain the logical connection next is a cryptocurrency Are you involved in that? Yeah within the cannabis world? Yeah, for sure like our latest our second the last press releases We specifically talked about the launch of our white paper, which talks about it You got to remember it as you know, Peter that when you're doing these, you know, you're doing these systems The reason we let's just make it easy when we did the reason we did blockchain and this is very Transactional data. There's a lot of transactions happening and if we don't secure it in blockchain It's gonna be really hard to prove, you know You can't just say at the end it's this you have to actually be able to show if you're gonna get any validation If you're gonna get out a regulator a doctor or even a retailer to sign off on that You mean signing off on the data that you've aggregated Signing off on the data you've collected to give it validity You're now attaching it to a blockchain in a distributed ledger Well signing off on the transactional nature of our of our algorithm trade in a data says this product This product is good for this strain air guard paying to strain trademark So you got to remember if you can't show that then you're like everybody else It's all hyperbole and so it's very important that You know, we can show that the nature of the chain of our blockchain is that data is actually the currency That's the cryptocurrency. You've got to remember the token is is essentially a cop that holds the water And so we're excited and and we've just published our first white paper about that The process is starting. It's really important that everybody understands We're not actually doing an ICO and that's a critical component of this. This is not about selling a future This is about a utility and you have a large institution involved. I understand so yeah so we're actually working with the central bank of Lithuania and Carrying that white paper for it's very important in this This because all the SEC rulings and and the perception around this and I've had conversations Canadian regulators Explain the model and they seem pretty happy about while you're not doing an ICO You're not trying to like find a way to get around the securities rules They get does somebody look at this and actually get the stamp or approval say that this is actually a utility token You got to remember it's critical to our business model our revenue utility means asset asset means It has a value that value as it grows by people pressing buttons is important and you can eventually monetize that asset for sure like you can any asset right and You know so it's and I think what it does is it really forces the company to go out and do its job Right to go get data to make things happen inside of it to actually create that outcome like this product is better for this Right, and that's what we're excited about so I saw your presentation. There's a 30 million dollar revenue line Projected in the business plan. What's that? Well, that's that's come that that's that and you're the first guy to ask me about that So thank you. I appreciate that that actually comes from the asset, right? So as people are pressing buttons and the transactional nature of the data is growing the true definition of crypto and blockchain That goes up in value Then what happens is we have this asset look it's similar to having an apartment building that you build and everybody wants to Move in and you sell an apartment and you sell part of so we have the ability to go out and go sell some of these Coins as they increase in value by people pressing buttons by moving that data around and Your risk though is there aren't enough people to buy those apartments and the apartments fall in value That's your risk. There's always risk in that but the nature of the nature of the Partnerships that we built specifically with mr. Lee is You know, we brought some of that you seen in the deck We brought some of the best people in each segment of our business around Stanley and Tony school gets better known as Tony G the poker player, right? These guys are involved with many many different blockchain initiatives and they have the ability of working with us to ensure That the right optics by the right people this thing aggregates in value by people pressing buttons And I gotta say that you get points by pressing buttons those people choose to sell those on exchange That's up to them and that's where investors can go out to go get those points two short answers. What's your coin going to be called? It's called the citizen green token. What's its symbol? Ctt and is it trading on an exchange yet? No, we just actually released the white paper the token launch Will be very shortly coming like very shaman talking months. I'm talking very shortly coming So that's the next major milestone for the company deck. Yeah, so the next major milestone is definitely obviously The the the token launch we look at that as part of the whole kind of the overall white paper initiative But then the the next major launch is our next major initiative is those half million cannabis users And as you've seen on our milestones, we're well ahead of the curve in accomplishing our milestones So as CEO I'm making everybody push things forward. We want to get more done this year than we are planning to do Great. We'll check in when the coin comes out and is listed We'll see how the ICO goes and we'll tell our viewers latest update word We're not doing an ICO my mistake. You're all right. You said that earlier, and I'm wrong When the coins okay when their coins are traded on an exchange will come back and check it and see how you're doing How's that? Brad more of global cannabis, thank you for your time today. Thank you very much having me