 No, it's not. It's flickering. It's flickering, huh? Okay. Just run it regularly. Let's see if that does something. Second, make sure nothing exciting occurred. Let me, you know what, then let's just run your record here and bypass this thing and see if that makes the same thing. Okay. It's already recording. Yeah. Stop it when it's started. Yeah. Now we'll just pass it through. Okay. So this one's got to go. The news is good news. Okay. And the audio is already recording. The audio will be off of your, just off of the laptop. So pick it up. To this pickup. No, it will just be the speakers built in. So I don't really need to be tethered. No, you don't need to be tethered. Hey everyone. Thanks for coming. I'm going to do perhaps a little bit of a different format today. And I've been talking about change management for a couple of years, but I'm in no way a professional on it. It is simply something that I do on a regular basis as a project manager. Am I speaking loud enough for the folks at the back of the room? Because I can use my like full on voice if I need to. So I'm going to start by basically getting you to tell me why you're here today. And then I'm going to give you some frameworks for addressing some of the challenges that you're currently dealing with, whether it's at work or in the Drupal community or wherever it happens to be. And then I'll share some of the stories that I have from the things that have been effective and the conditions of the conditions of stress that resulted in me needing to find solutions for the problems that we were having. So the first thing that I do want to do is kind of just make sure that I say change management. This isn't one of my get talks. This is the business side of change management. And we're talking about the transformation into a desired state. And so in this case, we're probably referring to Drupal 8 and the difficulties that we're about to undergo as development teams from a technology that we've been using for probably a number of years into a technology that is going to feel foreign and stressful. And from a site builder point of view, not that different from a development point of view, whether you're front-end or back-end, there's going to be a lot of differences. And how do we make that transformation over? My sort of general approach to working with new teams is to start at that point of coming to a common understanding. And I do appreciate that Whiskey is not required. But I have found that in a social setting and sort of that casual conversation about how things are going, what's motivating you, what's the challenge, what's the hard part. It could be laser tag. It could be whatever your team can come together on in terms of a non-work environment. This isn't a scheduled scrum meeting that happens on day X of thing Y. But in a casual setting, you can get a lot more information from people. I mean, one of the biggest challenges that I had professionally in most recent years, the transformation process started when I showed up at a work sprint, so we were a distributed team, when I showed up at a work sprint and said, okay, here's the bottle, Whiskey. And we're going to talk through what's not working. And it was from that point forward that we started to see the small wins that we needed to transform the team. So Whiskey not required, but I have found it to be an effective tool as a project manager. So I would like just to have you throw out some of the things that you're currently dealing with just so that we can get a sense of where the room is at, it may then also be if you look around and see who's got what kind of challenges that after this, you can support one another in whether it's boss here or whether it's just sort of ongoing. If you've got common challenges, being aware of who you might use as a resource in the future. So is there anyone that wants to kick off? Why are you here today? The answer may be because it would be easier than nothing after Karen's presentation. It's really cool with that. I have done that myself. I'm just checking email. Oh, goodness. It's not Karen anymore. I'm being recorded. I should probably not be quite as honest with you. Although transparency is important. Anyone? Yeah. So I've had in project management process. There's often many parties involved. Yes. And as the person who's actually building websites, there are often many decisions being made with personal agendas and competing personal agendas often. And so sometimes I'm privy to those and I can influence them. Sometimes I'm not. So at some point you come down to the chain where like there's a creative madness somehow has made it through the chain of things. And so I find that that is a challenge for I need to initiate change. Yeah. And but I may not be politically in a position. Yeah. In a position to see about actually not a good idea. Yeah. You know, whatever. And so those I would love to hear about creative ways of politely nudging. Sure. Yeah. Hurting that. Yeah. Yeah. Sweet. What are some of the other. Thank you. Or things that folks are. Yeah. Yeah. Yeah. Thank you. Yeah. Thank you. Yeah. Thank you. Thank you. Thank you. Oh, yeah. Yeah. One recurring thing is how to keep everybody in sync or up to date on what's going on without sucking up all the time and meetings. Yeah. Yeah. Absolutely. even I would say meetings are even worse for distributed teams because you have the or with when you have anyone who is remote or not because you have the context switching I was doing work and now I need to turn and think about getting into Google hangout is my microphone working is everything set up or Skype or you know whatever you're using even though I've been listening to audio and something else you have this initial friction for a distributed team to even begin a meeting so that they're even worse to suck people into meetings forget yes in the white teacher some of them are great and others just don't care I don't have it in the presentation but you will want to watch Todd near Kurt's who it's from the floor kitchen his presentation on creating empowering people to implement their own changes within teams and I think it was I think that was what he presented at Twin Cities Drupal Camp and I know I know it was recorded but he has given other things so Twin Cities in Minneapolis Drupal Camp which was this past weekend yeah oh yeah absolutely there was a next title to a presentation which was something to the effect it was a low-lot presentation on Martha Stewart something about changing the wheels at 50 miles an hour and they still have this concept of those little changes they want to make having potentially big impacts Jeff Patten's user story mapping that's a book you want to read I think I have it in the resource list but it's kind of different than what we're doing but that would be a good resource for you maybe one more and then I'll go into the framework so yes types in line so that was great I think to hear just a sense of where you're coming from the challenges are you dealing with right now and I talked about this for anyone who was at my presentation last year I talked a bit more about Simon Sinek's why I'm blanking on the full title of that right now and he had this sort of really great Ted talk of 20 minutes long but it's really great statement that resonated with me especially having run for election that we tend to as staff people want to work toward something so we want to know what the vision is and we want to work towards something however I can tell you that in politics working towards something doesn't really work negative attack ads are far easier to win supporters on and so when you're when you're implementing change we have this practice sort of in real life of moving away from negativity and being very drawn by negativity and yet to implement change positively in the workplace we need to teach ourselves how to create a vision and then move people towards that vision and one of the really hard things about change management is that if you can't get alignment if you can't get people excited about your vision expect to have what's the word that I'm looking for attrition expect people to either mentally check out or actually quit the job and be being prepared for that process being prepared for people not coming along for the ride is really what change management is all about I think he's got a lot of interesting pieces in terms of helping people to overcome that resistance and fuel the motivation and it all sort of stems back to well why are you even doing this and certainly for Drupal 8 why are you for saying people to learn Drupal 8 why as a developer have you decided to make that transition are clients demanding it yet maybe maybe not what is it that is your motivation whether you know you're the leader of the company who's decided to make this change or the developer who's decided to take it on because once you have that wide internalize it can fuel you through the process it can get people over that initial resistance of I don't want change changes too hard and if you are keen about it if you can see that future state then you can stay motivated when things get difficult so we we have this sort of less giving up so that's the quote that goes along with that one so that the frameworks that I've got for you there's essentially two with one kind of in the middle of expanding a bit on how to as a leadership team help people through it but there's two frameworks and they are sort of the they're recognized by business school frameworks that you will if you Google change management you'll see and the first one is the John Cotter do I actually say it on there I don't John Cotter eight steps to leading change or leading to change management and it's changed once so this is version two well this is kind of like version 2.1 these are my words on top of his his eight steps and the it was eight steps to begin with leading change which the original book accelerate is the the current book but there's essentially this process that you're going to have to to go through the first step is to create a sense of urgency the second step is to assemble a senior leadership change transformation team the third step is to create that vision that the new version is enlist a volunteer army my goodness does Drupal know how to enlist their volunteer army there's some interesting case studies in one of the Harvard Business School like top 10 blah blah on change management and about how to find your champions within organizations and some of you I like I recognize some of your faces you know that you're the internal champion for your particular company so you may be the volunteer even though you're paid and then enabling people by removing blockers generating small wins sustaining that accelerated pace of change and then finally indoctrinating that change inter-corporate culture now as a project manager I'm typically focused on this these three I don't know if the change is bigger here the enable enable people by removing blockers the generating wins in terms of helping people closing tickets and sustaining that momentum through an entire project so that's typically where I'm focused and often where developers will be focused as well as they work with me as a project manager leadership team those ones up at the top may be very very different very new concepts for you to grapple with but I bet you're really good at these three at the bottom if you are used to working on whether it's your own internal projects or or client sites so what can we do to actually ensure success during the project from again this is using my frameworks the external kind of like business management approved techniques they there's a lot of language and discussion around change needing to benefit the leaders because the the bottom-up approach is quite difficult so two of you managed some kind of senior leader position whether it was marketing or VP you know top-level folks if they're not on board that change management piece is going to be exceptionally difficult and so your sort of number one priority as a bottom-up change management person is going to be to figure out how can I phrase this what is the Machiavellian technique that I can use to make eat and just went Machiavelli what is the technique that I can use how can I phrase this in a way so that the leadership sees that this will be of benefit to them so is this faster to profit more clients like what is it that's going to motivate them the leader and how can you pitch it to them in a way that they can start getting on board with it the next one is to figure out again the why piece but coming up with those key phrases or key ideas that you can use within the company to explain why we're doing the transformation what the final vision is and providing the skills and upgrading for folks to be able to engage safely that's really important now a lot of cases what the training is that folks want is they don't need to know they don't like they don't need you to read the documentation for them they need to know where the documentation is stored and the rationale behind what the change was so why did we move to blah whatever twig why did we move to you know insert whatever the technology is here I can look up as a technologist I can look up how to actually do stuff you don't need to handhold me through those parts but you need to explain the thinking that went behind why that technical change was made then we need to acknowledge resistance and help to overcome or counter people with the overall strategic plan well if you won't have a strategic plan of why you're upgrading to droop a late guess what it's going to be really really tricky to get people in alignment hate the word but it's a word with why we're actually making this change and then finally which I think this is a really interesting one is to provide counseling to alleviate fears and this is personal counseling this is not just we're making this change here's the you know here's the thing that you need to read in order to understand why but actually giving that that personal mentoring time and that support recognizing that changes hard people fear for their jobs and helping to make it an exciting change and then finally monitoring and fine-tuning so those are sort of some of the steps and then the the other thing that's referenced a lot is these sort of five stages of grief and although Elizabeth Cooper Ross's original definition was to do with with how we deal with death and it comes up very frequently in the business world for people who are going through a change management process if it's sort of imposed on them you're likely to see these there was a very funny tweet this morning which was a little bit different but their five stages of grief was something like and I it wasn't for programmers but it may as well might have been it was sort of self-loathe self-loathing anger hatred more self-loathing like I'm sort of like yeah I can see how not having a process to go through these steps may result in simply negative feelings and I think I think the final one was sweet sweet acceptance I I favored it but I can't I can't quite remember all the steps on it yeah so so recognizing there's a structure that other people have come up with there's some steps that you're probably going to go through as a company there are pieces out there that you can read more about and these are some of the emotions that you're probably going to be confronted with as your team goes through that transformation so a few of my kind of tips and tricks and I in the original presentation description I broke it into three sections these stories are very loosely tied to those three sections but I I think that that I I became good at working with burnt-out teams because of it's fair to say this because of my incredible aversion to conflict but I actually I'm a fighter and so I would rather not get started in conflict because it never ends well for everyone in the room and so I started getting really good at figuring out how do I read a room how do I interpret the information that's coming to me so that I can redirect some of those energies I can restructure a situation to reduce the potential for conflict and there's there's another book that's you know there's to do with team dynamics and one of them in forming a team is you have a storming phase where conflict is inevitable so I'm very quick to try and get out of that storming phase and figure out okay well this person is an introvert they fantastic person they're going to bring positive amazing ideas to the table but I need to give them the questions ahead of time so they can show up feeling prepared and empowered to actually present that information and not come to me three days later a very passive aggressive kind of way unintentionally be like hey so I've been thinking about it some more like no give them the time ahead of time to think about the problems but but a lot of these tips and tricks that I've come up with and are things that I've stumbled into and I think the the trick for me was as I started doing these things recognizing that it was a technique or a pattern which I could apply in other situations and starting to take notes about what I did at work and what did work and what didn't and thinking of it thinking of my management as an iterative process thinking of it in terms of like split testing like I'm gonna try that with this group and that with this group and see which one's effective and then maybe you know drop the technique that's not working so the first one that I have was the the agile schedule and I I have begun to think of the scheduling as sort of a marathon training and I have never completed a marathon but I've trained for marathons and the the basic structure is that you build up and then you have a recovery week you build up and you have a recovery week you build up and you have a recovery week so as you are planning out the sprint the project that you're working on with your team think about structuring the tasks that people will be completing in a way that they learn a little bit learn a little bit do something like they already know learn a little bit learn a little bit do something they already know learn a little bit do something they already know now I didn't taper it quite as much but there's also this concept in sports training where you have a taper at the end so the taper at the end in terms of the agile sort of more like client delivery process this is going to be your your final perhaps your final QA period if you do that as a separate sort of final push this gives you this visor a little bit of time at the end for unexpected things but really you know not ending on hard stuff ending on really easy stuff so that you've got that extra time in place so the the I guess the the one that is the story that comes to mind or the story that I've got written down for this one is to also think about how can you over the course of the sprint or over the course of the project rather sorry iterate through and plan to replace what you're actually building so how can you learn incrementally during the project while exposing functionality and I do if you go to your new computer open get the teams calm there's a link there on the home page to the resources for this there's a link about five steps to innovative infrastructure and the the line that I keep remembering is plan to replace and I've done this in springs where we knew at the end we were going to have to build a PDF generator it wasn't a Drupal site but we knew that we were gonna have to build this thing and quite frankly the dev who was going to end up being responsible for it was kind of freaked out by needing to learn how to do this thing and kept kind of putting it off I would put it in a sprint it wouldn't get finished was like hang on a second let's figure out how to slice this down into smaller pieces so we started with a print friendly style sheet and some extra templates and then we moved to a an extra page that people were redirected to that wasn't a print friendly style sheet that was actually the style sheet that they saw so that we could test to make sure that people were going to be actually meeting those PDFs and not wanting the web-friendly version we checked the browser stats at that point we validated that we did need to move forward to a PDF server and then we move forward finally to the hardest piece which was actually generating that Docker container with the WK HTML to PDF service in place that could accept information from the website it accepts different URLs different printers so we got up to that point and then it's the sort of taper off we deleted what we had originally created in terms of those print friendly style sheets but I sliced it down into how can we expose that epic into chunks that don't seem that difficult print friendly style sheets totally straightforward to build a page that is what they're going to see in their printer totally straightforward okay no they really do need to trade PDFs we knew that all the way along the client tonight did but we you know gradually built up to we plan to replace we expose the functionality we proved that it was going to be useful and then we finally throughout the original piece so thinking about how you can schedule that information and coaching people through the the complicated pieces okay we're going to start with the old way of thinking about how to build a theme but using the new technology we're not going to worry about best practices we're just going to start writing things with twig templates okay now that we're writing to twig templates now let's start thinking about what the best practices are and we'll let's refactor what we did throw it all our old way of thinking now that we understand just the technology of how to make a twig file now let's learn best practices you know some teams may want to work with the best or start with the best practices and then you know on drill seven let's start building out components and let's start thinking about how we structure our SAS files and then all we're learning is twig when we move over to drill eight so how can you break things down and structure them in a way that allows that sort of slow build easier hard hard hard easier so in terms of the mitigation of learning curve there are I guess three things that I have seen used effectively one at these two we call it a technical review board that's pretty scary sounding it made sense for a company of 150 or 200 or whatever they're at now but you plan a document and then you have all of the across the entire company all the senior level architects come in and they help to critique if you're used to design if you ever have a design crit you put the technical plan up and you have people from other projects come in and critique that plan and you start to say what works what doesn't work based on my experience you may want to do your migration sooner you may want to leave this to the end but you have a cross functional or not cross-functional I'm sorry same job title different teams and you spend maybe two hours on that technical review I like working in a Kanban style for teams who are learning new things so that you don't have the stress of not being able to close out a sprint anything that's unfinished simply rolls over into the next unit of time and then finally I really like taking time to do weekly internal demos which are not about proving finished it's about proving problems so I again they can be very experienced programmers but when they're learning new technologies I love to have both get on a call and say this is what I currently can't solve sort of the and we tended to do them on Fridays at the end of every week there was absolutely nothing technical that was blocking the team starting Monday so they could get rolling at the very beginning of the new week now so those are the sort of three points plan and review that's my technical review board allowed fluid scheduling Kanban and share learning often so we converted what was a weekly demo into just a really great it was essentially pair programming and I know Drupal isn't really into careful programming the way some other communities are but the more and more I see how again this is I've mostly working with distributed teams but the how delays can really frustrate people and slow them down in terms of like hey well I need help I have to wait for this person to answer my question like the issue queue something that could go a lot faster is going to take a lot more time but sitting down at the same time and going through pair programming whatever you want to call it I love parent code reviews so you sit down with the original developer and the person who's doing the review and you do that together I love that synchronous experience for learning and then finally we've got the motivation piece and I in the first development team that I worked with I've been I've been a manager of my own business and a manager of learners for quite some time as a college professor as a producer of Drupal training workshops and my sort of unfortunate advantage in those situations is that the folks who showed up wanted to learn they were in you know they would show up for class or they would show up for a workshop because they were ready or because they wanted change to happen now maybe they had been told to show up but generally speaking I was going to treat people in the room as a motivated I don't learn so I took this approach in my first development team experience and this is a team who had been trying to upgrade from Drupal 6 to Drupal 7 for close to a year if they hadn't been able to set the time inside to do it they were burnt out they were stressed out and I showed up with that can-do attitude of I'm going to tell you what the tickets are and you will happily do them because you're a developer and you love developing so there were some challenges and this is the one where I showed up with a bottle of whiskey but we you know one of the things that we talked about was how in the resources there's a presentation by Joe Schindler at DrupalCon Austin on called something to the effect of how to motivate how to motivate me as a developer that the project manager is complaining about is me but I'm in the audience heckling him so it's okay but one of the things that blew my mind initially was he would tell me what he needed to work on next I would make sure that the ticket was in the sprint and assigned it to him and he would get irritated because he didn't want to be told what to do well I wasn't telling him what to do he told me what he wanted to do I will put it in the spring and assigned it to him like your idea but we made this really minor change of allowing him to choose whatever ticket he wanted to work on so he would tell me what he needed to build next I would put it into the spring and he would assign it to himself and not really really minor change maybe massive amount of difference and one of the first things that he did in a charmingly I absolutely loved Joe he was just he changed the way I thought of it project management but one of the things he did back-end developer he was like I'm gonna take front-end ticket I was like all right we've been trying to you know save you from this magical place of front-end development it's actually a little bit harder than you think I'm gonna take it I'm gonna like it and yeah he took it all right he sure learned what he'd never used sauce before if I remember correctly there was a lot of learning that happened in that first week and it's sort of he came out of it a much much stronger developer in front-end technologies and with also a little bit of like okay I see why you were picking those to get for me now but that that degree of choice and that degree of autonomy people know what they need to work on but not telling them and letting them self-assign and be like I hang over Monday I want an easy ticket today I don't want the hard stuff but just just a minor bits of choice so don't assign get choice and celebrate wins and have very very high standards but in that high standard don't necessarily make we need to build this amazingly huge thing your very high standard can also allow for rewards and creativity and by rewards and creativity I mean can you think of a cheaper way to expose this business value can you think creatively about how to duct tape the solution to get something exposed to the client so that we have the opportunity to behind the scenes plan a fuller scaffolding that we can and again this is my PDF server example you know we like we duct tape together the CSS style sheets with the plan of building out a proper interest infrastructure later on so high standards but not for huge monolithic systems or huge fully built functionality but for amazing work finally ask the developers what motivates them have the conversation in general I found that contractors or outside companies are terrified of having choice because they don't have the context to understand which ticket will give the the best win or the highest value to the company who they're working for for the client who they probably have no context or no contact with rather so in in the cases where I've had an internal development team and an outsource plus plus one or plus some so I've worked with with the Ukrainian development teams I've worked with Indian mobile app developers who were sort of like doing some add-on stuff those two out certain like those two outsource companies did not want to pick tickets no thank you they want to know exactly what is expected of them they want to know exactly what the deadline is and the more prescriptive you can be and how that ticket gets completed with what technologies and like the more you can give them the more they're like okay that's perfect thank you very much I'm gonna go do my work now exactly the way you want and it's I don't think it's a cultural thing I think it's just I don't have a horse in this race you make the decisions and I'll make it happen so that you know that don't assign good choice that's a really bad tip for some people so ask them how do you want to work how how can we make this work for you as a team and that also means if you're talking to people you can't have one system that's going to exactly work in every single team across the entire company you can have a framework you can have a set of guiding principles but you're going to need to think about this cohesive team and this is where it gets really hard it's like well that team needs help because they're currently in fire mode well how can you give that team more time instead of ripping apart this team to throw on another resource who now has to onboard which is going to take someone's time to explain what the problem is like there's and I'm like I've got seven minutes left and I don't want to get too much into like if you have a larger company and you find that that's difficult let's talk later but the the idea of teams with a framework I think is one that works well in bigger companies and it also with something that I use today the eight steps for change management there's a framework there which you can apply you can pick and choose the pieces that are of use to you but the way that you implement change isn't going to be exactly the same as the way someone else implements change because your staff or your team is going to be a little bit different or a little bit further along or a little bit further behind a little less scared a little more afraid of the change that's going to happen then someone else's team so those are my three kind of promises that I made to you in the original description ultimately change doesn't happen by magic you can't kind of close your eyes I know it's a disappointment she tells me it doesn't happen by magic it happens by management and by conscious actions and thinking about what did I do here that worked why did this not work and taking those lessons and moving them forward to the next situation and this URL has the slides already uploaded and it has some of the sort of hit points in terms of the business management things as well as the URLs most of your also I mentioned today a couple of the books we've got sort of five minutes left I'm happy to continue ranting but now you've heard all the stories maybe there's extra questions everyone's like oh sleepy too much talking yes so there's there's a few pieces in there and recently I listened to an agile weekly podcast that was talking about the pace of implementing agile methodologies in traditionally waterfalls and one of the things that I thought was really like the sort of like ah interesting was timing are you being impatient with a team who is getting there but just getting there really really really slowly compared to it's like well I know this is going to be amazing so it should just happen tomorrow so pacing is definitely one and then the other one which I learned the hard way I love to iterate and improve I also love spreadsheets and so my team doesn't necessarily love to have the rub ripped out from underneath them every single week so iterative improvement is kind of special sort of hell for people who don't you know they they don't want to have to contact switch they don't want to have to think about it so one of the lessons that I learned in the process with Joe Schindler was yes a little bit to change or good but don't change too many things too often change like talk about this is the one thing we're going to try and we're going to any the agile weekly podcast I'd like do it for two sprints do it for a month and then say is that working okay what should we keep about that part of the change and what should we throw okay now that we've tried that's the one thing that we were going to focus on practicing now let's try the next thing that we're going to focus on practicing so you've got these sort of windows where you can throw everything out and say nothing there worked we're going to try this completely different thing so as the example I was trying to make iterative improvements on the process when I was working with Joe and that that sort of constant ripping the rug out from underneath was really stressful so we figured out what the pieces were going to be and we went to a and that this is described on the drip-wise me blog and we went to a pre launch way of running the project and then after the launch of the project we all came together as a team or the product the framework upgrade we got together to team and we said how do we actually want to work now that we hit this milestone and in like you know really really positive way I fired myself from project manager because having a self-directed team was really the direction that Joe wanted to head in and so it's like okay I did the the coaching and the the sort of task mastering and all of these things to get us to launch now we're we're at that milestone we don't really need a task manager like three team of three developers you can pick your own frigging team like tickets like I don't you don't need me to do this so you don't need the gatekeeper you don't need that and it as sort of time went on yes some coaching and yes some guidance ended up being useful and Addy provides that that oversight and but it was figuring out what do we what are we trying to do you know what's the vision for this kind of work and how is the most how can we do that most effectively so that I think sort of timing increments and allow yourself to throw things out absolutely I've got two minutes left I see two questions so yes but leadership themselves are in this because they believe they're all the amount of the process where it is good so what are your thoughts on how has changed agents so step number two on this is a sample of powerful coalition and it's sort of the I'm sure that I've not made this up but I I seem to recall somewhere that's like it's referred to affectionately the cabal assemble your team and figure out how to convince the leaders that the change is going to help them specifically as individuals they are going to spend less time tracing people down they're going to get bigger bonuses I have no idea what the incentive structure is in your company but get your group convince the leaders that it's a good idea because without that leadership part it's it is virtually impossible to implement change that ends in a shift in corporate culture so you can kind of secretly do things differently but you're not you're not going to get to the corporate culture shift if you can't figure out how to change and was there there was a third it yeah yeah I was actually thinking about how do you do the reverse yeah in the sense of how do you create friction in a group that just accepts what you say and and you want actually challenge more you throw out a big change thing and everyone goes okay cool yeah I don't know what circle I would so as you were saying you can obviously so the challenging piece and how to get to challenge people I would say go back and watch Todd's talk on empowering I don't remember the exact title of it if someone has Google open if they can check it's something like empowering self-directed teams or something like that and making sure you don't have a blame culture making sure that people are okay I just want to cover my head yeah so some of the things in terms of blame culture which are interesting though so I had a I'm gonna go with time I'm sorry I'm gonna cut myself off I really want to answer all of your questions I I'm not having come up to me and kick me off stage so I think I'm just preventing you from getting coffee at this point but I don't have a schedule anyone confirm that yeah we should wrap up okay we basically just ask the assumptions that creates a conversation and out of conversation facing that conversation evidence and that's the problem yeah you know because a lot of times in friction longer conversation