Safely creating autonomy in the workplace - Jasper Sonnevelt at FlowCon France 2019

[00:00:00] Hey everybody. Seven years ago, and I got to sleep in the Airbnb with the organizers. So, look how the company, and there were 70 or 80 people. So, look how the company, the the the the conference grew and how it evolved. I really like it. It's really cool. So I'm I'm glad to be back. Um, I will be speaking today about creating autonomy in the workplace. So, who was in Carl Scotland's talk yesterday? All right. A couple of people. All right, so you will see the number of slides that are mostly exactly the same. Is what I found out yesterday when I was in Carl's session.
[00:00:39] Um, I will mostly talk about, so let me tell you about myself a little bit. I am a consultant. And I made up an interesting title for myself, at least one that I thought sounded interesting. I don't know if it works, but that's what I did. What I do is I help organizations get better at what they do and particularly like working with management. Um, it's a it's a I have the pleasure to work with a lot of managers. Um, it's an interesting arena to be in and I think there's a lot of impact to be made because what I'm learning is that they mean well but are often misunderstood. So this is one of the talks I created to talk a little bit about around um autonomy because autonomy is a word that's been thrown around for the last couple of years left and right by about everybody who wants to do something agile. And it's it's much harder than it looks, um, and a lot of people struggle with it. So I thought, well, let's may let's maybe just put a couple models together and make a practical talk around what you can do as a manager or what you can ask from your manager if they tell you to be autonomous. That was a joke.
[00:02:00] All right.
[00:02:05] Yeah, take the time to read. There's a lot of stuff in here. I'm not allowed to repeat. This is what management is seen as in some organization, some organizations. Right? So I first came across this picture when it was hanging on a coffee machine in a in a company where I was um hired to help out. So this is a massive tell about the culture in that organization, right? And I'm hoping I'm hoping to be able to do some things that um that help help change that perception a little bit and to to make it a little bit more tangible. So we're talking we're talking about autonomy and we're talking about um implementing practices when we're doing agile or lean or um most new frameworks strive uh to make sure that people can have more fun in the workplace, right? Get more motivated, get more uh enthusiasm, get better results and and hopefully make the company a little bit better. So, um, I've I've got a list of the books I'll I'll mention but I want to talk about a couple things. Dan uh Pink wrote a book that got turned into a YouTube movie that is much shorter. So if you want to if you haven't read the book, um and you don't want to invest the time, um there's a video on YouTube explains a lot about this. And he talks about motivation and how to motivate employees and he says there are three things that we're seeing. We're seeing that um in order to motivate people, you need three aspects to be there in order to in order to make people successful. Autonomy, mastery, and purpose. Right? Autonomy is our desire to be self-directed and I'll talk about that one a little bit more because it's in the title of the presentation. Mastery is about skills, about being good at something, and purpose is about moving towards um something that has meaning or is important. Right? So that means for you personally or for your organization.
[00:04:20] If you look at the Agile manifesto, there's actually not really anything in there around how teams work, not on the front page. But if you look a little bit deeper, what you'll see is that this is a recurring theme amongst the practices that we that we use use in every day. So, if you look at the principles, what you'll see is that there's a that there's a that there's a principle that says build projects around motivated individuals, give them the environment and support they need, and trust and trust them to get the work done, get the job done. And the other thing that's in there says the best architectures requirements and designs emerge from self-organizing teams. Sounds pretty good, right? So how do you do it? No answer in here. Scrum says, Scrum teams are self-organizing and cross-functional, and self-organizing teams choose how to best accomplish their work rather than being directed by others outside the teams.
[00:05:24] Sure. Conban says leadership at all levels.
[00:05:31] So
[00:05:35] Let me I'll I'll get back to that one. So, so what I was seeing is that there's a lot of consultant speak, um, around what you should do and what you should build around your teams, your people and your employees, but not a lot of stuff that actually helps you do it.
[00:05:55] So, autonomy is autonomy is a scary thing. So, raise your hands. If you think that um if you give people unlimited days off, so as many vacation days as you want. Who here is sure that people won't take the year off?
[00:06:19] All right. That's a good amount of people. Who thinks they will work more than they would if they had a fixed number of days? All right. Who thinks they'll work less?
[00:06:33] All right.
[00:06:35] So, um, there's some there's some experiments going around by organizations doing this. Um, generally what we're seeing is that I don't know if it's a good thing or a bad thing. I don't think it's a good thing actually, but what we're seeing is that as soon as people get unlimited days off, um, people will will take less vacation than they would before. Um, don't know why it is, might be just general stress, but what we're what we're seeing is that we're getting a result that is a little bit counter counterintuitive to what you might initially what you might initially think.
[00:07:15] So, if we dig in a little bit deeper around what self-organizing teams are and how they work, um, Scrum Alliance says the following things: So self-organizing teams pull in work themselves and don't wait for work to be assigned. Right? So they manage their work, do the allocation, reallocation, estimation, reestimation, delivery and rework as a group. I like all of the Reese in here, by the way. They continuously enhance their own skills and and recommend innovative ideas and improvements. Um, and that's how they collaborate. That's how that's how they work together. But there's a pretty big leap if you're going from in an organization from teams that are fairly managed fairly uh fairly directively uh to autonomy, right? So one of the mistakes I've seen organizations make in my in my day-to-day work is that they say, well, we looked at this whole agile thing. We think we thought about it a little bit better than most people have, and we think it makes sense. There is some we we read the book, we watched the video, we think there's there's a good point to be made around the self-organization of people and having autonomy in your organization. Do it. Go ahead.
[00:08:38] Now you can be now you can be autonomous, right? But the problem is autonomy is not a flip you could a switch you can flip. It is something that needs to grow over time and that is very easily destroyed if you if you're doing it wrong. So, what I did is I tried to figure out what's going on here. Why is this and why is it so hard for managers to let go of let go of control in a in in just enough uh in in in a just enough way so that people can learn to be autonomous and other um and managers don't feel like they're losing control. Right? So what I did is I dug into what is this whole autonomy thing. Looking it up on the internet, just type it into Google. Here's what you come up with if you go to Miriam Webster, right? So there's a whole definition and I like this second one. So self-directing freedom and especially moral independence. Because there's a word in there that I don't get. So more Googling. Moral independence arises in late childhood where individuals now believe that they can make effective moral judgment based on considerations about the motive. All right, starts to make a little bit more sense why we want autonomy. All right, still a word, I don't understand. The motive is something that causes a person to act. Why does that sound familiar?
[00:10:10] Here's another word you can use: purpose.
[00:10:14] So, here's here's my meshed together of all of the words. Autonomy in the workplace means being able to do things your own way while you're working towards a common purpose or goal. All right, so far pretty straightforward, right?
[00:10:34] If you look at the Spotify videos, you've probably seen this picture. If you haven't seen the Spotify videos, you probably have seen this picture anyway, somewhere. So in Henrik Kniberg's video, he he explains something around balancing alignment and autonomy. Where um autonomy goes back to this definition here and alignment goes into the level of purpose and how you describe it. So if you're if your alignment is too high, what you will see is that people don't really feel comfortable. Um, managers are very specific about what they want and how they want it. If your autonomy is too high, people just do whatever they think is right. Which is not necessarily the right thing, shocker.
[00:11:24] So autonomy in the workplace says something about how much freedom a person has in the way that value is being delivered. Right? So it all goes back to value and value for the organization. The fear of managers usually is when we talk about this and say, hey, you need to you need to give your people more freedom is that their teams will go, we can do whatever we feel like. There's a whole bunch of stuff we didn't like and we're not going to do it anymore. We've seen this with the Agile manifesto and the whole documenting thing and requirements thing.
[00:12:03] Managers actually have a different fear, but it's voiced in a similar way. And they say we can't have that suddenly team that a team decides that selling bikes is the best thing for our customer. We're a bank. We're not in the bicycle business. This is an actual quote from one of the uh C-level executives at a at a former customer I worked in.
[00:12:29] And it's an interesting thing to think about because if you if you take autonomy a little bit further, it would make sense that, sure, why shouldn't why shouldn't your organization be able to pivot towards a bike shop? The other the other thing is that might not be what our investors and stakeholders and shareholders or our customers are really willing to pay for. The reality of the situation if you look at the teams is that as soon as you let go of of all boundaries, tell them, you can do whatever you like. There is a massive spike in fear, anxiety and willingness to experiment among teams. Which is basically crippling for the organization. And that is not a good that is not a good thing. So what we're trying to do is we're trying to balance autonomy and alignment and I know Carl talked about a third axle, but I'm not going to go into that one here.
[00:13:28] Um, in a way that people have enough have a good enough understanding where what problem to solve but don't feel controlled. Right? They don't feel like it's a lack of trust and managers can actually actually feel like they're not being naive about how people work um and where they're going. Call it freedom within a frame, right? So you can do whatever you like as long as you stay within these boundaries and that's not as scary as it might sound.
[00:14:00] So we're trying to get a certain level of organizational clarity on goals, behaviors, structures, and priorities.
[00:14:08] David Marquette came up yesterday in the keynote as well.
[00:14:13] Um, it's another video. You don't have to read the book. The book is really good though. Um, but the video is shorter. Talks about the framework of giving control and what is needed to give control is technical competence and skill and organizational clarity. The thing that we forget about a lot and that managers forget about a lot is that you can be as clear as you like. You can make the purpose of the organization, you can make all of the boundaries crystal clear, you can give people all of the autonomy in the world, but if they don't know how to deal with that, um, you still won't be able to give give control because you don't know what the end result end results will be. And one of the most important things we talk about is that direction is more important than speed. Um, I once had a manager, my manager, tell me when we were in a in a heated discussion about why he didn't appreciate me as much as I thought he had to. Um, where he said, you've been, yes, you have been working really hard, but look at it like this. You've been running to catch the bus, but you were running in the wrong direction.
[00:15:32] Right? So it's more it's more important to get everybody on the same page and moving in the right direction rather than going fast. Which is one of the things that um lower maturity Scrum teams do a lot. So they deliver stuff faster. But it's not necessarily the right thing and they don't do the check to see if it's the right thing. So in order to focus on results and to get to get a um to get a little bit more practical around what you can do, um, to get clarity into to bring people into the right direction and and by doing so give more autonomy. There's a this is very, I hate it when this happens. There's a very good book that's written in a language that most of you don't speak. I'm sorry.
[00:16:20] So, it's not a big book, though. Um, so it's written by Philip Van der Driessche, who is a Belgian guy, so he should know better. Um, and there should be a French version, but there just isn't. So it's not that thick, you could technically Google Translate your way through it. Um, but I took some I took some parts out of it, so you might not you might not have to. And he writes, so the title is it's basically leading without commands. So, being able to and and the subtitle is the output manager. So, focusing on output or outcomes rather than telling people exactly what to do. And he says the difference between whether people come up with an acceptable solution or an unacceptable solution has a one-to-one relationship with the amount of organizational clarity. Do they understand what they're looking for? And he uses a um inverted pyramid um that looks like this to manage for outcomes. Um, by the way, I'm using the word outcome where he uses output because it aligns better with my frame of mind. So if you're if you're getting if you're getting confused, output for me is the physical thing that comes out. Outcome is more towards intent.
[00:17:39] And he says the top is facts and figures. Then below that is forward-looking scenarios or intent. Then there's criteria, so the boundaries that the frame is built up from, and then there's solutions.
[00:17:56] So if you're building this, and I'll go through a couple of examples as well. You got a current state definition, you talk about what should be achieved or what's the intent, um, the constraints of that solution, and then the potential solutions that are left. So let's look at an look at an example.
[00:18:17] Let's say that our we are a software company. And we have a product but our direct competitor can release three months faster than uh than we do. So we're at risk of of losing half our customers because the we don't have the features that we need to and all of our contracts are up for renewal. Right?
[00:18:42] So what we would like to have is we would like to be able to stay market leader, avoid downsizing, having to fire people, and because we're not able to pay their salaries or wages. Um, in order to do so, we're looking for a solution that allows us to do the following thing. We're looking for the ability to release within one month of our competitor. So we don't have to release the same thing, but we want to we want to be able to release within a similar time frame. Um, quality must stay up. Um, because you know that that's the first thing that's going to suffer. Cost of development cannot go up by more than 10% because we'll run out of money anyway. Um, and we cannot throw more people at this.
[00:19:34] And then there's a there's a number of acceptable solutions.
[00:19:39] If you're in a management position or if you're working through a framework like this, there is virtually no good way to work above the line and work below the line. So there's a group of people that set the framework and and define the criteria and the goals, and then there's a group of people that come up with the solutions. So managers are typically above the line, uh people that actually do work are below.
[00:20:13] So there's a and then there's a then there's a difference between input or output that they talk about they talk about in the book. And the the difference between input and output is input means I tell you what to do. So this would be a decent framework for output. This would be a decent example, it's not perfect but it's decent. ability to release within one month of our competitor. So we don't have to release the same thing, but we want to we want to be able to release within the similar timeframe. Um, quality must stay up. Um, because you know that that's the first thing that's going to suffer. Cost of development cannot go up by more than 10% because we'll run out of money anyway. Um, and we cannot throw more people at this. And then there's a there's a number of acceptable solutions. If you're in a management position or if you're working through a framework like this, there is virtually no good way to work above the line and work below the line. So there's a group of people that set the framework and and define the criteria and the goals. And then there's a group of people that come up with the solutions. So managers are typically above the line, people that actually do work are below. So there's a and then and then there's a then there's a difference between input or output that they talk about, they talk about in the book. And the the difference between input and output is input means I tell you what to do. So this would be a decent framework for output. It would it be a decent example. It's not perfect, but it's decent. Um, input would be, we need you to deploy, I don't know, install continuous delivery in the organization. Something like that. So it's very specific, it's almost smart and it leaves no room for imagination. Here's here's the hard part. So, input and output can be relatively close to each other. So, if you if you take a number of examples, resolve this priority three incident within five days. Input, right? It's a very good input example. Just resolve this incident with a work around. Who thinks this is input? All right, input, clearly not output. Because the work around is still defining what you need to do. Improve our internal communication by using Slack instead of email. Yeah, it's getting trickier, but it is input, you're right. And then it gets harder. Use it use the um, design a small experiment to figure out what our next steps should be to solve this problem. We're not saying what you need to do, but we're hoping you're going to design an experiment, right? Um, is this who thinks this is output? Ah, this is just bad management. So, what do you think is the best way to do this? That's never an that's even from a psychiatrist that's not a good question. Um, that's what Agile coaches ask. Um, so, well, it's it's it's tricky, it's a tricky, it's a slippery slope to be in and it's really hard to do. So let me let me see if I can build a little bit more context around it to give give some ideas on how to build output based statements. Um, if we're looking at a cascade from the department or the organization down, all the way down to work, this there should be a relationship. So hopefully, we have a purpose somewhere over here and we have a bunch of work being done over there. In between, are goals, maybe team purposes, if there are multiple teams working on that, teams have their own goals. Um, and then they have work being defined as epics, features, user stories. So this is a very nice little ladder that you can use. Hopefully, if you if you start at the bottom and you go, why, why, why, why, why? You should end up with the department purpose. And if you're um, if this is the way you design all your goals and objectives, that's impressive because I've tested this and it doesn't work. But it's a sorry, for everybody taking pictures. Um, it is a it's it's a decent model. So where this where this model goes wrong is if you have multiple teams that have more autonomy that might work for multiple departments or work on something in their purpose that doesn't necessarily align to the department purpose. But fundamentally, all of the work that a team should be doing should be able to uh, be tied to or related to a higher level purpose, hopefully in the organization, um, that you can measure and that you can work towards. There's a lot of ambiguity and the biggest mistake people in a management role make is that they think they need to provide a solution for everything. Um, so there so there is one type, I can say, yeah, I can say this. There's one type of people that makes this mistake more than the other type of people. Um, men. Um, so men are particularly, so my girlfriend tells me, are particularly good at giving a solution when there's none asked. But the the thing managers need to do is set their boundary clear and make sure that they define the constraints and have clarity around the goals and where to go. So that means that you're talking about, you're talking about a number of aspects. Company vision and purpose, it's one part, but not everybody is working towards that and not at the same time and not going everywhere. There's a there's a there's a possible set of solutions, but if you're in the uh, pharmaceutical industry, a lot of those solutions are just not safe. Right? So depending on your context, where you are, the type of company you are, the um, there's a there's a there's a number of constraints that limit the amount of solutions. There's a set of acceptable solutions and it's it's the role of the manager to make sure that those are clear. The difference between acceptable and unacceptable is the amount of organizational clarity. So, if you ask people to come up with a solution, the more information you give them, the more it will lead them to find an acceptable solution. And if people don't find that solution, that's the manager's fault. It's not the people's fault. Which is something that is hard to accept if it happens more often and more often. Because that means that um, as a manager and I've I've been here in in a management role, um, you think you're being clear. And you're think you think that whatever you try to achieve is so easy to do. Except you forget about explaining it the right way or equipping people the right way in order to get there. So how much is enough? For people that work in um, a management position, and this is a funny, this is a funny story. I was Googling stock photos to put in this presentation. I Googled manager. You want to see what it looks like? First hit, first hit I got. I feel sad for picking on the guy, but that yeah, I I got to say there's uh, that looks like a manager. One of the ways Carl talk Carl talked about yesterday is back briefing, right? So, making sure that as a manager, you ask people to explain the question back to you and explain the constraints back to you. That'll take time, but it's a valuable way of doing it and it's a good way of understanding if you're a manager, what people know and what they don't know. The other thing is just being transparent. Be be transparent on where you're going, what you know and what you don't know. Uh, communicate intent. This is what we're trying to achieve and make mistakes. You will get it wrong. You will give them too much information. They get angry with you. You won't you will give them not enough information and then feel like you have to spend a lot of time making them understand that the solution they come up with with was actually not not as good as they thought it was. It'll go wrong, just make it make sure that you don't experiment in a way that's unsafe. For teams, there's a there's um, there's something else that you can do. So, if you're a manager or if you're working in a team trying to implement that, there's an instrument that you can use. There is no word for this. So, um, we made a word up um, during lunch. And I'll show you I'll show you where it goes. Um, in the book, the authors talk about auto control. If I just say the Dutch word in an English way. What that means is that you set up um, you set up a mechanism that helps you verify if you're on the right track or not. And there might actually be a word for this. So if you know it, please let me know because I'm I'm struggling to find the English word. There might be a French word for this. Which is probably auto control. Right? Realizing what I'm saying it. Um, but the mechanism means that if you're doing something, you understand if you're in the frame or without or outside of the frame. If you're doing the right thing or if you're completely off course. So, the way you can use that is to balance the uh, autonomy and alignment in the right way. If people cannot verify themselves because they don't have enough organizational clarity or because they don't have the skill, that means you might have to do more alignment or more explaining. If people don't understand how to do it, if they don't understand how to self-verify what they're coming up with, um, that's a good question for them to ask to the manager, right? So, all right, just yell it out. How what's a form of self-verification in Scrum? Retro? Yes, it's one. Did somebody say definition of done? Yeah, that's good. Yeah. That's a that's a way that's a way of verifying if what you're doing is the right thing. And if it would fit with the acceptable within the acceptable solution. Um, what you what you'll see is that you can be very cle No, I've never seen the large organization being really clear on where they wanted to go in a way that teams could actually translate that to what they were doing. However, it is possible to translate all of the um, the goals and purposes at different levels of the organization to a uh, format and granularity that that specific level can understand. So what that what that would mean is that you get the triangles, the the pyramids are starting to interconnect on different levels. So, what that means is that on the board level something might be considered to be a solution, but it's so big that the only thing it will do is it'll cascade down to a lower level in your organization. For them, it might actually be the current state. So it might be the highest level of the of the pyramid. This is this goes all the way down and what that um, what that can mean is that I don't know if you've ever seen it, but there's a there's a discussion that every now and then comes back between a product owner and a team. Um, where they're doesn't matter what they're doing, but the customer's asking for something and they are really specific about how they want the solution to look. It's worth looking into if the product owner in that case is just providing trying to provide more organizational clarity than than they actually have to. Or the team just doesn't want to build it like that. Interesting thing to look at. So back to our example, right? So we had this one, we didn't know what the solutions were. This is, let's say we are a 10,000 people company. Right? I don't know if this is the right level for the for the top level, but let's just pick one. Let's say that one of the constraints that we're seeing is we must be able to release no longer than one month after our competition. And that one goes right into the IT department. So now we have, let's call it intent that says we must be able to release no longer than one uh month after our competition. And we can describe a problem at this level. So what we're seeing is our market our time to market has gone down. Um, and we don't have or our has has to go down. And we don't have money to hire new people. So what will we've like, what we what will we like to have happen? Um, well, here's what we want. We want to release more often in in about six months. Um, here's our criteria. Some are the same. Quality must quality must stay intact. Quality must stay the same. Um, production must not slow down. We cannot we cannot reallocate all of our capacity into from our bug fixing departments into our continuous delivery department. Um, and we want to be responsible for our workforce. So, we're not going to let people work overtime. All right, so come up with the solutions. So this is a lower level, um, This is a lower level cascade of a similar problem. Hopefully, if we're doing it right, let me so here's here's another cascade here's another cascade down. Um, with the with the same similar example. Hopefully what we're hopefully what we're seeing is that all of these triangles tie into each other uh, and connect to each other that ultimately, if we're looking at I wish there was a better way to do that. Ultimately, if we look at the problem that we've circled here and all of the pyramids below it, um, hopefully it helps us solve at least part of the problem that we're facing at the higher level. Right. Yeah, all right. So, a clear organization is a healthy organization, right? So ambiguity leaves the door open to politics. If things are not clear in the most positive way of saying it, if things are not clear, you're letting it up to people to decide what the best way forward is. That might not necessarily be aligned with your company goals. That might be closer aligned to their personal goals. It's not even not even true per se to say that they have um, bad intent. They might mean the best for the company. They just don't understand. Politics are the enemy of safety and trust. So hopefully, Um, hopefully by getting safety and trust in, politics goes down a little. So the role of management in this is at the strategic level, make sure that there's a clear vision and direction. And that is easier said than done. I'm working in an organization right now, um, where for everybody there in the room, the strategy and vision are and direction are absolutely crystal clear. I look at it, I have no idea where they want to go. Right? Could be me. It's probably me. But let's assume let's let's assume that there's a lot of context I don't have that other people also don't have, right? So help managers help managers to make their uh, make their their strategy clearer, show their direction clearer. On a technical level, set priorities, create focus, which means saying no, we're not doing everything. Create a focus, make sure that you're making deliberate choices, um, and create a healthy ecosystem and structure. The best thing a manager can do is say, let's get together and decide what we're not going to do right now. Because for for some reason, I've never I've never seen an organization where over time work didn't become more. Work always became less and then people start taking less vacation and we're in a vicious circle, circle and people burn out. Give power to teams and let them experiment. Right? So back to the whole um, thing around you'll make mistakes as a manager. If you know you're going to make them anyway, just let the teams make them for you. Let them have some fun with it. Let the let be surprised with what they come up with. Um, it is a very comfort it should be a very comforting thought that you're not the smartest person in the room. Because that would mean that you should be doing the work and they should be managing. Um, so let them let them come up with be surprised. Um, and let let the teams decide on what let the teams decide on what to do. So, you can you can grow autonomy in the organization based on based on the amount of skill, based on on how good they are, how well they understand the context. You can give them more and more and more autonomy. You can let a team, you can if you're a manager, you can put on the table and say, how much autonomy do you want in this? There are certain things a team feels comfortable deciding, there are certain things where teams typically will say, we're not really sure. And it's a conversation you can have, right? Draw a line on the wall and say, full autonomy, no autonomy whatsoever. Where do you want to be as a team? Where do you guys want to be? Where do I think we should be on this? And then you have a conversation with them. You're a manager, you can always overrule them if you have to. Um, but it's a good conversation, it's a good conversation to have. So, and then adapt your your checks and balances and your your things you're checking on, reporting on, uh, and your governance based based on this. Um, and become a facilitating leader. So facilitating the conversation around stuff you don't know is actually a good one. I've learned a lot from that as a as a manager as a manager and and and therefore as a consultant later on. Um, protect the team from the corporate anybodies, which means that there will be a lot of things and politics in the organization pushing and pulling back on this. Um, protect them, be be the good be the good umbrella. Um, and then resolve the impediments that they cannot solve on their own. Keep in mind that autonomy in the workplace can only exist if there's enough clarity of roles. Um, purpose and purpose and desired behavior are important, but if people don't understand what they're responsible for, that makes it a lot harder for them to to act in a to act freely enough to uh, um, to be to be considered really autonomous. Um, management should only be providing guard rails and clarity, maybe establishing that strategy. But the most important the most important thing managers should work on is clarity. And solution are created where the information is. So, if there's a place in the organization where people have more information about the work, then that is where the solution should be created. Right? So in in David Marquet's book he says, um, you need to move authority to where the information is. Um, same same concept goes in the uh, the leadership book. The information, um, is with the people that do the work, it's with the people that create the solution. All right. Um, the books I mentioned, um, two out of No, three out of three have a video and I have not checked. There might be a video that has subtitles on that one. I'm now realizing. I'm actually, I'm actually not sure. The book David Marquet book and Daniel Pink book give you a lot of uh, references that you can use if you know the models with the triangle. All right, so we got I think we got a little bit time left for questions, right? Are there any questions? All right. Good. Um, thank you all for being here. I will try to beat traffic to catch a train home, so I might not be around for long. My email address and Twitter stuff are over there if you have a question. We're putting the slides online, right? Yeah. All right, so feel free to use use it all. Um, thank you.

Transcript