 Okay, hello everyone. I think we're in a good position to start now. So for those of you who don't know who I am, I'm Abby and I'm the people operations generalist. I'm part of the people operations team and this session is on decision making and I'm going to be presenting the kind of first part and then I'll be passing it over to Barbie in the second half. So I want to start off by getting you to think about a couple of things. One of them is in preparation for when we open this up to discussion. I'm going to be talking in the abstract for a little bit. I'm going to go to the handbook first and then giving you a bit more sort of tips and guidance on how to make decisions. Then I'm going to pause and pass it over to Barbie to talk about we, Sid very kindly gave us, gave the people operations team a link to rework with Google. For those of you who might not be familiar, this is a project or an effort by Google and others to help share and push forward the practice and research of data-driven HR and they've opened up a lot of case studies and resources for lots of different topics and one of them is for new managers. So there was some content in there on decision making and I've added a few slides from that to this presentation. Some of the other points that they've shared will include in some further training and add to the handbook. Of course, some of it may or may not be relevant to GitLab but it's really good reference material for us. After that, we'll be opening it up to discussion. So going back to this think about slide, I'd like you all to think about why decisions are hard to make first of all, what's made them difficult and what steps you've gone through to make decisions and how opposing views were handled if you came across any. So that's something I'd like you to think about as we go through this and then we'll come back to this at the end. So as always, when I prepare these sessions, I go to the handbook and take a look at what we already have and I went to the leadership page and I saw that there were a few points on decision making and I kind of want to take a bit of a step back and say that I think not just managers but everyone at GitLab has the freedom to make decisions basically because there are different types of decisions and I'll put them into three kind of buckets of tactical, operational or strategic. So that kind of covers pretty much everybody I think at GitLab. And I was really looking for what, if I was a new manager and I wasn't clear on how do we go about making decisions, where would I go and what's the kind of guiding principles behind decision making. So of course I went to the handbook and I created this section here making decisions and added what we already have in the handbook and added a couple of other points. So I think the general approach to this is that we make decisions based on an informed and knowledgeable hierarchy and that's also in addition to that I've added we should be making data driven decisions. I think we all love data mainly because it helps provide powerful and useful insights that support the decision making process. In addition to that I think you can't go wrong with subject matter experts depending on whatever it is that you need to make a decision on or about and you should refer to them if you know who they are and reach out to them for their insights and input. Another point with this is that the person that does the work makes the decisions but I think you should that person will probably come to you as their manager for your advice or approval and if that is the case then you should be asking them for data what data have they gathered what are their recommendations what do they think is the best approach but the point with that is that if you are the decision maker you shouldn't really do it in isolation. So gathering data getting insights testing things out perhaps but we're not looking for consensus when it comes to voting on material decisions. So does anybody have any additional thoughts on this in the handbook so far? Silence okay good I'll go back so this is kind of like the the guiding principles of making decisions at GitLab which I think is a great start and I think as with everything we can iterate further on this and I would really appreciate your help with doing that as managers as well and people who make probably more decisions than I do in my role. So from that I went and did a little bit of research into okay well we have our the GitLab approach but what are the key points in how to make a decision? So I found a really great article and I've linked it at the bottom there which kind of listed out six tips on how to make decisions and I want to walk through some of those as I said as managers you may be asked for your approval on making the decision but someone else will probably execute it and you should be sure that you have all or as much information as possible before you're acting. So I think the first step when you're faced with making a decision is to analyse the situation. So you can ask yourself who will the decision impact and what data information or knowledge do you have or need and at this point depending on what it is your gut instincts may start to kick in you may think this seems to feel right to me if we do this we'll do that and you may have already put your mind in one direction. I don't think you should necessarily switch that off I think it can help but at the same time you should be able to back up your instincts with data and information. So the next step as I said is to look at gathering data and that could be raw data numbers things like that or information or knowledge from other people within GitLab. As I mentioned subject matter experts and we'll talk a bit deeper about how to get information like that from other people in the second part. There are two things I think you should consider with that when you're getting information from others is the credibility of that person what's their track record have they been successful in the area that you're looking to get the information from do they have any biases against a particular direction of the decision and do you think about your biases in terms of what you want to do or what decision that you need to make. Another point is it the right thing to do this was kind of interesting as I was reading the article because there are many areas where compromise yields significant benefits but your value system your character and your integrity should never be compromised and the other point which seems kind of obvious is to actually make the decision you should have a bias towards action and be willing to make the decision and you should of course make the best decision possible even if you possess an incomplete data set. I guess probably a little bit of word of caution there it depends on again who the decision is going to impact what it's going to impact have you done a cost and benefit analysis assess the risk reward ratio and if you've done all those things then you can feel confident about making the decision. The other point have a backup plan decision makers are people and people make mistakes so therefore sometimes wrong decisions will happen and the secret is to understand all plans are made up of both constants and variables and sometimes variables work against you. Any questions or thoughts on what I've talked about so far? One thing which is one of the common kind of failure modes I see here is what my dad used to call analysis paralysis meaning people they follow each one of these steps but the process doesn't kind of go on forever and go on to the point where you miss an opportunity so are there tips or tricks we can use or we can teach our managers that we work with or people that are making decisions to learn how to value time and be comfortable you know getting into that you know 70% range of certainty and pulling the trigger versus waiting too long and waiting until it's perfect. I think for me it's really about balancing out the risks of a wrong decision there's going to be times where a wrong decision is not catastrophic and you can take more risk and then there's going to be times where being wrong could be catastrophic and then you want to be more careful and deliberate and I think that it's not the same for every situation and it's really about balancing those out and being thoughtful about it but I agree with you especially in an iterative environment like we have at GitLab we should be able to make decisions fairly quickly and and then move forward or unwind if we need to unwind but you know there's some decisions we may make that there's no way to unwind and there really is no backup plan that could ensure that the catastrophe doesn't occur so hopefully those are more rare situations but where they are you should you should very tread very carefully. How do you know if you execute it 70% how do you know that you're spending 10 more percent of time or 10 more percent to get to 80% doesn't actually get you to to a point where you have to redo everything from scratch like I that's that's the part Eric you mentioned like trigger make a trigger at 70% already let's use that number like where do you understand that that 70% is actually 70% and not you know something that will make you go back and then redo everything instead if you just spent that little bit more extra time to think things through to get to 80% and then execute. I think for Barbie's right for in an iterative environment making smaller decisions is a natural defense against this and then there's some things and we have a couple of these projects ongoing right now on the engineering side one is the GCP migration one is the the geo project where we have to take a longer view than normal and it's not just a month iteration and we we have to do a little bit of kind of time management so we're doing a little bit of you know light gantt charting basically and I know that like we're not using Microsoft project we're not going to maintain this thing but just as an initial plan we're just looking at dependencies and where the timeline comes out and we're using that as a forcing function to say okay you know as Sid mentioned in the call this morning there is time pressure around geo in particular due to the the ACV and what that means is that we have an opportunity here to assume that time is fixed assume that the scope is fixed and then see what that does to the resources required to to execute it it's kind of like you know in databases like you know cap theorem it's like pick two it's sort of the same type of exercise here remodel it and and depending on what you're optimizing for something happens to the to the to the third input and then there might be other situations and maybe this is more in the sales sort of thing where when you're dealing with external customers and you're dealing with you know quarters and you're dealing with fiscal years and things like that there are triggers that those individuals have to understand like if I don't get this contract done by a certain point in time my champion in the organization is going to lose the lose the budget and that's usually not the case in engineering decisions but it's there's other types of organizations that probably have to model for those or optimize for those sort of things can I can I add to that yesterday I make some popcorn and it says on the box that you should stop stop the microwave when the time between pops is two seconds and at two seconds it's pretty arbitrary so as Eric said you should see for every decision is it like what's is it reversible is it like a one-way door or is it a two-way door now so the time is variable but the time between pops is like the time where you have a new insight so if you if you talk to people and you keep having new insights you keep learning apparently there's value and keep going if it's if you keep hearing the same things then apparently it's time to make the decision now how long the time is depends on the impact of the decision now I could talk a bit more about that it's like 10 but uh that's a criteria my use heavy or you're going to continue or what's the plan I'm sorry I'm sorry I was talking and I was muted sorry two people talking but both muted did it really happen so uh yeah we'll move on on the slides but uh I was gonna say that you guys are all right and uh not all decisions can you break up into smaller parts but when you can break them up the smaller parts and then learn at each at each milestone that's an excellent way of doing it but they will all be different they will all be some decisions can be made in five minutes and they can be good decisions other decisions take more time and and it's really about learning to trust your gut and to get the data and to ask the right questions but let's move forward a little bit into that I think abbey gave me control on these slides but um let me see here yes there we go so balancing advocacy inquiry and summary is is a little bit about what you're asking about here and so we do have some slides that talk a bit about that so when you're making decisions there's certain data points there's reasonings you need to get but you also need to often have an opinion most of the times we're making a decision to go somewhere it's almost like you've got a theorem that you're going to test and you and you want to put into place and so there's a little bit of advocacy that goes into this too so you do need to state your views clearly you need to understand what it is you want and hope to get from this decision that you're making while still being open to influence so be explicit about the reason why you want to make the decision what you hope to accomplish your concerns your conclusions your reasoning offer up the examples and the data that you do have that would lead towards this decision being made being adopted people getting buy-in it is your decision but it's a good idea to bring people along with you because in most situations we're not in this world alone and it's good to have people on our side and helping us to execute and and then you need to make your points one at a time I think often we we kind of spuel out a lot of information and it's hard for people to track and follow but again you need to be open to influence and when you're open to influence and getting data and opinions and expertise from others that brings you into inquiry and with inquiry you do need to explore others people's reasonings concerns and interests you need to encourage them to challenge you and ask you questions it is invaluable to have people challenge your assumptions and challenge your assertions because it does make you think through your reasoning think through your thoughts think through where you want to go are you correct in your assumptions are you correct in your reasonings and sometimes when you just self-reflect that really improves you to feel more solid with your reasoning and know yes this is the direction I want to go and you can feel more firm with that when you are challenged and are able to respond to those challenges in a way that is logical does make sense and it so it really does allow you to test your own understanding and it also makes those that you're working with feel like their opinions their expertise have been taken into consideration but to Abby's earlier point who is the expert and who does have the right data so you do have to be thoughtful and discriminatory about which opinions you listen to everyone's got an opinion but not everyone's an expert in a lot of things and so it's figuring out who are the who are the experts that you should go to and who should seek information from it's not to say that the rookie can't have great ideas there's a lot we can learn from rookies because sometimes they ask the best questions but do know who your rookies are and who your experts are so and then it's about balancing the advocacy the inquiry with actually summarizing and making the decision and so it's great to synthesize the views you've heard in your own words test your understanding of others concerns and capture the full meaning of the situation and then hopefully you can make a decision and not only make a decision but make a decision that others understand often when we make decisions there are controversial decisions and if those impacted by our decisions feel like we took their time to understand their situation they can get much more behind the decision even if they don't like it they can understand the reason why and that's invaluable to getting success in what you want to execute now said has also added a slide here so we can stop and ask for questions now or said do you want to go ahead and move on to your slide up to you the other any questions right now all right let's go to said so I was in an airplane and this was really at the start of my career was talking to someone in oil and gas industry I think it was a quality inspector and he says well it's simple well it's simple he had to take a lot of decisions he says oh every time I make a decision I ask myself do I make a decision of the right size at the right time based on data so the right size is like can we can we make the decision smaller can we iterate can we make it a two-way door where we make the decision but have the optionality of going back on it every time you can do that it makes it a lot easier to make the decision yeah the popcorn time goes from like days to like minutes because you can take the decision if you were wrong you'll find out and you can go back the right time when do you need to make it now on one hand a company of all split of velocity of its decisions so I try to decide really really fast for most I think of myself as like decision machine I said something but I'll come up with a decision might be right might be wrong but it's it's not it's the velocity of decisions and clarity that they give is more important than being right how should we name that I'll come up with something it's got to be a unique name we've got to agree on the name we couldn't have to have two names for the same thing is horrible like like that that would that would be the bad thing so so doesn't matter what we call it something I now think base theorem is actually a really good representation of this where you have a model and you're continually improving it with data that might be a little bit too formal and mathematical for people but I usually think of those things about Bayesian statistics yep well Eric I was barbie for edit axis you're still trying to add a slide now the second thing is the right time when do we need oh well I talked about needing to decide fast now there are one-way doors and for most of them you know it's a big decision you know it's important and there's pressure to decide now and it's surprising to me how frequently when you think about it you can delay the decision many times you have to take an action but you don't have to make the decision yet you can just keep going and gather more information and it's frequently with these big things that are urgent so important and urgent that people tend to freak out and make a decision when they shouldn't they should preserve all their options just keep going and this happens a lot in enterprise in partnerships and fundraising in many of these cases you actually don't have to decide at that time and and it gives you all kinds of optionality so where I say of small decisions people tend to take too long for them big urgent decisions people tend to decide too fast or at least people meet so so the the intuition is kind of wrong now the last part based on data very very very important you you're a leader because of the legitimacy in other people's eyes if they don't know what you base your decisions on you're going to lose that legitimacy you see arbitrary and it's hard because it takes time so I don't I'm not pretending I always do a good job of this myself but anytime you can get data that's great and it starts with like asking other people what do you think we should do doesn't really matter that answer matters less than the follow-up question why do you think that what are the other factors we should wait getting all that data on the table is is the most important thing it allows everyone to contribute it allows everyone to feel hurt that builds understanding but most important you have all the data and almost every time I talked to Andrew yesterday and I was like should we I thought we made our a fork of lip kits and go implementation shouldn't we do this or that and turns out I was wrong we were selling out directly so many times you're you have a flawed assumption somewhere and it greatly simplifies the decision-making and I wanted to put this thing in there this this graphic if we have data let's look at the data if we have our opinions let's go with mine you kind of want to avoid that situation so I probably should put a rat arrow across it anytime you can have a data-driven decision it's better and I believe most of them have data and it makes many times when we have decisions that feels that feel okay like should we invest more in solving technical depth or not many times when you get it from an abstract level to like an example level it becomes a lot clearer should we fix that thing yes or no it it makes it a lot easier to reason about it I added another slide slide 11 who should make a decision I try to say more and more I don't have an opinion and it feels kind of like a cop out but it's powerful it empowers other people I also try to say more since you accurately summarize all data I'll leave the decision up to you like we should get all the data on the table and then it's up to you to decide and there's a big benefit to having the person that does the work make the decision because they have to live with the consequences of that and it's so annoying that someone else decides something other than you want it to do and now you have to execute on that so I'm not always good at practicing what I'm preaching right now I try to become I think over time I'm becoming better at it but these are a few things that I wanted to I wanted to share I think that opens it up for discussion on that on your last point it said there about about empowering people who are doing their work to make decisions this is something I'm super passionate about and I think when I interviewed I talked to a lot of people about this like you know how do you motivate engineers and there is this really cool talk it's it's fairly well known it's based on a book by Dan pink called drive there's a youtube video by rs anime about drive and it's basically what motivates knowledge workers they did this really cool I like this because it sounds like business school jargon it's actually based on an empirical study done at MIT and they they wanted to figure this out so they took MIT undergrads and they had them turn a crank as hard as they could as a proxy for physical labor and then they had them do some leg calculus as a proxy for knowledge work and then they gave them arbitrary money rewards you know five ten twenty dollars for this stuff and they saw a linear correlation between how much money they gave people and how hard they turn the crank for physical labor so it turns out if you want more physical labor you just pay people more and strangely enough they saw an inverse relationship with monetary rewards and the knowledge work which was just puzzling and they ended the study and they said this is crazy we need to do some follow-ups and what they ended up coming up with is this model called mastery autonomy and purpose are the things that motivate knowledge work and this is why people work a job all day and then stay up all night committing to the Linux kernel for no money it's because one of these three things is sort of intrinsically motivating them and mastery is the idea that you have the chance to be the absolute best at something in the world purpose is the idea that you can connect the small individual tasks that you're doing to larger grand visions and autonomy is exactly the point that you described which is knowledge workers need to have a say in how things are being done when they're going to do them or they find it intrinsically demotivating so I always look for opportunities to create all three of those especially the autonomy piece because I have a management and they try to enable people to make those decisions and not take that away from them because you see dates slip you see poor quality work the more you tell people exactly how to do stuff so try to focus on the what and then leave the how to the to the people who have their hands in the technology obviously Eric this is very useful data for our next salary negotiation with you remember that inverse relationship so I agree with Eric I do think that most of the literature that as far as I've could see is that what people want most in a job and what keeps them motivated in a job is a sense of progress and so it's it's very important to to have progress and I think decisions frequently are pro progress like they unblock you for something and counterintuitively like reversing a decision is really bad like when when when a decision hasn't taken effect yet and I'm reversing it like like undoing work like it's horrible for a sense of progress so if you can make it smaller you can at least like make a decision go there maybe turns out what's the wrong decision you go back that's that's that's okay but if you kind of say go left and then even before you've went down the road and figured out whether it was any good you say go right that's very annoying and and the the way to reduce that is just to keep like working progress low like like what we try to do iterate make smaller decisions do smaller projects so you have to cancel fewer of them you have it's less frequently that you have to take people off something and put them on something else totally agree and and when and sometimes we have to do it and it's always a bit of a bummer but it's really important for for people in leadership positions to be to acknowledge that switching costs that the people have to pay especially engineers who love to automate stuff and then we have to throw something away so just acknowledge that hey we made a decision we're reversing it I acknowledge that that's on me I'm asked me to come with me as we make this turn and and make sure people feel that the decision wasn't arbitrary or they weren't weren't included because it can be totally demotivating yeah I think with any decision you make explain to your stakeholders and those impacted the why and the context around it is always super important whether it's making a decision or unwinding a decision the why is always critical okay I'd like to open it up and find out about some really examples of perhaps difficult decisions that some of you have had to make so I'll pass it over to yeah Barbie I'll ask you and perhaps you can give us an example well gosh there's so many of them so I think probably um the most one of the most recent ones was joining GitLab I had a successful consulting career and I needed to make the decision on whether or not I will join GitLab or not and I really did go through the um the deliberations of the facts versus the emotions and and lining up numbers and then the emotions of what do I think I would enjoy most and I think that I just had to really deliberate amongst those and then ask those around me who know me and know what drives me and knows know what makes me happy as well as looking all the data and then it was the decision to join and it was one of those decisions that isn't um possible to be catastrophic there was no necessarily wrong or right one in terms of of leading to some huge failure but uh so it made it a little bit I guess easier to make but um I didn't really have any opposing views everyone that I spoke to was very very supportive and agreed with my passion and my energy around joining so I didn't really have to um explain myself as much as I would in a more controversial decision I think it was it was widely understood by everyone knows me that of course I'd want to do this so from that perspective I didn't have to go there unfortunately though I do have Comcast here who's going to disconnect my internet now they won't be up for about another 20 minutes so I am gonna have to thank you thanks bye bye okay um I'd like to hear from somebody else what about you Sarah can you talk about an example of a difficult decision and specifically I would be interested to know how you handled opposing views you would do this to me today Abby uh as you can imagine in UX there's a lot of times there are opposing views and unfortunately we don't always have the the data to back it up right I mean we're working on getting more of that data and and being able to back those things up but a lot of times it is really more of getting a full view of the problem hearing all sides in terms of what the proposed solution is and then really just doing your best to move it forward so I also find that a lot of times on UX issues they um there tends to be a lot more discussion because there is a lot of opinion um and not necessarily opinion based on on any type of data really just more about well I think this and I think that so as much as I can I try to cut to the meat of the issue so what is the problem we're trying to solve what are the proposed solutions what data do we have if we have any and then how can we take a step forward as quickly as possible and and and then collect data to say yes this was the right decision or no this was the wrong decision so I don't necessarily have a specific example in mind but um that's what I try to do anytime I enter into these these issues in these conversations um and I think where it becomes difficult for me sometimes is when I state a decision this is the decision we've made on this issue this is what we're going to do going forward make it UX ready and then a lot of times what happens is other people will come in oh well I didn't know about this issue I have this opinion wait wait wait and then you kind of get pulled back sucked back into that that decision but something Sid said really resonated with me in terms of of how we handle user research when you get to the point where everyone is saying kind of the same thing it's time to move on like you're not gaining anything from continuing to have that conversation you need to take what you've learned from that conversation implement it and then start a new conversation um and that's what we do with user research and testing once everyone is kind of giving us the same feedback we know where we're at what we need to do and then we can move from there so I'm sorry if that was a little rambling I just you call me by surprise Abby um yeah I love that Sarah and I think what you're referring to as data is what I would call hard data um for I think it's really commendable that we're doing so much user research and like new project page with like per second timings now of what is faster that's amazing that's hard data most of the decisions I make are based on soft data so I can't opinions as like soft data at least we got the opinion of someone it's not just my own so so my data my data that I refer to is like frequently just gathering all the opinions of the people in the room instead of instead of having having an excel model or something like that um so um take that gathering data in that vein and I think if you have all the opinions it's it should be the person who's most both most expert in the subject matter and the person executing on it hopefully the same person making making a call so when I say make a decision based on data I don't mean have an excel sheet for every decision I just mean get all the opinions of the people that could be could be helpful um but yeah obviously if you can get harder data it makes the decision a lot easier yeah yeah but I agreed yeah and that's what I meant really was um you know there's there's that hard data which is hard to always have ready and available and then we're working on but a lot of times it is really just getting opinions and in different perspectives and point of view because to me that is data you know your experience and what your day-to-day flow is and how that affects you that's data I don't have because I don't have that slow in that experience so trying to have that empathy exactly okay I'm not going to pick on anyone but would anybody want to um share anything else I can see you all sitting there nervously looking at me yeah I will share a classic engineering problem where you need to make a decision in my opinion and I had it a couple of times in the past so you are tackling a technical problem and especially more junior engineers tend to do like let's rewrite everything let's redefine the wheel and start completely informed scratch because we just took a very small wrong turn um and I think it's also most of the time about doing pragmatic choices uh that the hardest time I had in the past to to do actual hard decisions was when you had basically two types of opinions but your personal opinion and your personal experience was something different of these two opinions so basically one one group said yeah let's redo everything the other group said yeah let's uh use uh redo it but with a completely different library and you were like yeah let's take a step-by-step approach so these are the actually really hard decisions for me but I totally reason that that's one of the biggest things that why I joined Github and left my old job is that there were so many decisions made by simple people who were just reading something and were never close to the topic and and and having the person that actually on a daily basis is there and next to the topic is the most valuable data soft data as you said that you can get and most of the time they can make the best decision but you simply need to to do this uh long term goal also taking a look at at longer term goals because they are like totally in their topic at the moment and these are also different things I I tend to take into my decision making so maybe I I could say a few words uh because I we all have these engineering challenges that team mentioned and like something that we are often having problem is with like the evolving requirements requirements that we think that they are uh clear in the beginning but they basically change and like with our vision we we maybe know what is the end goal but we may not know the steps to get to this end goal and something that I've been seeing and I've been part in number of times is like the conflicting opinions how we should do things and like people having their vision about how like some parts should be implemented how they should look architecturally what we should maybe prepare or like maybe sometimes even over engineer and something that that kind of very often not really like very often very often is the point point something that I kind of learned is like that for me the best way on like making and concluding what you want to do next is like making sure that we lay out all possible options make sure that we discuss the implications of all possible options and try to find a solution that would everyone would be comfortable with uh it's like I'm trying to find a solution that people are fine with implementing rather than being forced to implement because of like my vision of how they're done but this is also not always kind of possible because some people just basically back off at some point but this decision still has to be made uh so we always think about not only how to implement something but also what are the consequences if what we make as the decision is basically turn us wrong and what is our backup plan and it's so far it turns out that we made a few bad decisions but just because we kind of anticipated that this decision may be wrong we also were able to later correct that uh but just because we were correct uh collaboratively on figuring out the best solution that everyone is comfortable with it did help in like making everyone on the same page the one thing I just wanted to add is that whether or not you make the right decision or the wrong decision or whatever decision you're coming to um people really really enjoy being part of the conversation and I think when when you're in a group and the decision has been made that didn't involve you I think people really um want to be part of the decision and they're more likely to be on your side if they were part of the conversation there's that I think it's called the Ben Franklin effect which is like if someone does a favor for you they're more likely to do another favor for you in the future I think that's how it goes something like that but people just want to be involved and people want to feel that they are important and uh those types of things so that's what I try when I'm making decisions I try and make sure that as many people are involved as possible so that when the decision has been made someone's not like hey I didn't even know we were making that decision I think people take that more personally than uh them than we know yeah Jacob I I hope that what we can do is create a culture where we debate passionately and we hear everybody out and we listen to people's opinions but then we can also commit because there's always going to be a quote-unquote loser someone whose decision wasn't the chosen option not that I like the label loser um and we we need to train everybody to be comfortable the idea that okay I said my piece I was heard other people heard me um but then I'm comfortable moving forward because time is of the essence and again as long as we're making smaller decisions those people should be comfortable that okay if if uh if I'm right and we've made the wrong decision we're gonna find out as quickly as possible and it'll be obvious to everybody and we can course correct um in the interest of of time um I I think that's that's super important yeah and I think and one of our the things listed on our values page is disagree and commit and maybe we can go to the previous slide um I think the last sentence there it's really important to make people hurt so everyone can chime in but make them feel hurt and do that by restating their position better than they did themselves so formally don't don't attack a straw man don't take the weakest part of their argument and start arguing with that instead give give the strongest possible case they made and and and even even make it stronger and then disagree with that and and in quote reviews we say you are not your work you are not your code and also you're not your decision so by advocating a certain decision you should be able to untie that from from your from a personal attack it's not attacking your decision you're not a loser you're the point you advocated for lost you didn't lose um and that's that's a completely different thing do other things I want you to add which are just above that managing up one of the decision needs to be taken if your manager is involved give them options and trade-offs don't just say look I recommend this no say look I recommend this because XYC if we do this it will be better in this way and worse in that way and then managing down give data and insights we had a infrastructure meeting this morning and there was there was a conversation about our geo cluster where they're a geo test bad to add one file server or multiple ones and I thought that the trade-off that was done was strange but I I reckon I realized look I haven't given them all the data so I said look we're our customers need geo to be generally available this bad and and that's why that's why we probably should improve the test that a bit faster and I realized like oops that's information I haven't given the rest of the company so I went on the team call and told everyone like look this is this is a very important thing we can do to help with sales um many times people are missing part of the picture that higher in your higher up you have so it's your role to to give that information not not to take the decision but to give them the information they would come to the same conclusion themselves so give them the data okay we have two minutes left for anything else any questions anybody has anything else that they want to say I don't see the recording button on uh abby uh it's on my I see it on yeah it's it is on yeah glad to hear that thanks you scared me oh that'll be great all of this good stuff and it's not recorded um yeah anything else from anybody before we wrap this up