Make Great Decisions Quickly, the Unscary Way w/ Alamelu Radhakrishnan #144

Here's the truth. Hiring remote engineers doesn't have to be expensive and time-consuming. Our friends at Revelo can help you find and hire top engineers based in Latin America in a matter of days. Just tell them what skills and experience you're looking for. They'll come through their network of over 400,000 pre-vetted engineers and give you a short list of curated candidates that meet your specific hiring requirements. You interview

and hire on your terms and only pay for as long as you keep the engineer. To learn more, visit revelo.com forward slash ELC today and save $2,500 off your first hire. Any decision you make is better than not making a decision because most of the decisions that we make in our job are reversible decisions, but the time that we lose by not making a decision is irreversible. The opportunity cost of that time you're never going to get that back.

Welcome back to the Engineering Leadership Podcast. ELC Annual 2023 is just around the corner. This is actually the last episode of a special series that features some of our past sessions that captures some of the themes and topics that you'll see during the conference. Why? Because you're probably wondering what can I expect from the conference? Well, if this is your first time listening to this series, or if you've been with us through

the whole journey, then the answer really is incredible speakers and content. And this episode is just a little bit of a preview. Speaking sessions will tackle some of the most critical challenges facing engineering leaders today. We're talking career development. How generative AI is impacting software development and leadership. Today's theme though is about leadership and decision making. So if you haven't gotten your ticket yet, you're

missing out. I'm telling you right now, you absolutely need to be there. You only have a couple weeks left. So you need to grab your ticket. There are only a few tickets left. And I'm telling you, you will miss out if you're not there. You can grab your ticket and check out all of our speakers and topics at sfelc.com forward slash annual 2023. See, introduce today's episode, all a me Lou, Rhara, Christianin reveals her best frameworks

for making great decisions quickly without fear. She covers her approach to knowing when to make a decision pitfalls and anti patterns to avoid throughout the decision making process and strategies for delegating and avoiding decision fatigue all while working around her fear failure and empowering other decision makers to act with confidence. Plus, she shares some interesting decision making concepts, including first principles, the 40% to 70%

guide and more. Let me introduce you to all the me Lou. All the me Lou is excited to start her next chapter with home base as VP of engineering, leading product delivery, and they helped small and medium businesses maximize their potential. Previously, she was chief of staff to the CTO at Shopify, supporting the engineering organization and leading the teams responsible for building the systems, technology and technical programs that power

Shopify. Prior to Shopify, all of me Lou has worked with some of Ken does most innovative product and consulting agencies, leading software delivery teams and helping organizations leverage technology across a variety of industries. Again, if you're interested in topics just like this and beyond, you can get your ticket to join your peers, check out all of our other speakers and explore additional topics at sfLC.com forward slash annual 2023. You will not regret

getting a ticket and being there and showing up. It is such a special experience. And seriously, you don't want to miss out. Enjoy this special episode with all of me Lou, Rada Krishnan. Hello, hi. I'm so excited to be here today. I'm all a me Lou and I'm really excited to talk to all of you about decision making. As leaders, we make hundreds of decisions a day, big and small. And it is a core part of our roles. I've worked with a lot of leaders who

are very intuitive decision makers and they make decisions. They make quick gut based decisions with their depths of experience and their skills. And then I've also worked with leaders who are very structured decision makers who use extensive frameworks to make their decisions. I myself am a very naturally instinctive decision maker. But as I grew in my career, I realized that this was an approach that didn't scale and it didn't allow me to scale as a leader.

And so I started to build a decision making framework first by reverse engineering the intuitive decisions that I had made and then evolving and iterating on my decision making approach. So I'm excited to talk to all of you today about how I make decisions, some components of a good framework, when to make a decision, some of the traps and pitfalls in decision making, how to make your decision stick and how to effectively delegate your decisions.

So I'll start with a question that's so obvious that it might seem facetious. Why should we make decisions? Decision making, if I boil down my job to its absolute essential pieces, that is the only thing I do that is the most important part of any leader's job. So why do it? Because clear and timely, clear and timely decision making is the best gift that a leader can give their team. I see so many teams that are slow or struggling because they don't have

