making decisions is becoming more and more the central activity that you're going to participate in as a software engineer and in today's episode i want to talk to you about advanced techniques in decision making and in persuasion uh we're not going to cover the whole gamut here we're going to talk about a couple of them to hopefully get your wheels turning about this topic about the fact that your job will continue to move more and more towards critical decision making you're not always going to have direct control over that my name is jonathan cuttrell my goal on the show is to help driven developers like you find clarity perspective and purpose in their careers and we're talking a lot about change recently we're talking about how uh these these new agentic tools are changing our jobs every day and we're talking about how we're changing our jobs every day and the primary impact that this has had we're going to try to sum up a lot of what's happening in in the industry right now in a very short you know summary here but the primary impact this is having is it's making coding a lot cheaper right and and uh you know you may disagree with this we can talk you know more about why i believe this is the case but overall a lot of things that otherwise would have taken more time are going to be changing the way that we're doing our job and now notice i'm not saying optimally accomplishable i'm not saying that uh you know what's delivered by these agentic workflows is perfect by any means but the outcomes that uh that ai tooling that agentic workflows are producing are sufficient enough that they are shortening the lead time right they're shortening the the cycles required to accomplish a given thing and so as a part of that i'm going to talk a little bit about how we're going to be able to do that and i'm going to talk a little bit about how we're going to be able to do that and i'm going to talk a little bit about engineers and uh software development life cycle people who control the sdlc in a company they're recognizing that this is changing where the bottlenecks are it's changing you know what this job really is about right it produces a much faster step in the process and interestingly that faster step in the process used to be the bottleneck right so we kind of we didn't incrementally improve the bottleneck uh this these these tooling uh improvements are drastically changing that bottleneck so that other things now are much much more the bottleneck and so if you know much about this language that i'm using when i say bottleneck it comes mostly from traditional manufacturing where uh you know let's say you make widgets and in your widget factory you have a series of steps and each step takes a certain amount of time maybe it takes you know it has a certain failure rate it has a certain throughput it has you know required upstream components that need to be taken into account but ultimately uh in this in this environment this kind of traditional manufacturing environment your throughput your total throughput at the end of that pipe is essentially defined right the the the velocity of your factory is defined by the bottleneck and so uh you know if you were to go and get your six sigma black belt or if you have an mba and you work in a traditional manufacturing environment you know that the prescription is to work on your bottleneck until it's no longer the bottleneck but then don't keep working on that area divert your resources to the new bottlenecks right you know start moving people start moving money start moving uh you know uh resources whatever resources you have towards the the new emerging bottleneck of course you can't regress on the on you know the solved bottleneck that you just left you have to make sure that that stays solved um and you know arguably coding is not totally solved right we have we still have problems of quality control review all of these things that start to emerge but uh because this bottleneck picture is changing uh you know we can disagree on how much and and how thorough that changes but it is changing because of that we're starting to see those resources divert right there's some intuitive response to this which is well if this particular step is super super fast then we don't want people sitting idle what can we do to make sure that we're not sitting idle and we're not sitting idle right so what can happen in this in this picture is you have if if nothing else changes right if nothing else about our pipeline changes then engineers are going to be sitting around waiting on work to arrive right the the typical product backlog is uh they're not overworked to the point where they have a ton of stock this is again those those manufacturing terms um you know in a typical factory uh setting you would you would call this a stock where you have uh let's say a bunch of those widgets they're halfway done and they arrive at the bottleneck step well if the upstream steps are really fast and if there's too many resources already dedicated to this upstream uh uh steps right the parts that make the first half of the widget and there's going to be a big pile of half made widgets sitting in front of the bottleneck right they the the stuff kind of piles up before the bottleneck and so if we were to see that you know product had a big backlog that is piling up faster than the engineers can burn through it then the effect here that i'm talking about will be a little bit delayed right because engineers are going to work through that backlog as quickly as they can which now is much faster but once they get to the point where that backlog has been burned through now we're talking about a new kind of a novel experience for most engineering teams where the engineers are outpacing their upstream counterparts all right so this is why in this episode we're going to focus on some of the upstream things that are not far away from engineering even some of the in-process engineering things that have traditionally not been in your job description as an engineer right that most of the time these uh what we're talking about today with decision making has not necessarily fallen into your lap you can defer or you can delegate those decisions out they're not necessarily your your job in a lot of uh kind of scrum type environments a product owner or a project manager all of these terms for people who handle those decisions maybe a designer is handling them maybe it's a business representative you can defer or you can delegate those decisions out they're not necessarily your job in a lot of whatever that is most of the time engineers have been responsible for the how not necessarily the what but it's very likely that as this bottleneck of how gets smaller your responsibilities as an engineer to continue moving resources to the bottleneck right the the uh responsibilities you're going to have is to help make more decisions help facilitate decision making so that we're making more decisions and we're making more decisions and we're making more decisions making faster decisions and the throughput of these other processes can start to equalize with the throughput of the how the the actual coding uh you know throughput that you are hopefully uh at this point you know that this is changing and that um you know if you are not paying attention to those changes that you're going to get left behind okay so we want to talk about decision making when we talk about specifically a couple of of decision making that i personally i've seen these two things uh kind of get in the way of a lot of otherwise very senior engineers who uh have great careers who are really good at what they do but they get stuck in these two things i want to talk about two of them today um but first i want to talk about today's sponsor unblocked your coding agents have access to your code base and probably much more and you've probably connected all the mcps that your organization has access to but it's not easy to keep up with all of that um and access doesn't always just equate to context agents can't really reason across mcps they don't know what architectural decisions you've made for example and they don't um they don't know your team's patterns why is the api shaped the way that it is so agents are looking in the wrong place and then they can often deliver bad outputs as a result of that this is part of what i was talking about coding is not totally solved we still have some of these kinds of problems so then you spend your time correcting what the agent did which is wasting your time and your tokens just to get back to a baseline unblocked is the context layer that your agents are missing it synthesizes the code and it's not just the code that you're your prs your docs your slack messages jira issues into organizational context that agents actually understand so they make better plans they write higher quality code and they'll use fewer tokens in the process requiring fewer correction loops if you're running clod code cursor or any other agentic workflow which if you're not by now then it's time to get on board unbloxed is worth a look get a free three-week trial at get unbloxed.com developer t that's unblocked.com Thanks again to Unblocked for sponsoring today's episode of Developer Tea. So we're going to talk about two ways, two ways that I have seen, you know, a large number, I don't know exactly how many, of senior engineers get tripped up on these two things, these two aspects of decision making. And I want to be clear, when I say decision making here, I don't just mean making the final call. Decision making in an organizational context, in a product context, is very much about creating arguments for what you think should happen. This is more like a debate than it is about authority and making the final call. And I want to be clear, when I say decision making here, I don't just mean making the final call. And so it is much less, you know, on your shoulders to make a good decision. And it's much more about how do you bring to light the correct information, the correct arguments to persuade and help create the right conditions for good decision making. Right. So because engineers are being relied on more for decisions and very largely speaking, engineers have not been involved in these discussions in the past. These areas are easy to trip on, right? The first area that I want to talk about is decisions that you don't need to make. I know we just now talked about how this is all about, you know, persuading and getting involved and raising the right context, etc. But decision making, especially persuasive, proactive or collaborative decision making for engineers, this is very much an art and provides an opportunity for you to work in a way that you haven't before or work in a way that you are not like required to as often as an or weren't required to as often as engineer. And a lot of times this is a social responsibility. So in other words, as you're making decisions with a group of people, your track record and your decision making behaviors, your communication behaviors, all of these things matter to whatever the current atomic decision is that you're trying to make today. Right. So what does that mean? It means that whatever you did in the past and whatever you did in the last decision that you made together, whatever attitude you took towards other people's opinions, all of this matters. For your credibility in making decisions going forward. So this is very important because an important aspect of this, this social, you know, environment that you're going to be participating in is making sure that you are a, excuse me, it's making sure that you're not a. Using too much. Using too much. Of your capital. Your social capital in this case. Right. In other words, if you're constantly putting your reputation on the line, for example, saying, you know, you can trust me on this. If not, then you, you know, if I'm wrong about this, then you can hold me accountable to that. That's essentially what you're saying when you put forth an argument. In most cases, you're saying this is what I believe. And if I'm wrong, then in the future, you should. Trust me less. All right. In the future, if I'm wrong about this, then, and if I continue to be wrong, if I get a track record of being wrong, then it makes sense. It makes logical sense. It makes intuitive sense for other people to stop trusting you with decision making. And so a lot of times what we'll do is we'll spend our capital. That's, it's not literal capital. It's social capital. We'll spend that. Decisions that matter the most to us. So in other words, the, the advice here is avoid spending your capital, avoid, you know, putting your opinion out onto the table for things that matter very little to you. So there's a couple of ways to think about this. One. Is to recognize that often. We as humans, and especially as engineers, we feel the need or, or the kind of intellectual itch, uh, to scratch when someone presents an argument that we disagree with. And so it's very possible for us to disagree with that argument. And because of that, uh, you know, because we are prone to see an argument as an opportunity to set our own argument out. We get involved in that discussion. Now, sometimes we do this because we actually care about the outcome. Other times we do it without really even caring about the outcome. It's very important to delineate between what outcomes am I actually going to care about here? Right? The, the opinion that I have where I think you're wrong about this. Can I think that someone is wrong? And simultaneously. Not offer my own opinion. The, the correct kind of approach to this, in my opinion here. Is to avoid getting involved in arguments and decisions that you don't care about the outcome for. Generally speaking, avoid getting into that. This is, uh, an exercise in self-control because if you do have a differing opinion, it is often difficult to withhold it. But. As we'll talk about. For this, for the second, uh, you know, critical mistake. It's important to recognize what the utility of your opinion is. In this case, the utility of sharing your opinion is for your own, uh, kind of self-satisfaction. The utility of sharing your opinion is not in order to change the decision because you don't actually care about that. Right? To you, the utility of sharing your opinion in this, in this environment. Is. To feel better. Right? To, to feel intellectually engaged in the discussion. And this is usually not worth the risk that you're taking. The risk that you're taking, of course, is once again, putting your reputation on the line, potentially burning others' trust in you. Uh, you know, of course, anytime you are in confrontation with another person, you're challenging somebody else. If they cared a lot about that outcome and then they didn't get what they wanted. Then they may. Develop a kind of, uh, contrary, contrary or contrarian, uh, relationship with you. Right? So. So it matters because. In the future, you are going to care about something. Right? You are going. And maybe they won't care about that thing. But because. They have a contrarian opinion to you or they don't trust you anymore. The thing that you do care about, the thing that you have a lot of knowledge on, the thing that maybe. You know, the utility of your opinion is. Actually, you, you want this to change. Uh, there, they might fight you on it. They may come to, uh, you know, come into the room and disagree with you on it because they think that anything that comes out of your mouth is ultimately worth disagreeing with. Now, these are very extreme examples. Most of the time, this happens in much more subtle ways, but most of your opportunities are about picking your battles here. Right? There's. Another kind of variant on this piece of advice, which is to recognize what decisions will make themselves. Okay. So in other words, uh, and this, this is actually a really common example. If you find yourself trying to convince someone else of a future you believe will happen. If a decision is made. Okay. You're trying to convince them that if we do X, then Y is going to happen. A good example of this is. If we change our hiring policies. In this particular way, we're going to remove an interview. We're going to add an interview. Right? We're going to change the, you know, who's allowed to interview. We're going to change what our first call looks like. We're going to change how we do our technical evaluation. All of these are adjustments to the interviewing process. So let's say your manager says, oh, we're going to, we're going to change that. The outcome that you may predict as an engineer, you may say, oh, this is going to be a little bit more complicated. Oh, I really hate that. If I was a candidate, I would stop. I would stop my, my candidacy. So I'm, I need to tell somebody that, you know, I predict this future could happen that other people are going to stop. The utility of your opinion here. Okay. Is matched by simply quietly waiting. In other words. The adjustment that they're wanting. To make. If your hypothesis is correct, that people are going to leave the pipeline because of these adjustments. That eventuality is going to happen even without your intervention. So the learning that you are hoping that somebody takes away from this. You can get for free by being patient and waiting. Now I say free. There is an asterisk next to this, which is there's downside potentially to. You know, those, those negative effects. So for example, you may have a delay in your pipeline. You know, if you actually care about. That the hiring process, you know, succeeding or failing. For most engineers. Your, you know, kind of core responsibilities. Are not necessarily to improve the hiring pipeline. That's a hiring manager's job. It's part of the leadership's job. And so if you're getting involved in these decision-making processes. And trying to provide feedback in order to improve the hiring process. It's very possible for you. To kind of take the watchful waiting approach. Let's see what happens. Because now you're not putting yourself in a position where. You know, a, maybe you're wrong. Right. And so now you, you kind of sounded the alarm or you gave feedback that ultimately ended up being wrong. We get back into that kind of erosion of your. You know, your credibility. If you keep doing this. You know, you're going to be in a position where you're going to be. And so when you're sharing your opinions. Remember that. Kind of the core piece of advice here is. Sharing your opinion is not a free action. Right. Sharing your opinion. About a decision that's being made. Is a transaction. You're making a transaction by saying. Please consider what I'm saying. As an input to your decision-making process. But also. Here's my opinion, and you can come back and update your beliefs about me based on whether my opinion pans out to be true or not, right? So I want to be clear because I think, you know, as I'm talking through this, I'm recognizing that we're talking about kind of a political management, right, that you'd have to engage in. And that's actually true. That's a true part of this transition. And one of the hard parts of this transition for a lot of engineers is going to be that your job responsibilities, which used to be a little bit more kind of concrete and easily kind of defined as a hard science kind of definition, where something works or it doesn't work, a lot of jobs, a lot of software engineering jobs are going to shift more and more towards those soft skill kind of things, right? And decision making certainly fits in this category. So I think it's important to recognize that as we're talking about decision making, that decision making. In a collective collaborative environment is not the same thing. It's not the same thing as making a good technical decision, right? If you are arguing, if two engineers are arguing about the merits of one technical solution versus another, then based on some specific criteria, right, you could gather evidence that says one or the other of them is correct, right? And you could go through the process of choosing. You know, a particular direction. Now, we all know that even in technical decisions, opinions abound. We have a lot of people who disagree about which direction is better, which, you know, which language is more maintainable or which thing is better for startups to use or whatever. This is all, you know, a different kind of argumentation than what we're talking about with these other kind of like, for example, product level decisions. Okay. The second trap. So the first trap, just to kind of recap this, the first trap is allowing your opinion to be your difference in opinion to be the reason that you get involved in an argument, right? Because you have an opinion that that is enough for you to jump in. And my suggestion is to recognize or pay closer attention to the utility of that action. What exactly is the upside for you to get involved? Do you feel like it's going to benefit you from a social perspective or like a reputational perspective? Is it going to benefit? Do you care very much about the outcome that you have an opinion about? You know, those are the ways that your opinion could have utility or sharing your opinion could have utility in a given argument, in a given debate. The other trap. The other trap that I see a lot of engineers falling into is when they do share an opinion or when they do share an argument, they're arguing from a position that is misaligned with the decision maker's motivations, right? So some classic examples of this might be a product manager asking a group of engineers to delay some. Optimization work in order to get some product features out the door. And a software engineer may come back with the argument that, well, if we do that, then, you know, our, our endpoints are going to be a little bit slower, or we're going to have to come back to that in a couple of months. And we're going to have to, you know, deal with the on-call between now and then. Well, if you're a product manager, these things you could, you may be able to observe and recognize that they're true. But a product manager, they're unlikely to be motivated by reducing the on-call load for their engineers. Because most of the time they can, you know, maybe they have a system where that on-call load, you know, is essentially like handled by one engineer, for example, right? And so that's not a compelling argument. And there's, there's other examples where, okay, I, you know, I really didn't, I don't, I don't personally like this kind of interview. So I don't want the company to use that kind of interview because I don't like it. I don't think it's a good interview. I think it's, you know, it, I'm not very good at that kind of interview. Well, of course, if you are making the decision about what kind of interview you should incorporate in your, in your recruitment processes, then one engineer telling you that they don't like that kind of interview, maybe a small data point on your overall radar. But it's not the most compelling case, right? A more compelling case, if you're that engineer, if you say, okay, this interview that we're introducing, you know, this kind of interview is something that turns me off as an engineer. And I bet other engineers are like this. Let me go and find whether, find out whether that's true, if there's external data, right? And so your, your core argument is, is that you think this is bad. It goes against your personal values, but that argument may not align well with the decision maker's motivation. For example, let's, let's say that your, your organization is introducing a systems design interview and in your experience, maybe you haven't had a good experience with these systems design interviews. You think they're implemented poorly, or, you know, maybe that you just don't think they're very good at illuminating important skills, right? That, that may be. Your take on this, which by the way, I actually am a fan of systems design interviews. So this is a totally made up example. Okay. Well, let's, so let's say that you, you don't like that and you, you think it's a bad interview type. We should do something else. Maybe we should do, you know, another coding interview, a working session type interview. So you present this argument to your manager and you say, I, you know, I, I think this is a bad, bad interview. And your manager says, well, why, why is that? And you may come back and say, well, because I'm not very good at this. I probably would, you know, move my can. I would remove my name from the list. I wouldn't want to work at the company or I would, I wouldn't want to go through the process of, you know, going through that interview, knowing that I was going to fail. It's, it's anxiety inducing for me. And so your boss, your, your manager may come back to you and say, well, I understand that you're not good at these, but we have a completely different reason for wanting to run them. We want to recruit engineers. Who thoroughly understand systems design and have worked at companies that, you know, put a focus on that. So now the entire basis for your argument is essentially irrelevant to the decision. Right. And so I see this happen all the time with, with engineers where they're arguing from a position that they believe is rational. And this is a very important factor for you to consider. Any decision-making situation, and really in other parts of life as well, this idea of, uh, what, what's called naive realism, uh, that, that might be a term you would use for this naive realism, the idea that you somehow see the real world, you understand how things really are, right. That you have an unbiased take, or that you have a balanced take, or that something about your perspective is the closest to true that exists. Right. Right. that anyone who kind of disagrees with you must be biased, must be wrong, must not have the information that you have. Nobody who makes good decisions would disagree with your perspective. And this, of course, is flawed. I mean, when we lay it out like that, hopefully you recognize that, well, I don't actually believe that. But we act in ways, our intuition informs us that we are that way, right? That we do have the best view. And thus, you know, any disagreement, we often lack curiosity about whether we could be wrong. Our first instinct response is that that other person is wrong. And now what do we do about that, right? What do I do about the fact that the other person's wrong? And so if I have a strong opinion that this is a bad interview type, that systems design is a bad interview type. You know, myself and then that other person should jump on board with this. We may be missing an entire, you know, functional reason for this decision that has nothing to do with our reasons for believing a particular way. And so the important factor here is alignment. This is the key term maybe for the rest of your career. If you can only learn. You know, about one concept, it would be alignment. Because once you recognize what that other person cares about. Two things really could probably happen. Either one, you recognize, oh, wait a second. If they don't care about this thing that I care about, but they do care about X. Well, this does solve for that. Their decision is not unreasonable, right? Their decision actually, actually totally fine. And. My motivated reasoning or my idea behind, you know, why I didn't like this, this direction has no bearing on what they're trying to optimize for. And so they should totally do whatever it is that they said they were going to do. So that's one potential outcome. Another potential outcome is you recognize that, wait a second, there's, there's something else I could argue on here. I could, I could take that approach that I was talking about earlier, where I identify that. My. Interview type are not just my personal feelings. That this is a growing sentiment among that group of engineers that maybe they're trying to recruit. That there is, you know, a large faction of people think this is not a good interview. And then you have a different basis for your argument, right? You're, you're trying to find something that the other person actually does care about. And so now, you know, another great example of this is two engineers. Who have opinions about how a stack, a particular stack should be built. And one of them is optimizing for accessibility. You know, how, how do, how can we connect this thing? You know, to, to our existing stack and the other one's only optimizing for performance and they're going to talk past each other unless they can recognize that their arguments are just misaligned, that they're going to argue on completely different axes. Right. Yeah. And so now once you have both arguments in hand and you have the optimization strategies of both of these and you say, okay, what is it exactly that you're trying to accomplish with this decision and why now you could say, okay, we have two totally different competing evaluations or criteria for the decision in the first place. Right. So this is the, the piece of advice I have walking away from this for you is. Understand the criteria for the decision. Don't assume that your personal criteria generalizes to everyone else around you. There's a major, major mistake. Your opinion, your perspective, your worldview, your biases, and all of these other things are yours uniquely. And so if you try to generalize all that stuff out, if you try to say, well, everybody has the same belief about X. Or. We all agree on Z. Then you're very likely to make mistakes. You're very likely to make arguments that nobody actually cares about except for you. Or if they do care about it, they care about it for a different reason or not as much as you do. You see there's, there's overlap between this and the first and the first kind of trip up the first trip up being don't make arguments for things that you don't care about. Right. And so what I'm trying to do is. The kind of the overarching theme of all of this is actually knowing what the other person is trying to accomplish and why. Decision-making, especially in the collaborative environment is, is largely about understanding what other people's motivations are and finding alignment, figuring out how can, how can the thing that I want and the thing that you want be accomplished? And then ultimately, you know, the decision that works on the optimizations that you care about and the ones that I care about. This is the, the path to finding kind of a middle ground. It's interesting that decision-making really is largely about negotiation. There's very similar recommendations for negotiation, which is recognizing that you can optimize for two different things, that it's not a zero sum game. Ultimately, if you take nothing away from this episode, other than this, this would be. My, my. My. My one takeaway for you here is to understand what the other person wants to do. What is it that they want? What do they care about? Why do they care about it? That is going to pay you back every time over and over. And this is going to become a more and more important part of your job. It's it's, it is just as wild to me that I'm sitting here talking about making better decisions together or, you know, managing your political kind of relationships within your organization. but we could always kind of come back to engineering as a core skill. But this is going to become more and more important. This always was becoming more important for you as you become more senior in your career. But the acceleration of your participation in decision making is going to be much faster now. And so it makes sense to start practicing this. It makes sense to start paying attention to this more and more. Thank you so much for listening to today's episode of Developer Tea. Hopefully this was an engaging discussion, way of thinking about decision making and about persuasion in decision making, how to make better decisions with your coworkers. If you enjoyed this episode, please leave a review in whatever podcasting app you currently use. Make sure you subscribe in YouTube or in that podcasting app as well. These are the best ways to make sure that this show sticks around. We're continuing with this show until I can't anymore, honestly. I have no reason to stop doing Developer Tea. And it's been some of the most rewarding time that I've had in my life. I spend on a weekly basis is thinking about these things and trying to engage with, you know, what does this career have in store for you, for me, as we move forward into the new kind of new landscape that we're all staring in the face right now. And I'm excited for it. And I hope you are too. Thanks so much for listening. And until next time, enjoy your tea.