Hello, everyone, and on the last session of the last day of Summit, I think everyone will agree with me that it was quite a long week. We are running on fumes, and I even more appreciate you coming here and joining me to on the update of our glorious project that Kola is, Kola-themed one. So my name is Mihail Stremski, I'm a PTL of Kola. You can find me on IRC, that's probably the best way to contact me, INC0 and OpenStack Kola, and let's get to it then. So probably most of us know what Kola is, but let me rephrase it. Kola is a deployment tool of OpenStack with Docker containers. And our full mission goes like that, Kola's mission to provide production-ready containers and deployment tools to operating OpenStack clouds. That means we want to provide images for other people to consume. And by that, I mean, and we have three projects under Kola umbrella or deliverables. Kola itself is just image-based, I mean images, image definitions and Docker files, you can find them in search Docker, and some building infrastructure for them. Our images are, I'm sorry, it was long day, images, that's what Kola is, and how to build them. And deployment mechanisms, we also have two of them currently, we deploy our Kola images with Ansible, that project has a surprising name, Kola Ansible. We also have Kola Kubernetes, which, well, we deploy it on top of Kubernetes using HALM. So a little bit of history, and our project was initially conceived around Paris Summit, and back then there were like two people, I wasn't there, I joined project around Vancouver Summit. And since then, we grew. Currently, currently a currently the latest user survey that came out in April, we are at 15% of production or test-phase deployments, which that spans between 4% production and 9% in test-phase. And we have very good growth of interest rates, because currently we have pretty steady growth of 50%, more people are being interested in our project, release to release. So I think that's fair to say that we're doing something good, right? So yeah, almost one third of OpenStack community expressed interests with Kola project, according to the latest user survey. So let me start with community update. To me, projects are about community, they're not about code, so I think this should be first one to show. In Kola, we value diversity in our community. So far, we don't have any rules for it, because we never had to, because currently no company has more than 20%, no single company has more than 20% of our reviews. That means security, that means we're not driven by some hidden agendas of our business people, we're driven by community. And if one company will figure out, hey, we don't want to do OpenStack for whatever reason, Kola will survive. We're very globally distributed. In fact, I don't want to say for sure, I don't have the numbers, but by now I think most of our core reviewers will are from either Europe or Asia. And top reviewers for sure, it's, we are, I mean, yeah, globally distributed, sorry. So yeah, and during Pike release, we had more than 30 different companies contributing to Kola. That goes to diversity. In Ocata, we had almost 180 reviewers total, granted, most of them did one review, two reviews, but if you multiply it over 180, and a lot of people actually did much more reviews, that gives you quite a nice number. And Kola also shows how much we grow. Over 30% of reviews are done by others. And what that means is in terms of, this is in terms of companies, which means not only almost 20, no company has more than 20% of reviews, a lot of people that are unaffiliated or just happen to come over is quite high, the number of people who did reviews. And we have almost 50% number increase in reviews in Ocata since Newton, given the fact that Ocata was much shorter cycle. Yeah, well, 1500 commits in Ocata, 200 more than Newton during shorter cycle. That kind of shows how much we're growing as a product. So this is the slides that apparently is a thing in product updates. This is what we'll be focusing in Pike release. Okay, I marked this minor focus because there's really not much to be done on our side. It's most of the projects we currently are proven to be deployable. Like images are deployable on a couple dozens of thousands of servers, the biggest one that I know. And Ansible is proven to be working well around 300 nodes at least, we haven't tried more. And well, this space covers more than 90% of OpenStack users. So I think that's quite a good number as well. Resiliency depends what you mean by resiliency. We deploy OpenStack in a way that, I mean, we really are as resilient as OpenStack we deploy and that's up to user, that's up to projects really. But we do care about manageability because that is well within scope of deployment tools in my opinion at least. We want to provide, we want to provide day two tool sets for operators. I mean, we go beyond deploy. It's not Firefox yet. We want to provide, I mean, we do provide upgrades. We provide reconfigure. We have some tools to help with fixing the certain, to fix certain issues that may or may not happen, that may happen in your cloud. Modularity, again, not really deployment I think. Interoperability. That's actually also very important in deployment tools because one of the features in Cola is that we provide multiple distributions that we can pick the distribution that you're more familiar with, inside containers. And even that, even that, within that, because we are running in containers, there is some distance between your hosts so you can run pretty well. I've seen Cola being run on Arch Linux, on Gen2, on CoreOS. And within inside containers, we have a, currently we can build containers with Oracle Linux, CentOS, Ubuntu, lately Debian, Debian in both Arch and Power, just not just AMD 64 and REL, yeah, we have REL, I'm losing count myself. So yeah, I think interoperability is a major focus, will be a major focus. And I think we could adapt for it anyway. Security always is and will be our major focus. We take pride on, I mean, we try, of course, to deploy the most secure cloud that we can post, that we can, the best to our knowledge we can deploy. For example, they will take measures to remove a common areas of common vectors of attack by, for example, binding just to correct IP, every service opens up, we deploy the most bind to our IP that is given. So yeah, this is just one of the, this is one way that we try to limit number of, number of problems that security issues that you may find out. And user experience, well, we are as good as uncivil or Kubernetes, but Cola Kubernetes has, can work on user experience and we do, that's a different topic. And that's our Queens, Queens plans for Cola, user experience became my major focus, probably, I mean, Queens far away, so it's, but in Cola Kubernetes, user experience is going to be work on, and it's being work on as we speak. We also, we also will focus heavily on increasing, improving our documentation, which is, you know, user experience, but I, this is probably, this is one of the most needed places when we need help, documentation. So project white updates, Ocata was very interesting release for us, because before Ocata in Newton, we have just one project, it's what, it was called Cola. And within Cola directory, we had Ansible directory just to be able to deploy images that we built with Cola, just have way to deploy these images. However, once we arrived to a place when we felt that we are stable enough and we have community strong enough to move to the, to our next phase of Cola evolution, we did.  And this way we want to, we want to encourage everyone, every other community to take, use our images as they is without Ansible. You don't, you like puppet, please deploy them without it. And actually, our images are being used across, across multiple projects. Triple, for example, is using Cola images. So, just to show you how, just to show you that you don't need to be involved with Cola heavily to be able to use it. So, yeah. And, you know, I encourage everyone, if you like puppet or chef, whatever, we still have space in OpenStack for more projects. We can, you can do it for, you can create the community around Cola images on your own. So, let's, what happened during the Okata to images? First of all, we have 15 new services. One of the main tasks that we, I mean, we want to deploy, we want to deploy BigTent. That's one of the Cola goals, standing Cola goals, we're still not there. BigTent is quite big and it gets bigger. And we also have lots of non-BigTent projects, except for example. So, yeah, during this three months of Okata, we increased the number of images available by 15. And first, you use default user, that's. I was kind of thinking whether it's a feature or not, but it was big enough to, I think, call it out. So, deploying with Docker is something relatively new. I mean, it's already a few years into it, but we still, we're still finding, like, when you are serious about it, you'll still finding the correct sense of deploying stuff with containers. So, one of it was the, one of this was the UID issue that we found. What happened is, when you build MariaDB today, when you install MariaDB today inside container, it will create a MariaDB user which may have ID 1,000. You build Newton, user ID is 1,000, MariaDB is deployed to create files with user ID 1,000. And when you build tomorrow, because you want to upgrade to Okata, the MariaDB user ID will be 1,001, for whatever reason, it's semi-random. So, when you do an upgrade, your MariaDB loses the access to the data, which is, you know, not ideal. So, that's just one of the issues that, I mean, we fixed this issue within COLA. And just wanted to show that deploying with containers has its quirks, and we're working actively to fix them. It's more than just installing packages. Yeah, and what's our goals? What bike? Well, we want more images. As I said, BigTent is big, and we don't, we're not done yet. We need more packages, we need more applications, and I'm pretty sure people will, people keep adding different images that may not be BigTent, like we also have ATCD, for example, being added. I can't remember that quite, I think it was in Newton. So, non-OpenStack services, especially with the new, with new kind of, sorry, with new goals of OpenStack community, which we'll probably have a good thing on keynote, OpenStack is meant to be reused not only as whole, not only as whole set of compute, of compute kit, but just in there, just, you know, pieces of OpenStack to be used. COLA may be very well fit to this position, to this model. So, the other big one, I think, is at last, we want to create a source of images. So, COLA is meant to be building images, but not everyone has to build images. We have repositories of images, and we want to create a list of, we want to create a source of images for other people to consume that are built, that are, that past CI of COLA. And, you know, when you build them in your own lab, if you have staging environment, if you have CI environment, that's perfect, build them all. But not everyone has this sophisticated staging slash CI system. And by having some set of images that were passing COLA CI system, that's what we, that's one of the goals that we want to achieve.  And the other reason for that is that will enable really users to live in this colleague rail of OpenStack operations kind of, and that doing constant upgrades, like upgrade every day. And that will allow people to just, you know, constantly upgrade. So when some security patch was, will be released in one of the underlying services, you'll get the security patch right away. COLA Uncible in Okata. Reconfiguration optimization.  That's just an uncible thing. I mean, that's us multiple things. But we noticed that, I mean, this is one of the feedbacks that we got in feedback session in Barcelona. And while we got to quite a long lens, reorganized lots of code to make it better. And I think it's better today. So just want to emphasize this as a kind of, you know, show, send the message that yes, we want to listen to feedback. Yes, we want to fix it. And this is incredibly important to hear from users. What are the issues of COLA and how do we fix it? Changing HECA to Fluent D. So this goes to the logging infrastructure that is deployed alongside COLA. And within that, when you deploy, when you deploy COLA with centralized logging, you are able to right away get elastic search and KIVANA. And we use what used to be HECA. HECA was a Mozilla open source project that was deprecated, which means we needed to switch it to something else. After quite a discussion, we stopped at Fluent D, and now we have no HECA left. We also added 11 new roles. Role in Uncible is a separate service that is going to deploy, which means now we can deploy 11 more services than we did before. Conceivable pike goals. That's, first one is better gates. That's probably the one goal that is standing, like we always improve our gates, but we always can have more and better. And one thing that we definitely need is to more deployment scenarios, deploy more services in our gates. There's different use cases, different sorts of reference implementations, and make sure that they work with, you know, we won't break anything. Another thing is we want to have a full upgrade gates. And by that, I mean every commit to COLA, which is more than once a day, will be deploying latest stable branch, will be upgrading this to master, and that will not only ensure that COLA didn't break our upgrades, but will be able to also provide feedback to the project teams, let's say Neutron, if something happened to upgrades on Multinode, we should be able to see that and will be able to help them to fix upgrades because before the actual release happens, so the users will not have to suffer to them. And that also resonates with Multinode gates. And currently, we deploy only one in COLA Ansible. We want to deploy, well, Multinode, HAA, OpenSpec. So, yeah, again, lots of things appear when you deploy clustered. And we want to catch those. Another thing is documentation improvements. I cannot stress that enough. We need better documentation. That's probably the weakest piece of our project. And one of the things that I would really ask people here to give us is use cases. We want to know what are you deploying. We want to make sure that whatever you are deploying works well. And we want to document the most common use cases so other people will have easier time going through the pains. Best practices is another thing that we discussed. It's like use cases, but not really. It's, okay, so I have this happening to my containers, how do I fix them? Or don't do that. Use this kind of versions of packages or like Docker. All that operators' tricks and tips that is extremely useful. And easier quick start. It's quite easy today. It can be easier. We'll be working on it. And we already have some materials that are even easier than quick start. And, yeah, we're working. And also more roles. Again, big tent. We want to deploy more. And it's well within our scope and goals. And color Kubernetes. That's a new kit in the block. Everyone is talking about Kubernetes now, so we don't want to stay behind. And we made quite a lot of changes since Barcelona Summit. You may have seen our presentation during Barcelona Summit when we made live demo of color Kubernetes when we actually deployed full-fledged Kubernetes on stage. We removed almost all of that code since. We moved to Helm. Helm is a package slash templating management tool for Kubernetes. It's within Kubernetes namespace. It's a separate project with a very cool community. We were working with them, implemented a couple of features to Helm to enable deploying the complex beast that OpenStack is. And currently, we're using Helm to provide resources to Kubernetes to deploy full OpenStack. So what we do, we went to use native Kubernetes templating mechanism, which is Helm. We used something called, we call it micro architecture, micro service architecture. There we have lots of discussions about how to do properly Helm and how to arrive to sort of flexibility that will require us, our users, to deploy different OpenStacks. For example, with Kola, we want to enable brand field migration to Kola Kubernetes as well. So what we did is we created micro service architecture. And my friend described it to me in a very interesting way. I really like it. It's like you have all the puzzles and every service in OpenStack, Nova Compute, Nova API, Neutron service is a puzzle piece of it.  So it allows you to ask much flexibility as you want. However, we also have overarching charts like ComputeKit chart. A chart is an equivalent package in Helm that allows you to, if you want just generic OpenStack, it's going to be one command. If you want to deploy every single thing manually because you want to migrate from your brand field deployment and put a service at the time to migrate to the new service, it's also going to be possible. We want to have this cold and middle ground between ease of use and flexibility should you want it. So one thing that we did is we did kind of test-driven development. One of the things that I'm extremely proud about Kola Kubernetes, what Kola Kubernetes community created is one of the most sophisticated gates that I've ever seen in OpenStack. Every commit to Kola Kubernetes will be tested on multi-node gates on self-backend the way it should be run in production in our opinion, which means every Kola Kubernetes being deployed in OpenStack's infra couple dozen times a day in a production-ready architecture, sort of, as much as we could achieve with the limited resources that infra offers. However, it's really, really solid gating system that enables us to ensure that everything that we do will keep working and will not break, will not break it. So yes, this was very painful at the beginning. It was a lot of work to make it to at this point, but right now it's really something to be proud of. And we do have an ambitious roadmap for first release of OpenStack. We created a roadmap on Atlanta PTG, on pack PTG. And one of the, and just to highlight, like the list of features that we want to have on 1.0 is quite long and it is quite complete, but just to highlight few easy security upgrades that will also resonate with Kola images publishing. We want to be able to run Kola Kubernetes in a way that will be almost constantly upgradable. So again, security patch comes into, from the security patch being published to MariaDB to being deployed in your OpenStack, we want it to be less than a day. We'll build every day on images. You run and deploy every day and upgrade every day. And that's going to roll in the security upgrades without you watching them extremely easy, extremely fast, which is critical. We want to start with release upgrades. Most of the release upgrades are not that hard. I mean, not with containers, but there are few. Namely, probably the highest upgrade was Newton Tocata with placement API being introduced. And we want to be able to upgrade that kind of. So since we're deploying first, since it's going to be our first release, we don't really need release upgrades in a way that you deploy 1.0. We need upgrades from 1.0 to 2.0. And that's why we do prototype, we want to make sure that nothing will stand in a way. And we're pretty close to have actual upgrades, to be honest, because, well. And brownfield friendly, as much as possible. Yeah, the brownfield will always be painful. That's just how the life goes. But we do want to, we ask, we, I mean, there are lots of OpenStack already running. And once you run OpenStack, we don't want you to be left alone. And we want as much as possible to be able to migrate from existing OpenStack to Kolo Kubernetes. And we will actually have a very sophisticated use case for that, because one of our lead contributors is going to do that as soon as we're done on his couple, couple, here's couple of OpenStack clusters, each three or so hundred nodes. So yeah, that will be quite interesting use case. So closing nodes, yes, please help us. It's an ambitious project. We still need help. There are many ways to contribute. You don't need to write, to be writing code. We encourage to write code and encourage to review, but this is not the only way to contribute. As I said, we love our feedback. Don't be shy. Come to visit RCRC, say, hey, guys, this is not working. This is breaking. Or I don't know how to do it, please. Or we need to do it in this way, and this is not documented. We need that kind of feedback. We need to be, we need the hard, we need the hard truths. We need the ugly truths so we can make it better at the end. Of course, Patras reviews just the regular what you normally would think of contribution. As I said, we take pride of our openness. We take pride in our diversity. I would love to see more faces and more names on our reviewer list. Bugs, also, great way to, that means if project has no bugs in the queue, that means nobody uses it. So, yes. Please. And you can spread the word around. If you actually like our project, I encourage you to try. Please tell your friends. Maybe they have the same problems as you do. And not everyone has, is here in this room. Not everyone has the stamina to wait for 5 p.m. last day on Summit. I would love to see more people. And, well, we are all friends out there. So, it's never, you can never have enough friends. So, again, thank you for attending in this late hour. And I'll be happy to answer any questions you might have. So, if we're first, taking a first look at Kala, is there, would you recommend one over the other? The Ansible method or the Kubernetes method? Ansible by hands down. I mean, Ansible is stable. Kubernetes is still in development. Well, I mean, at some point, it's going to be a stable. At least it's not there yet. Ansible is stable. It's been running production. It's been battle tested. It's the one that I would encourage. In fact, if you want, I run workshops two days ago. Tuesday, it's called novice install. But Kala, well, video is published.  We have quick start guide. Feel free to try it at home. And if you run into any problems, just give us a holler on the IRC channel. Awesome. Thanks. Great talk, Michael. So, in Kubernetes, I think it's very famous because they don't build the Kubernetes containers, right? Just pull it and start it. The scheduler, the controller, HCD, CNI, we pull it and start it. And I brought this a couple of times in meetings as well, and we talked about this session yesterday. What is the roadmap in Pyke to make Kala just pullable and startable and have a mechanism to automatically push our master, building master containers? Right now, we can only pull our golden stable. But if you're an upstream developer, you don't care much about stable, right?  And you have to spend four hours on your laptop, building 100 containers, or at least the changed ones. So, what we're doing today is every time a commit passes Kala gates, every time a commit is merged, we build all stack of whole stack images of images. They are tested, and we save them in certain places, in tables. This is Hakiway, but that's what we're doing.  What we want to do later is for master and all this, and at least Ocata stable, later Pyce stable, and all these tables that we will have this code, to do daily, once a day, we're gonna, this is still in process, but we're gonna push all these images that we built that day to Docker Hub, which means, in general, you have at least 24 hours old, sorry, at most 24 hours old images. And once we increase, as we will be increasing our gating scenarios, images will be more and more resilient as the same, because again, they need to pass the gates to be, to be accepted, to be saved. So, as we pass it, the more and more testing each image will take and get, and the more stable the whole stack will become, and hopefully to, at some point, you will be able, I hope we will be trusted enough so we can just upgrade the OpenStacks like, you know, in a proverbial cron, right? Thank you very much then for coming, and I hope that