clarity from their leaders on decisions on vision. And so giving that to your team is an incredible gift. And I will also say that in almost every case, any decision you make is better than not making a decision because most of the decisions that we make in our job are reversible decisions. But the time that we lose by not making a decision is irreversible. The opportunity cost of that time you're never going to get that back. So in most cases, make the decision and it will be

better than not making a decision. I worked with this product development team a while back and we were working on an internal product that had thousands of daily active users, but it was internal to the company I was working for. So the stakes were not as high. And so we decided to do away with a lot of product management practices. We stopped doing experimentation. We stopped looking at our data before making decisions. And we defaulted to a mode we called YOLO shipping. And we

just came up with ideas and we just shipped them. And once they were in production, we saw how users reacted. We looked at the data then we looked at the metrics then. And then we decided, was that a good decision shipping that thing or did we make a mistake? And there were cases in which we made mistakes and we roll that thing back and you know, we wasted a bunch of time.

But in most cases, we had done the right thing by shipping it. And overall, even though we wasted some time, we found that it was net positive and a net accelerant to the team to just be YOLO shipping all the time. I'm not recommending that you change your product management philosophy to YOLO shipping. I think that there are a lot of good, better ways to approach this. But it is a very small but meaningful example of how fast decision making can unblock people and can give you a lot

of impact quickly. And lastly, I'll say that decision making is hard. It can be exhausting. It can be scary. And that's the time when you lean into it. When you lean into decision making, when you build the skill, when you build that muscle, you can really be a force multiplier for yourself and for your teams. I also want to talk about when is a good time to make the decision. For me, there's a sort of golden zone of decision making, which is when you know enough,

but not too much. Colin Powell talked about this 4070 rule of decision making that you should make a decision when you know between 40% and 70% of the information that you need. When you know less than 40%, you're really shooting from the hip. And when you know more than 70%, you've waited too long to make the decision and you have sort of lost that opportunity moment to seize. And so for me, when I think about that golden zone, it is a threefold approach that I take. I think about gathering

context. So that's gathering context from my stakeholders, from the people around me, from the experts, as well as from the data that I have access to. I like to think about my forcing functions. What are dependencies that I should be aware of? Dependencies that I have versus people have on me and what are other consequences and timelines that I need to be aware of. And lastly, I think about what do I actually need to decide? We don't have to decide everything. Sometimes you can make

part of the decision, learn from it, and then make the rest of the decision. And so how can I make a decision that unblocks the people working with me, but still leaves all of us optionality moving forward? So now that you've decided when to decide, how should you make a great decision? There are so many great decision making frameworks out there. And I think different frameworks work for different people. And they're also very contextual. So different frameworks work in different

contexts. I will share with you a few key components of mine, which is a fairly simple and easy to use framework. So I like to start first with desired state. So I like to start by thinking what does success look like? If I make a great decision today, what will be true in the future because of it? And then I also like to think about my metrics and my tripwires. If that's what success looks like, how will I know when I see it? Not only does this allow you to make a great decision today,

it also sets the foundation for your feedback loop. So you can see in the future, did I make a great decision or was I wrong or has the context changed? And so my decision isn't valid anymore. The other thing I want to talk about is first principles. If your desired state is your destination, you can think of your first principles as your map. So your first principle should show you a number of paths to get to your destination. It may be able to surface to you what the best

path to get there is. And it may also establish guardrails for where you want to drive and where you don't want to drive. For those of you who aren't familiar with first principles, they can be described as essentially the most essential aspects of your problem and your solution. So your first principles are the thing that hold true as long as you are in the current context. They are what you build alignment on and they also form the building blocks of your solution. When you solve from first

principles, you can really get to the most creative solution possible. The opposite of that is solving by analogy or reasoning by analogy. And what happens when we do that is we are taking the paths that has already been taken. We are solving the problem the way everybody else has solved the problem. And as a result, we end up in orthodoxy or we end up in situations where we do things the way they've always been done before instead of finding a new and creative solution. That's why I

love first principles. And I think they're far more very essential component of any any problem that you're approaching. And lastly, it's really important to know your priorities. You may have in most cases, you will have a desired state that has multiple components or you may have first principles that contradict with each other in certain situations. And when that happens, it's really important to know what is the most important thing? What is my number one priority?