In this episode, we're going to talk about how to get design into the hands of the next generation. We'll talk about what's the most effective organizational model to embed service design teams and is there a limit to how far service design can reach. Here's the guest for this episode. Let the show begin. Hi, I'm Judy and welcome to the service design show. Hi, I'm Mark and welcome to the service design show. This show is all about helping you to design organizations that put people at the heart of their business. The guest in this episode is an effort lacrosse player and I learned that that's actually Canada's sport number one. She's currently the service design and strategy director at Tellus. Her name is Judy Mallet. The reason I invited Judy for this episode is because she has a long track record of doing an embedding service design in a huge organization and that poses some interesting challenges. More incidentally, Judy has used her experience to improve the educational system in Canada, which you also talked about at the service design global network conference in Toronto, and she will be sharing some of her lessons in this episode as well. We'll cover a lot of ground in this diverse conversation, so make sure you're ready because without any further ado, let's jump straight into the chat with Judy Mallet. Welcome to the show, Judy. Thanks for having me. Really excited to talk with you. Before we got onto this talk, I was watching your presentation at the SDG service design global conference in Toronto a month ago or something like that. Just under a month. I'll share the link down below. Yeah, depending on when you're watching. So it's really nice to also talk to you about, we're probably going to talk about what you also presented in Toronto, but also a few other topics, right? For the people who don't know who you are, who haven't googled you or looked you up on LinkedIn, could you give like a really short, brief introduction? Sure thing. So I am the director of service design and strategy at TELUS, which is a national service provider here in Canada. And we provide internet, mobile, TV, home security and health services to Canadians. So I'm part of the product development team. And I think people will be surprised the topics we're going to talk about if they hear this background. Judy, I'm really curious, what was your first encounter with service design? When did you get in touch with it? Boy, so if you can just bear with me a bit to give you the bouncing ball of how I am here in service design. I've been at TELUS a long time, coming out of school, I was a business graduate, did some consulting, and I joined a startup, which is a mobility company. And that startup a few years later was bought by TELUS in order to then buy into mobility services. And over my career, I've been in a number of roles within TELUS, trying to get as much experience as possible, including retail, managing devices, warranty programs, pricing and so on. And just before my stint in service design formally, I was managing the applications portfolio. And it was at a time if we all remember that apps, apps, apps, everyone was talking about building an app for whatever service they managed. I also had ownership of our text messaging services at the time. And when we were asked to build the TELUS My Account Self-Serve app, which allows customers to manage their cell phone usage and their bills and so on, at that time, because everyone was building an app, I assumed that there was some standards around how to build an app. And every time I kept asking, everybody would point me towards brand standards, which is not the same thing. Application standards are not the same thing as brand standards. And so knowing how big this app would eventually become, we started an app development process. If I say governance, it sounds too bureaucratic, but it was a way in which to help other teams are building applications that, one, develop consistency in the application. So a TELUS customer who's using an app for TV versus mobile has similar experiences. And it was a way to help guide product people through building applications. Because just because you're well-versed in TV as a service, doesn't mean you're an app expert. So it was a way to provide support. So after we built the My Account app, we were doing a bit of a reorganization within the product team. And to be quite frank, I was left without a role, because we were combining other roles. And my boss at the time said, what might interest you? Come up with something. And I was thinking, well, we've learned a lot through the app development process. And I have peers who are product owners of these core services. And I said, we could take a lot of those similar standards and build a shared service so that we are focusing on customer experiences toward services. So unifying customer experiences. So we have people with deep expertise around TV. And they're thinking TV day in and day out through roaming services as a product. They're focused on understanding the depth and building a portfolio and experience for roaming. There wasn't a team that was looking across to say, TELUS customer is consuming multiple services. And that has to be consistency. So my boss says, sounds interesting. I'll give you a year to figure this out. And why don't you put a plan together, put a team together? And so at that time, we had stated this old vision. We didn't have a lot of expertise. I was hiring some agency partners and a few people to come work with me. And that was eventually we stumbled. We said, there's something that this is called. And we stumbled upon it was service design and agency partners that we brought on to work with us through some of these core initial experience development processes help build our credibility expertise across the organization. It's interesting. Long history, but that's probably about seven years ago, how the whole idea initiated. And then from there, really, it's like you hear similar stories across other organization really proliferated the design community within Toronto and Canada at large is also supporting that. So we've grown significantly in our impact. And and lever other teams that lever just beyond just the product development team has grown. So that's it's quite a journey. It seems like you're becoming more and more channel agnostic. And that is sort of the one of the career paths or where I see service design is coming from. They start like with a service design mindset, but they are stuck with their channel and app or a website, maybe even copyrighting. And then they sort of realize that they can apply the same mindset, same approach, same process to anything, right? And then then usually that's the moment when they discover service design. Absolutely. And if you think about even from a customer experience standpoint, you the pitfall you can run into when you're only looking at a single channel is you're almost developing experience of blinders that can then break or push some of the pain points to other channels. So if you think, for example, hey, let's just fix an experience that a customer has in the store when they're renewing their mobile contract and the goals and objectives and metrics that that particular initiative might have might be, hey, how do we reduce the amount of time that a salesperson might spend during that interaction? Well, in pursuit of that, at the same time trying to make it a good experience for customers, you could inadvertently perhaps drive the burden to another downstream part, right? And maybe you're doing something and then you're driving more calls of call center, for example. So if you that is the pitfall of not focusing across the entire experience, you might go deep and say, okay, we need a service design initiative within within just the retail portion. But it has to be anchored in the larger end end experience, right? Like from a customer standpoint, we're all the multiple channels. I fully agree. And this is I think one of the big challenges in our field, which we won't go into today. But who is and how do you actually organize this because who has ownership across channels, who has ownership across touchpoints. Anyway, Judy, we need to get into the topics that you that you shared with me. Maybe in the next episode, who knows, we need to save a few things. We're going to move from TV, mobile and what else you do into the topic, which is called Next Generation Thinkers. Sounds exciting. Do you have a question starting? Can you show it to us? Okay, that's right. We're going to do a we're going to maybe we'll do a how about we do we're doing our merge? Yeah, why is it we can do one that says, why should we enable and invest in in educating the next generation thinkers about design thinking processes, philosophy and methods? It's it sounds like a big leap from what you're doing on a day to day basis, or is it? Not really. And let me just, if we think about and everyone can reflect on this, our own growth, right, from starting as kids and the way that kids naturally learn and explore the world and experiment if you think about that. And then the role is the talk that we had at the SDN Global Conference, which was here in Toronto about a month ago, the role in education. And we heard Eleanor, who's the Director of Technology and Innovation for the BC Minister of Education, talk about how the traditional way of educating often, if you think about like, pushed out some of these natural tendencies that we all are born where right we have gifts as kids to learn to experiment learn about the world around us and through that process we gain knowledge. And our education system because originally it was conceived to help us identify certain groups of people that ultimately we would cultivate for lack of a better word, to help contribute to society, right? And some of the things that really helped us be able to measure and identify certain groups of people like it would be things like science, technology, the math and so on, which are much easier in terms of assessment, much more data based. And that would then identify to us that they may be the ones that are the engineering, say the white collar trades go on to become our finance, business, commerce, doctors, lawyers and so on. And then we have these other groups that may go on to trades and so on. So if you think about our education system, it was designed for the industrial economy to be able to say who belongs where and how do we maximize the economic value of the citizens, right? And if you think about the question, why is it important for us to get back to our roots in and help the next generation thinkers bring back some of the elements of design into the education process? It's because we are now dealing in a world where technology advances, complex society. And with that brings the need for some of these original skills, which is critical thinking, complex problem solving. Technology has made our world in some ways much more complex, even though it's also helped to simplify things for us. So think about AI, right? Those jobs are not, as everyone fears, not necessarily displacing blue collar or the menial or row professions. They are displacing white collar, like entry level positions, right? You think about some of the accounting jobs, even law, they're developing programs to be able to do basic law, finance, and so on. So what we need now is to bring back the skills that are practiced in design and bring and value them because those creative problem solving skills collaboration are so necessary for this next generation to be able to succeed in our current economy. So the role of education, this was part of that talk, was to say we need to rethink and evolve our education system to focus on those competencies. Not going to be easy, right? Because again, tougher to, tougher to measure, tougher to evaluate, right? So it's some of the education curriculum changes that have been made in British Columbia are born out of the need to say, okay, we need some more drastic shift in order to help better prepare our future citizens, right? Can you give an example of what, I heard an echo, but can you give an example of what has changed in the curriculum in British Columbia for instance regarding this topic? They have rolled out curriculum changes that focus on a number of competencies such as collaboration, some of the things we talked about problem solving, creativity, critical thinking, and they are now moving towards something which is called inquiry based learning. And so traditionally when we think about the school environment and this is how I grew up, the teacher was a source of all knowledge, right? And they had knowledge, they had a very specific curriculum that says we're going to teach you factoring in math, biology and so on the subject matter, they would hold all the knowledge and their role was to impart that knowledge to the students. They were the holders of learning, if you think about it, inquiry based learning is now flipping it to say students are driving their own areas of topics that are of our interest to them, giving them choice, control and flexibility and in allowing them to have more say in terms of the areas that they want to learn about, the educators responsibilities are now, how do we invoke the skills of collaborations? How do I have perhaps group assignments, group challenges? How do I involve problem solving? We may formulate a problem and say you need to go find out your resources with your team, assign teams and go out and solve this problem. So it's really changing the whole pedagogical basis of which students are experiencing their education day to day like school to focus more on the skills development rather than focusing on what knowledge have you gained, right? Like can you factor a polynomial? That's what Eleanor said in the talk, right? It's less about show me how you do that as opposed to through the process of learning about climate change, like are you also building these core competency skills? If you fast forward a few years, I can imagine that this has not only implication for students but also the physical environment of schools and also for teachers, like is the way we're educating teachers is probably not the way, not the teachers we need for the next generation. So are you seeing also those things changing? It's a slow process and as anything where there's public, public and government involved, it's slow. I would say understanding where BC is headed, they're probably at the forefront of the change. But of course, like the change has to start with the educators, right? And how are they learning and how are they supported with tools? What are they learning in order to be able to affect this to the students? So that is also in tandem. And as I said, even it brings me great joy to hear more and more about business design, systems thinking, design thinking, being embedded into university. I don't, I haven't heard of high school yet, but that's part of the curricular competencies, but in university programs, right? We're teaching these methods of thinking in, as part of regular curriculums and some of these are mandatory. I taught undergrad business students third year, a business design thinking course. And so, and that was a mandatory, not, not an elective. So that gives me great joy in thinking that it's being valued to the point where it's, it's a standard part of the curriculum for even post-secondary education. So, yes, it'll be ongoing, but educators also the way in which we're, we're preparing them to help teach the students is an integral part of that process. I can recommend everybody who is interested in this topic to check out your presentation at the global conference and dive into that. So I'll make sure to link to the videos in the, in the show notes. Judy, we're going to move on to topic number two, which again might seem like a big leap from what we just talked about, because this second topic is at least on my paper here, organizational models. And I'm going to invite you to hold up a question starter. Okay, I'm going through my list here. Just pick a random one and surprise us. Okay, pick a random one? Okay, you don't need it. Let's see what, let's see what happens. Okay. Embrace uncertainty. Okay. All right. What if, what if org models? Okay, my question on this is, I'm trying to, maybe I'll change that one. It'll be this one because I'm trying to. Wow, God, let's go. Yes. Okay. I am not the expert in this. In fact, David Dunn, who's at the University of Victoria has a book on how design thinking works and organizations, but one of the things I can comment on obviously from my experience and the question would be, what are some of the benefits and what are some of the, what are some of the costs or detractions of a design team that's embedded working within a particular business function? Yeah, I don't know if that's super clear. I had to rearticulate that. That might be said better, but let's see where, let's see. Why did you want to address this topic? Why is this topic on your mind? Well, because what I'm often asked about, even as recently as last week is, first of all, much like the introduction, tell me about your group. What do you do? Where, where, where do you reside within Telus, which is this large organization of over 35,000 people and tell me, tell me how you guys work. So I start with, similarly to the way that I introduce ourselves, we are a design team, we're a shared service within product development and we are part of the consumer marketing organization. So as we're working over the years in this model and we're, we've, as I've articulated, we've now done work that's outside of this core structure, if you will. But I reflected on quite a bit around some of the benefits of being anchored within a, an, if I say operation, we're close to the day-to-day business and we're tracking the core metrics that are bread and butter versus a team that might be located outside. And we're starting to observe very specific patterns that are emerging from that. And then I even had a question that came and said, okay, but why don't you guys sit in, in digital as a service design team. And so I've put together from these very answers a point of view, which is to obviously one state that there is no perfect org model that's going to be a, a function of priorities of a company, your leadership, the markets that you operate in, so on and so forth. And what I will say is TELUS has different design teams. We're probably the, the, the one that has the longest tenure and most established, but we are helping even another service design team within the business and enterprise sector get established as well. And of course teams like digital are doing design, right? They're doing UX, UI, interaction-based design. So we're not the only design house within TELUS. But the point of view is this, we are within a product development team. So we have a, like a mothership, if you will, that watches very closely. How are we doing on TV? What are the subscribers? Who are we losing? What are the pain points we need to fix? Why are we losing them? What's happening in content consumption patterns? And how do we provide or initiate new services and introduce in the market to make sure that we're addressing those unmet needs? So we are very much part of the day to day. And that helps us stay relevant, right? Because we are so close to the people that need to deliver the business results, public company. That keeps us pretty pertinent and relevant, if you will. Now, we have often also been sought out for more strategic longer-term, like second, third horizon type work. But I would say 80% of our work is the very here and now, right? Tell me how to fix our roaming experiences. Who is the prepaid customer? What do they need from us? How do we rethink that product? So on and so forth. And because of the nature of where we sit, those types of projects tend to fill our funnel. And the times where we've had much more exploratory, tell me what the retail sales force the future needs to look like and how we might upskill or attract new talent that reflects where things are going. What's happened is because of the way that perhaps structurally we're organized and our focus, even the results and the action and the traction that some of the more future scenario modeling type outputs have are less effective. Because the tyranny of the urgent and the core business that needs to be supported here and now garners a lion's share of attention. So I would say it's neither bad nor good, only say we're happy that we're relevant and very much sought after for today's needs when you're not outside and you're not a unit that sits outside and has time to explore without the urgency of you need to deliver something or we need to have these results shown right away. And we're not necessarily always given the time and space to be able to do that. That I think is some of the pros and cons of having a team that's within, nested within the business versus having one that maybe sits as an innovation hub outside the business. And I wouldn't even say there's one that's better or worse, but I could see and vision a time where there's like multiple groups that are looking at different horizons of the business. Now the issue with an innovation hub that sits outside the business is sometimes they lose the credibility. You hear people say things like, okay, you guys go away, do some naval gazing and we're doing the real work here. So it has to have very top-down leadership support to make sure that that work has equal or its value that's known to the organization. So they're not sort of outside. And that they also have people that are working within them that know enough about the day-to-day business that that lens is also brought into some of the work that's being done and the thought process and so on. So that's been interesting for me. A lot of interesting things that I think a lot of people will be interested in. So from what I'm hearing and what I'm recognizing from what I've seen within organizations is being close to the day-to-day operation makes you relevant because you can actually change stuff. You can actually impact stuff. You do things that are urgent. So from that point of view, it makes sense to actually be really close to the business. The other thing that I'm hearing you say is maybe there should be, let's call it a service design team or unit, which is more related to and closer to strategy and defining influencing. And I was looking for different work informing strategy and also being able to trickle down that strategy maybe into operations. Is that something that aligns with how you're thinking about this? Absolutely. Like strategy is just what's your plan, right? And does it have good rationale and firm backing and correlated to ultimately what is the vision that is driving your company. But the horizon of that strategy, I think when you're nested within the core business tends to be more near your term, right? Because again, when you're public, you have results. You've got numbers delivered. There's an investor community that's looking to see how you've performed against the market expectations that you set. So by nature that you are more driven to the immediate stuff. Go fix that pain point. Or we're seeing clearly that particular channel or something that's happening in that app or that part of the support experience that needs to be addressed. And we've helped the team understand what that needs to look like and what those changes need to look like. Those are the types of things that tend to get front and center and the lion's share of attention, resource, and dollars, if you will, and so on. This will be a topic that is going to be discussed a lot in the coming years, I guess, because service design teams are popping up everywhere internally and how you organize them, where you place them in the organization has a big impact on what they are actually able to deliver and how they are going to impact the business and the customer experience. Absolutely. We are working on a CEO or C-suite level initiative now, which thankfully, because it does need to come from the top, looks at what do we need to do when everyone says, right now, innovation, how do we enable innovation? What does that mean for your organization? For us, it means the days of the hockey stick effect on data consumption and people just having an ending appetite, especially with unlimited plans, is gone. So all the dollars and growth that we saw, we are not in a phase where we are in that period of growth. So innovation for us means where is that next wave coming for? So it is forcing us, when we look at some of the growth trajectory and comparing it to where we have been, to say we need to be looking out further ahead, can't just be some minor feature enhancements or tweaks or pricing changes that are going to drive the growth for us. And so that, as you said, like there's different service design teams are coming up, that's becoming an area of focus for us, thankfully, right? Because right now, I said the large part of our work has been kind of more near term and how do we fix this or what's the next feature? How do we enable this and so on. Final question about this topic, is there an example or research or something that inspires you about this topic, this team? Well, we talked on this a little bit earlier and without going too far into it before we can reel ourselves back in. Oftentimes, organizations that are starting out, we're really interested in this practice. What's an ideal way to orbit? And again, it's kind of always the disclaimer that well, there's not one size fits all on this, only to say here are the things to watch out for. And I was asked this very recently to say, do you think it makes more sense to have a team like yours, like the way that you operate within the digital team or within like a specific channel, if you will. And my thought is, it can sit anywhere, right? At the end of the day, it's an org structure. But the watch out for that is, by virtue of you being within a particular business unit, it has implications in terms of the metrics for success and the objectives that particular business unit has. So for example, and I'm only just using digital as an example, if you have a design team, and I'm not talking about UX design or what's happening on the web development, but if you have a service design team that's looking at more end-to-end client experience, if you think about what digital's objectives are, it's the drive as much because it's lower cost to serve, traffic and support experiences and interactions to the web. So that is the core things that that particular channel would be looking to achieve through all the work that they're doing. So if you have a design team, that unless you can have kind of the wall which separates the rest of the web objectives to this team, the tendency will be to always try and look through or force fit the experience and channel it into that particular channel. And that people need to be aware of when they're making those decisions around organizational structure. So what is the ideal experience would be not to be located in one aspect of the customer journey that your objectives may inadvertently drive you to make decisions that may benefit that particular business unit but also give up like then lose sight of kind of bigger picture. So I would say that's one watch out. I didn't know this thought earlier, maybe I'm losing it. I think just to the point I made earlier about where it sits, does it sit in the business outside the business? Oh and then the point we said about you can go deep but how do you have a team? You may consider multiple teams, right? So we have teams that are looking at anchor experiences which we call what are the pivotal experiences for your customers that these are the ones that you have to get right. Like when you're doing TV moves, like what's the move experience you think about? Internet is like water. So people don't want to move to a new home and not have their internet set up to wait for technicians to show up and fire their home. So those types of experiences what we call like anchor experiences renewing or upgrading your mobile phone, your repair, if you break your mobile phone, those are like key moments of truth. So we do have a team that looks after anchor experiences and their full role is ensuring that those anchor experiences don't get broken. And then you have a team like mine who is then hired by other internal team members who are going deep. So somebody has oversight over what is the full renewal of a mobility contract look like and the channel team might say, okay we have this part of the tapping in store, service design team, can you come in and help us? What is the rep support experience like for a customer that's coming in during that piece? And we're nesting those two together. So you're focusing on deep experiences but you're never breaking the entire end end journey. I think some people at HR will start crying when they have to make these orchards. Never easy stuff, right? But this is why design exists because if it was a silver bill with easy ideas, they would have already been done. It's time for those ones that are passed. All right, cool. Really interesting. We could talk about this for a long time but we have one topic left which is also dear to your heart I think. And this is the third topic. Public versus private sector. Please surprise us with a question around this one. Okay, how much? Did I do what if already? You can reuse them. There are no rules here. Okay, how far? Maybe, yeah, maybe it's how far and how wide can design thinking be applied, right? We had our more conversational chit chat talk about when we look to places outside of where we see maybe standard design thinking organizations, government and so on, we find that people in copyrighting, people in the creative arts, chefs, musicians, there are natural things that they're inherently or intuitively practicing that align to design or follow some of the design methods. And so we started with public versus private sector and there are no limit to where design can be applied. Maybe that might be the question. And we need to be careful that we're not making it sound as if design is a panacea. Like it's going to solve all the ills of the world. But I think the way that we need to think about it is some of these tenants and values of design, which is ultimately about how do we bring diverse thinking and perspectives to the table to help drive better understanding of problems and then out of that more thoughtful and wider expanse of solutions. I don't want to say that that's like design thinking because it's almost trivializing it. Like that's always good practice. No matter what situation you're in is to think outside of my mental model of how I'm seeing this, that shape from my personal experiences, my education, my work experience, my lived experience. And always think that that mindset will can never go wrong, right? So in doing the public versus private sector, there were clear differences in the way that we had to approach the work. Some of it was very similar, of course, right? But I would say primarily, if you ask the question, is design going to solve everything? It's maybe not the methodology is always going to be like a right fit sometimes. And we say no to projects that come up. It may be things like where there's already kind of a known narrow discrete set of solutions. The problem is fairly well known. I would say this is a lean problem. I go go to the engineers or the lean six six experts and just crank it out, right? Or if it's a specific process thing, figure out where your bottlenecks are. And again, use a process methodology to help you there. So I would say it's not it'll solve every problem, but the core tenants are abstracted from calling it design thinking. And it's more like just like good sense, like good, just good logical sense to say, more people you can bring in that can kick the tires on something and contribute potential ideas. That's always a good thing. So anyways, the public to private, how far can we go with it? Wow. I really was quite intimidated and I don't want to repeat the talk. I was quite intimidated when I was originally brought on to that project and just the magnitude of the problem statement that was cited to me. And of course, as you sort of have to say, okay, I know that this process works, right? I've seen it enough times. And even though this is a much different aspect in the public sector and it's much more complex, it's an area that I don't know as well. There are people that are involved in this project that have that. Like I'm the shepherd of the process, if you will, to achieve the outcomes. I don't have to hold all the knowledge and maybe the stress and feeling the accountability on my shoulders. And that helped me maybe just get my bearing straight and get my wits about me to be able to affect that. And I would say just in the public sector, the core difference being just the sheer magnitude of the people and the considerations and things like politics, which obviously also happens in corporate organizations. But just the magnitude are much bigger. And often in business, you're always trying to get to narrow the scope, right? Figure out the scope. We can't design for everybody. Who are the real customers? Who are the ones that are going to be most profitable? Like who is this TV solution actually designed for? And let's understand what the value proposition is, how to reach them, how to market to them, and so on. And then how to service. Public, it's the opposite. It's like you don't leave anybody out, right? It's everybody, right? When you're dealing in the public sector. So then the problem becomes, like how do you have solutions that are broad enough that get the maximum reach for citizens, right? Like education, health, like this is something that everybody needs, right? So it's not to get thoughtful inclusiveness approach. So that would be the primary difference. So after having going through this public sector challenge, has your perspective on how far the design approach can go changed? It's, if anything, it's reaffirm. I'm kind of like, okay, I know governments are using it. It's a big thing. I'm in corporate. That's pretty complex. We have corporate business systems. It's technology. That's pretty complex. And so I always knew government was using it. I now have a complete reaffirm belief that the most wicked and complex problems, things like transit climate change, really benefit from some of these core aspects being brought in to help unwind or drive pieces of solutions, right? Because there's never one solution that's wanted to fix everything, but pieces of the solution together. So if anything, it's reaffirmed my belief that there's no problem too small that you can bring in some of these practices and bring in these peoples and the thinking to help get to a set of solutions. I fully agree. Well, I sort of have been a believer for the last 12 years, but seeing these kind of examples, again, like you said, just reaffirms this belief. And I think we're still just at the forefront where the moment we unleash the design approach and mindset on the youngest generations, and when they will take it and start running with it, then I think we'll really see the power of what we're doing here. 100%, rather than beating it out of them through our education system and then having to reteach it to them later, why not let them keep going, right? These are natural tendencies. Why not foster this and let it flourish? And these are, like, to be honest, they're the ones that are going to solve these problems. So develop their thinking through frameworks and methodology and encourage it and hone it so that they're set up to be able to help solve these problems, which ultimately they will inherit, right? We will not solve these problems in one generation. Judy, before we wrap up this episode, I want to give you the opportunity to ask the listeners and viewers of the service design show a question. Is there anything on your mind that you'd like us to think about to honor upon? Sure. I'd love, if you guys, if you can send up my contact details. Again, akin to the discussion that we were having informally before we started on this podcast, is I'm curious about some of the fringe or non-traditional places where other practitioners had been applying design or even if it's like a small little corner of a problem that you wouldn't traditionally think about working with design thinking to help solve. Please, I'm just so excited to learn about how many different ways in which it's being applied and used and driving some results and outcomes. So please let me know. So am I. So please let us know. Judy, when people want to reach out to you, what's the best way? LinkedIn, Twitter, where are you on? I'm on LinkedIn, Twitter. You can Google me and find my details. And it's LinkedIn, Judy Mallett. So it can't be any simpler than that. Cool. I make sure to link to that today. Judy, thanks for making the time from the beautiful Toronto. Happy to have you on. Great listening to what you're doing. And thanks for sharing. Thank you so much for having me. It was fun to talk to you. So whether you see design being applied outside of the design field, of course, leave a comment down below, join the conversation and let's see where this takes us. If you enjoyed this episode, grab the link and share it with just one other person today. You'll not only inspire them, but you'll also help to grow the service design show community and help me to get more interesting guests like Judy on the show in the future. Thanks a lot for watching. I look forward to see you in the next video.