One of the things that we do at Shopify is really, really obsess about the merchant. And so whenever we are in a situation where it's not clear what number one priority is, it's always the merchant impact. It's always the merchant value. And that is more important than anything else on in front of us. Another really good example is decision making during catastrophic incidents. Something that I don't wish upon any of you, but something that you all have been in or will

be in at some point in your career. And so when you're in a catastrophic incident, when you're the incident manager or you're the leader there, you're in this high speed, high stakes, high pressure situation. And it's really hard to make decisions, but it's also the most important time to make quick decisions. And your decisions have really big consequences. And so at a time like that, it's really helpful to know what is the most important thing and the next and the next.

Is it more more important to prevent data corruption or data loss or data leaks? Is it more important to keep your platform up? Are there multiple aspects of your platform, which one will you preserve before another? If you have a list of priorities or axioms that allow that tell you that, you can really speed up decision making and you can apply this to any complex decision making scenario. So if your first principles and your priorities and your desired

state are your map, what are the pickfalls on the way to getting to where you're going? A lot of the things that I talked about might have seemed, it might have resonated with you or you might have thought, oh, I do this without thinking already. But there are also anti patterns that we do without thinking in decision making. And there are sort of unintended behaviors that we all have. And so I'm hoping that by shining a light on some of the most common ones that I see, I can help you

avoid them. The first one that I want to talk about is consensus. This may feel like a controversial opinion, but I think building consensus is really bad and it really dilutes good decision making because instead of targeting your desired state, your targeting consensus, I have been in so many situations where other people are I myself and just trying to find the best middle ground between two opposing viewpoints. And when I do that, my decision is the middle ground. It's not pushing

any boundaries. It's not moving us forward. So how can we not worry about consensus and how can we be bolder decision makers? The other one I want to talk about is sunk cost fallacy. I think this is a natural human tendency because none of us want to waste time and waste resources and we're afraid of doing that. But I encourage all of you to be fearless and to not think about sunk cost.

I was working on a project recently where we were building the small component, took about a day to build and we ran into a problem and we decided to throw it away and build it again instead of trying to fix the problem. And then we did that three times before we finally got something we were happy with. And it might seem wasteful to approach it that way and I guess it was a little

bit. But what we found is that every time we did that, not only did we solve the problem, we also made the entire component better in a number of different ways because each time we did that, we were rebuilding from first principles instead of just iterating on current state. And obviously it's not practical to do this in every situation. But again, it's a great example of what happens if you can stop worrying about the costs that are behind you and look to the future. You can make bolder

and better decisions and you can reach a more creative outcome often faster. The third one is false dichotomies. This is a really simple but really impactful one. I get so many messages from people from someone working, I'm working with who says, Hi, can you please help me decide this?

I'm torn between A and B. And the most helpful thing I do for them in that situation is talk through it and then offer them options C, you know, to show them that it's not just A and B. And breaking that binary thinking is so powerful because what ends up happening in most of these situations is they don't pick A or B. They don't pick C either. They pick an option that neither of us could have

conceived of because they are not stuck in that binary mental model anymore. So every time you're making a decision where you're choosing between two options, I guarantee that you don't have two options. You have more than two options. And lastly, I want to talk a little bit about escalations. Escalations can be a dirty word in business. We don't want to escalate things, but actually escalations can be really powerful when you're working with a partner and you can't come to a

decision together. And one of you is not a clear decision maker. Instead of trying to compromise or come to consensus, it's better to escalate and get context quickly. Do your escalations respectfully, do them cleanly and not only will this lead to better decision making, it also has a lot of other benefits like better transparency, better relationships, and better context sharing for a lot of people around. Once you've made the decision, we have to try and make that decision successful.

And in order to do that, we have to make that decision stick. There are a few ways that I approach this. So I said consensus is bad and I stand by that consensus sucks, but alignment is really important. It's really important to get buy-in from the people who are often the ones executing your decision and who are usually the ones who have to live with the consequences of your decision. One really important way or one really effective way to get people to disagree and commit is to

model this behavior yourself. Show people that you can disagree and commit, not just when it's your boss or when it's someone senior to you or your peer, but also when it's someone who reports to you, someone on your team who comes to you with an idea that you don't agree with, how can you disagree and commit and how can you model this behavior for them? And one of the ways when I'm struggling with disagreeing and committing or when I'm struggling to get someone to disagree and

commit, something that really helps is the framing of an experiment. So let's just try it for X weeks and let's come back and revisit the decision. And usually I find that that gets people on board and also helps me get on board if I'm not ready to commit to it fully. The other thing that's

really helpful here is storytelling. How can you bring people along for the ride? How can you paint a picture for them that shows them the full context, the assumptions that you had, the stakeholders that you work with, the risks that you were concerned about, the whole journey of your decision making and what you're trying to achieve. Storytelling is a really powerful tool and it can really help you galvanize your organization into change. Speaking of change, I want to

talk a little bit about change management. I know it conjures up visions of slow bureaucratic teams that are making your decisions take longer and longer to execute. And I think that that version of change management exists because that is an approach that is rooted in fear of change. But there is also a really effective version of change management that is rooted in embracing change while acknowledging the difficulty of change. For me, this is a really fine balance between

fragility and resiliency. How can you create space for your team to express that change is really difficult, that they are having a hard time processing it and give them the tools to navigate that while at the same time enabling them to move from a negative or destructive mindset into a really constructive forward looking mindset. And if you can hold that duality for your team, you can allow them to navigate the change while also embracing the change and thriving upon it.

And then lastly, monitoring. We talked earlier about desired state and success metrics. It's really important to measure these, to have trip wires for these and to understand, is my decision still taking me to my desired state? And if not, will I know? Because we're not always going to make the right decision and the sooner we know we're wrong, the quicker we can react to it. And in some cases with really consequential decisions, you might also want to have contingency plans. What will I do

when I realize that my decision was wrong? And how can I quickly respond to it and pivot? I'm getting a little bit of fatigue saying the word decision over and over again. But on a more serious note, decision fatigue is real. And this is what I look like at the end of each day. I make that face. That's what my Slack icon looks like. I have this mountain of DMs that I

don't want to look at. And every DM is someone asking me to make a decision on something. And I find that I sometimes get into a pattern where I will open a DM, read it, market unread, open it again, 20 minutes later, read it, market unread. I just can't deal with it. And so when that happens, I try to recognize it and step away and take some time to reset and recharge and come back to it in a better state of mind. And you should all do that. But more importantly, you should not make

the decisions that you don't need to make. If someone else can and should make this decision, then you should give it away to them. And so I think the most valuable thing, if you take anything away from this talk is delegate your decision making. This is easier said than done. It's really hard to actually give away decision making power. But here are a few things that have helped me.

So number one, delegate the problem, not the solution. It's very easy to slack someone to call someone and say, Hey, can you please do this and tell them exactly what to do? But how can we stop ourselves from being prescriptive? How can you give someone the entire problem space and say, can you solve this as opposed to saying, can you do this? And that's going to look

different at different levels of your career. The way that an engineering manager delegates to a senior engineer is going to look really different from the way of VP delegates to a director. But in all of these cases, you should still be delegating the problem space as opposed to delegating just the solution. And then calling back to your desired state and principles, give those to your team as well. So what you can do is you can give them the problem space,

you give them the desired state. Here's where we want to get and here's what success looks like. And then you give them your first principles. So those form, you know, the essential aspects of what we want to achieve as well as the guardrails for where we don't want to go. And when you've given them all of this, you have effectively established what I would call a zone of success. And then

within that zone of success, they can make any decision that they want to make. And I'm certain that they will make a better decision than you because they have more time and more context, and they can steep themselves in that problem more than you can. And when they come up against the boundaries of that zone of success, that's when they can come to you and you can collaborate on

the decision with them and you can help them navigate those boundaries. And when you work in this way, you're giving your teams a lot of autonomy while also creating more time for yourself and more space for yourself to focus on the problems that you need to solve. Speaking of autonomy, autonomy is also in my mind the key to accountability. So accountability, I've often seen it used as a tool for blame, who's fault is this, but I actually think accountability when it's used correctly is

a tool for freedom. How can you give your teams the right amount of autonomy to fully solve this problem so they can be fully accountable for the solution? And then lastly creating a safe space, people are going to make the wrong decisions, you're going to make the wrong decisions, how can you make it okay to fail? There are a lot of ways to do this. I really like focusing on learning. So acknowledge successes, acknowledge failures, but the thing to really celebrate is learning.

What did you learn from this success? What did you learn from this failure? Something I say is the only failure that matters is a failure to learn. And so by centering learning in that way, you can really

allow people to move away from the fear of failure. So I talked a lot about how to create a good decision-making framework, the components of mine, what to watch out for, how to delegate it effectively, a lot of this might feel really heavy and it probably is for a lot of your day-to-day decisions. You don't need to go through all of this to make all of the decisions that you make every day.

However, when you start to apply this to big decisions and you start to do it in a systematic way, it also makes your intuitive decision-making better because you've built this muscle and so your intuitive decisions become faster and more effective as well. And lastly, I'll say that there is no one-size-fits-all approach to decision-making. The way that I approach decision-making is really based on my personal leadership style, it's based on my values, my strengths and weaknesses,

and then it's also contextualized to my environment. It works where I work, it works for my company culture, it works for my value, for the company values, and it works for how people work with each other. All of these components may not be true for you, but some will and you can build others that make more sense for you. And so I encourage you to build your own decision-making framework because intuitive decision-making doesn't allow you to scale as a leader.

So thank you so much for taking the time to listen to me today, I really enjoyed talking about this and I'm really looking forward to hearing some of your questions, but also your insights. We have a lot of great leaders here, so I'd love to hear what works for you and share some of your decision-making secrets with the group. Thank you. As a U.S. company, hiring remote engineers can be time-consuming, expensive, and frustrating.

You could hire freelancers, but you don't know how much they'll focus on your business. Outsourcing to dev shops, risks, control over who works on your projects, and expensive long-term contracts. Or you could look overseas, but working across lots of time zones can really slow things down. Enter Revello, your gateway to a talent network of over 400,000 pre-vetted engineers in Latin America who are proficient in English, work in your time zone, and are dedicated exclusively to

your business. Revello simplifies the hiring process, enables quick payroll in local currencies, and provides expert staffing support. There are no big up front contracts you only pay for each month that you decide to keep your developers employed. With Revello, you're in complete control, you get to decide who to hire, what to offer, and you get to decide how long to keep them on your team. To learn more, visit revello.com forward slash ELC today and save $2,500 off your first hire.

All right, my name is Strong. I'm a director of engineering from Affirm. My question is about the organizational aspect of the decision making. What kind of artifacts process that you use in your day to day, like to decide to go through, for example, do you have a proposal document, do you have a meeting, do you have follow-up meetings, how many meetings do you have, you will keep having questions, do you just like, at some point it's just cutting off, and do you have a

memo about what is decided and how do you circulate that? Can you speak to that aspect? That's a huge question. That's basically everything, but I will try and answer some parts of it.

So the way that we approach decision making and to be fair, I don't think any organization at the company level does this really well because it's really hard, but some of the things that work is making it very clear who the decision owner is so that you know after you've had all the discussion and conversation, who is actually making this decision and who is accountable to make this decision. So establishing that owner early is really helpful. I find also in conversations,

it's helpful to frame what kind of conversation are we having? Are we brainstorming? Is this a decision-making conversation? Do we expect to come out of this meeting with a decision or do we expect to come out of it with more ideas? Or will I be making the decision on my own? Thank you for your input, but no, thank you. Whatever that approach might be, it's really helpful to establish that

as you go into the conversation. I've worked with some people who have really effective decision log formats where they talk about what they're trying to decide, what they're trying to achieve, all the alternatives they consider, the final decision they made, and the risks and contingencies of that decision. And so when you are making big decisions and then you're communicating those

decisions to stakeholders above you, it's really helpful to share that decision log. When I get a decision log like that, it's very unlikely that I'm going to challenge that decision because I can see that they've thought through most of it better than I have or better than I can. So that's another thing that I find really helpful as well. And then communicating it, I think really comes down to what are you trying to accomplish in a lot of cases when you're communicating the decision,

you're communicating the decision, you've already made it. And so then it becomes about narrative building. What's the story you're telling and how do you want it to land and what do you want people to do with it? As opposed to just sharing the decision and leaving it sort of open for decision feedback, because in some cases you're not going to change your mind. I like to always leave

room for feedback because I think there's always space for it. But I also like to set the expectation that this feedback will not change my decision right now, but it might change my approach in the future. Hi, from the back, you talked about yourself as an instinctive decision maker and the framework kind of coming down from trying to decode that process. Have you ever come across a situation where despite those two technically being derived from the same source, they disagree

with each other? So the framework outputs a decision that's different from your gut feel. Yes, absolutely. That happens. And I think for me, there are two cases where that happens. Sometimes what happens is my gut instinct is different from the decision I'm trying to make intellectually. And that's because I am sensing something instinctively that I don't have

language for yet. I don't know what I'm sensing, but it's something and it's a signal. Maybe I'm reading the body language of someone in a room and I can tell that they don't agree with me and that's bothering me because they're, buy in is important. But I haven't realized that's what it is. And so my gut is saying it's the wrong decision. And so when that happens, I like to step back and think about, what am I feeling? What am I reading that I don't have language for? Why is my gut

telling me something different? The other time that happens is when I'm afraid. And so I'm scared of something going wrong. I don't like the intellectual decision that I need to make. I don't want to do it. It's unpleasant. And when that happens and I step back and I think about it, I realize that it's an emotional response and that I just need to navigate through the discomfort instead of trying to make the decision. That's just the easier path. And sometimes I don't know which one it is.

Sometimes I'm just wrong. Thank you. That's a great talk. So one insight that I have seen work is when you use a recie chart. This is in making it easier, but it's very hard to use it because most of the time we're in the go. And then I have a question. Could you elaborate a little more on the first principle? I'm not familiar with it. So maybe some concrete examples. So that's a big component of it. Absolutely. So first principles, like I said, they're the most essential aspect of

your problem and your solution. And so an example might be we are trying to make our platform faster. So a first principle might be sometimes this will also sound like an intended outcome, but a first principle might be I want my time to first bite to be under such and such. And that has to be true for this to be considered successful. But an implementation detail might be do it this way or you know, make sure that you have your infrastructure distributed in a certain way.

And so be focusing on the principle instead of focusing on the implementation detail or the solution will really help sort of expand the space of where you can where you can solution. That was a great example off the top of my head, but really whenever you're trying to establish your first principles, think back to is this a principle or is this an aspect of the solution that I'm trying to get to? And if it still feels like an aspect of the solution abstracted up

another level so that it can feel like a principle instead. Hey, thanks, Felix, great talk. My name is Nick and you mentioned the importance of delegation earlier and I was curious, do you have like a framework or an intuitive approach for deciding cases where you're not delegating enough or if something is going wrong there? I think that that is still an area of personal growth for me. I find that sometimes I realize I'm not delegating enough when I've run

out of time and then I step back and I think why don't I have time? It's because I'm doing too much and I'm not leveraging my team enough. But when that happens, I try to delegate at the highest level possible. So instead of delegating the project, let me just delegate that whole product to you. Let me just delegate this portfolio. Let me just delegate this whole problem space. So that's one part of it is like having a better system for determining when you're not

delegating enough. Mine is just I'm overwhelmed. I don't have time. I haven't delegated. Actually, another signal is I have someone on my team who's underutilized and I can tell like as their leader that they're not challenged enough, it's probably because I haven't given them the problems that would actually challenge them and I've kept those problems to myself. So that's

the other one. And then I think it also comes down to like delegating the right thing to the right person and that really goes into like how do you understand the strengths of your team and what inspires them and challenges them and gets them really excited and that also helps with effective delegation. You talked about reading body language, you know, getting like a gut feeling of like where the audience is headed. How have you adapted to the remote world where you we just see people's

headshots or just a blank thumbnail on Google Hangout? Yeah, it's a great question when we first started working remotely. I really felt like all my superpowers were taken away. Like I really loved working with people in person and when I couldn't have that, everything felt flat and it

was a really, really difficult adjustment and one that I'm still making. Some of the things that helped me is starting to build personal connections with people and sometimes that looks like just having a one-on-one with someone who you typically wouldn't have a one-on-one with but you have like group meetings with. But it's also little things like sending little gifts on Slack to sort of you know, nudge where they see how they're feeling and judge where they are and build like

a little bit of a rapport. And as you do that and you form more and more of a fuller picture of that person in your mind, then you can see how they're reacting to things and you can you don't have body language but I think you have other signals like you have micro expressions facially.

But I also feel like I can get a lot of signals from how people type on like type messages to you, how they're using punctuation, how like the kind the way they phrase things if it's suddenly different from how they usually talk, you can tell that something is up and then when that's the case, you can address it directly or you can try and you know, assess out what's going on.

Hi, thanks for the talk. My name is Niels and my question is how do you delegate a lot of decisions without becoming perceived as like a indecisive leader or someone who's not you know engaged in whatever's happening, you're just letting other people make decisions for you, even maybe to the point where the team is like why is she asking us to make that decision? Yeah, that's that's a great question. I think that you can delegate without becoming disengaged and it's a balance of how can

you remain very collaborative with the team without being the owner of the decision? And as the leader, you're always ultimately accountable. So there's no escaping that accountability for me. And that's also another reason to remain engaged because if it is wrong, like I'm not going to call out my team, I'm going to take responsibility for that. But being engaged and collaborative while

allowing the person to finally make to make the final decision really helps. And if you do it slowly, then over time you realize that you have less and less need to collaborate as closely because they

are really running with the thing and you don't need to be as close to it. Also, I think when people are asking why are you making me make this decision, either you're delegating to the wrong person, like they're not ready for that, or again, and they're coming from a place of fear, they're not ready to make that they are able to make that decision, but they're not emotionally ready to make it.

And then in that case, it's a question of coaching them. But generally for the way I lead in my team, it really is about giving people a lot of space and giving them a lot of responsibility. And so someone who sees that as negative is not going to thrive with my leadership stuff. Hi, so 30 to 70% is a nice guide, but I'm wondering if you could talk more about when you know it's time to make the decision. Yeah, absolutely. Yeah, 40 to 70 is like, how do you know you have 40 to

70% of the information? Because how do you know what 100% looks like? You don't, right? I think for me, like it really is the things I talked about, like getting enough context, understanding what my forcing functions are, and then understanding how much do I need to decide? And so in practice, that doesn't actually, like I don't ever know if I'm between that 40 to 70 zone. I just know that I have done as much as I can to make this decision. And if I wait any longer, then I'm waiting too long.

So it's not a perfect answer. So I have a question. Can we quickly touch base? Hi, thank you. Can we quickly touch base on alignment versus consensus? Because my understanding so far has been that alignment is a byproduct of consensus, but from what I understood today, and correct me if I'm wrong, if alignment is enforced by the decision maker, then at what point does it become perceived as non-collaborative? Because alignment so far has always been about consensus,

and then executing it and being on the same base for me at least. Yeah, absolutely. I think consensus is when everyone agrees that this is the best decision and you have 100% agreement from everybody. And you'll get that sometimes. Sometimes you'll just collaborate in a way that consensus comes easily. And it's fine if you have it. It's just not the thing you should be targeting. You shouldn't be trying to get to consensus. Whereas alignment, I think, is everyone agrees

that we will do this. And they may not agree that it's the best path, but they are aligned that they will give it their 100% to that decision, and they will do the best they can with it. And so they may still have a different perspective on how to go about it, but they are making sort of the the deal with you that they are going to go with the decision the way you have it. And I think you bring up a good point about how much can you do that without seeming that you're not collaborative.

And I think it's about establishing sort of what those boundaries of collaboration are. We're collaborating on this problem space together. Are we going to come up with a decision that we have consensus on? Are we going to talk through all possible models? But then I am going to make the decision or is someone else going to make the decision and we are going to present these options

to them? For me, what works when I'm making a decision that not everyone agrees with, but I also want to be collaborative is to genuinely be collaborative as opposed to just pretending to be. So be open-minded in the discussion. Change your mind as you get new information. Update your approaches as people come to you with different perspectives, but then still make the decision that you think is the best decision if you are the owner of that decision.

It's a no-once difference, but I think when you are trying to make everyone happy, you are not doing the best thing for your product or your business. Yeah, maybe a little bit more on that, but more about buying. How do you get a buy-in from somebody who is diametrically opposed to the way you're looking at the problem and that you are solution? What are some of the techniques maybe that you use? Yeah, I think for me, it comes down to understanding why they're opposed to my solution.

Is it because they have a concern that I have not fully understood yet? Or that my solution is not solving for? And if that is the case, am I not solving for it because I've missed it? Or am I not solving for it because it's not a priority to me? It's not above the other priorities that I have in my stack ranking. And so exploring that with them can help me understand why they're opposed to what I'm saying and it can help them understand why I'm not doing what they're saying.

And so that collaborative exploration really helps you in getting there. The other thing that helps me often is I will just say to the person, can you disagree and commit on this with me? And I use those words and often people will say, yes, I can. And sometimes people will say, no, I absolutely cannot. I just can't get there with you. And then it forces me to think about, am I really missing something here? If they're this

strongly opposed or are they just not going to get there? And then I need to figure out how to work around this problem until I can get them there. Quick question about bringing problems and abstracting them higher before delegating them. Like, I've definitely been on the receiving end of delegation where the problem was so abstract. Like, I've pushed back on it because I feel like I'm walking into a badger's nest here.

You know, like, I mean, I don't know if there's an exact question coming out of this or not, but it seems like a kind of a thorny problem to sort of decide the level of abstraction and and make sure that the people you're delegating to feel taken care of, you know, and that this the delegation is a mutual benefit and not just one-sided benefit. Yeah, absolutely. I have also been on the receiving end of that where I've sometimes received

a problem space where at the end of it, I'm just like, what? What do you want me to do? Like, I have nothing to take from this. And so I totally get it. I think for me, the right level of abstraction is one where you can still define what a successful outcome looks like. And so when I'm delegating the problem space to someone, if they ask me, okay, if I've solved your problem, what will it look like? What will it feel like? If I can't answer that question, I've gone to

high level and I shouldn't be delegating that in the first place. I'm not ready to do it. And so that really makes it concrete for people and it allows them to solution towards something. The other thing is, in most cases, when I'm delegating, I am not divorcing myself from the problem entirely. And so they know that they can come back to me that I'm still involved in this with them and I'm still a partner and a collaborator to them in it. And so there are a lot of times when

I didn't do a great job of delegating in the first place. And then I'm working with them a whole bunch until we can get to a point where they can own the problem and that's fine. There are some cases where you're sort of giving away the whole problem to someone in some other department. And that's not the case anymore. But even in those cases, I will try and stay engaged for as long as people need me and as long as my time permits until they're set up

for success. I want to ask about the escalations. Let's say somebody comes to you and ask your decision. What makes you say, why are you coming me with this question? Why are you not making the decision yourself? Or like, you're failing at your job. This should be something you should have done. Why did it come to me? You know, in most cases, when people come to me instead of making the decision themselves, I don't think they're failing at their job. I think I'm failing

at mine. Or neither. I think we're just collaborating. So, you know, yeah, in most cases, when someone's coming to me with a problem, it's because I have contacts that they don't. I have reassurance that they need. I have expertise that they don't have. I haven't empowered them enough to make this decision. And those are all good signals, both for me to help them right then and then also for me to improve as a leader. And so it's very rare that someone's coming to me and asking me for

a decision. And it's because they're not performing at their job. It does happen. And sometimes you have folks who aren't performing. But in most cases, it's something else. And I would also say sometimes they don't know that they're the decision maker. And so they're coming to me and asking me to make the decision because they think I'm the boss in that situation. And so often in those cases, I'll also tell them, this is your decision to make. And I will defer to you whatever you decide.

And that really helps move people along as well. I think we are at time. Thank you so much everybody. Don't miss out on ELC annual our community's flagship conference happening in San Francisco on August 30 through 31st. You'll leave ELC annual equipped with practical proven strategies that will transform you into a more effective leader. Visit sfLC.com forward slash annual 2023 to secure your tickets now. Join us at ELC annual and be a part of the future of engineering leadership.

We'll see you there.