Why Good Ideas Still Fail to Get Backing

Why Good Ideas Still Fail to Get Backing

• 59 views
vlogvloggervloggingmercedesmercedes AMGMercedes AMG GTAMG GTbig techsoftware engineeringsoftware engineercar vlogvlogssoftware developmentsoftware engineersmicrosoftprogrammingtips for developerscareer in techfaangwork vlogdevleaderdev leadernick cosentinoengineering managerleadershipmsftsoftware developercode commutecodecommutecommuteredditreddit storiesreddit storyask redditaskredditaskreddit storiesredditorlinkedin

This video is a response to a viewer looking for feedback on getting buy-in for a proposal that should help their whole team.

📄 Auto-Generated Transcript

Transcript is auto-generated and may contain errors.

Hey folks, we are going to go to a submitted question. This one's from LinkedIn and the topic is around influence and buyin. So the scenario that this person submitted is that they are having some challenges getting uh full support for a project proposal that they have. And I don't have like all the details of course uh and the specifics but the the premise seems to be that they have a proposal that uh they believe will help uh like significantly help a lot of uh the team that they're on and the sort of the catch is that it's going to require uh people on the team to work in a in a different way. And so they said that they have they do have support from most of the team for this project but there are a few uh engineers on the team that are I

guess like considered maybe I'm maybe stretching this a little bit but my assumption is maybe like the more the more senior more tenured engineers there's a few of them that are kind of uh pushing back on the idea right so it's not a it's a full buyin from the team and it's not a full uh um you know dismissal from the team or rejection. In fact, it seems like most of the team is bought in except for uh a few key stakeholders, right? And a detail that I don't have on this is like if the few that are uh sort of pushing back on the idea share the same concern or if it's uh more sort of unique for each of them. But there is uh sort of this push back from the more you know uh some of the key stakeholders on the team and the characterization of this is that it's either like from the person who submitted this it's either very minor things from their perspective.

So to to to the point where it's like it's it feels like negligible to them like why like why should we really even be concerned about that and they're still trying to come up with some uh sort of mitigations for that or almost like a misunderstanding of like what the of what the goal is. So, I figured this would be a good one to talk about because this is uh genuinely like I think a thing that you will see more and more of as you become more and more senior and as long as you're in a role that kind of empowers you to sorry role and environment where you're empowered to kind of drive some of these changes and uh it's tricky because even if you're in you know say an environment that is conducive to this kind of stuff so say your manager's open to this.

It's kind the kind of thing that can happen within the team. You know, it's not unheard of for things to change. Like, if you're in an environment like that, it doesn't automatically mean that any proposal you have just like is taken forward, but also there's a lot of people that don't work in environments like this where like any change is just resisted outright by everyone um because change is uncomfortable, right? So, I think this would be good to talk through because I I do think it's a really common thing and um yeah, unfortunately uh we don't have the details on like what kind of environment this is overall. Um but yeah, to me it at least sounds like uh if this person was, you know, in a position where they were coming up with a proposal and some people were at least willing to listen that it's not uh outright such a terrible environment.

But it is going to be common where you have some key stakeholders that don't buy in right away. So a few different angles that I would consider in situations like this, right? Um one is that I think almost it's it's really rare where you're going to have some type of behavior change. And I say behavior change as in like process change, behavior change, like ways that teams work. It's rare that you're going to have something where you propose it and every single person on the team is like, "Hell yeah." Not saying that's impossible. Um but the reality is that you know like change is uncomfortable for people, right? So change is uncomfortable for people. And so even if the idea is awesome, you will uh I find like statistically have some people that are just like I'm not I'm just not ready for change.

and almost like I I will I won't even listen much further to what your proposal is and I will look for ways to kind of push back cuz I just don't want to have to change what I'm doing, right? Like things work for me and any change is some level of discomfort. So I just simply don't want to be bought into whatever you're talking about. So because of that um like if you accept that that is some kind of reality like how and how I don't know how prevalent that actually is but to me I find that's almost in every kind of proposal we have a bit of that but if you accept that that is there is some truth to that then I would say we have a couple of different angles to try um one is going to be that your proposal isn't

actually um you don't actually require the entire team to be bought in to start and I think the reason this works is that um when you try to get full buy in and you don't have evidence like you don't have actual data that shows we have tried and this works some people will say like it's really difficult for me to you know accept that you want change you want us to change behavior actions the way we work and we don't even know if this works right like are you just wasting our time with this. So instead of having the whole team bought in, the proposal is actually let's try an experiment and you can do um a subset of the team. So do you truly to see this as an experiment? Do you truly need the entire team, every single person on the team to be bought in 100% to try an experiment to get some results?

I would suspect that you don't need fully 100% of the team. And if you do need 100% of a team for a given project, is there another way that you could slice this up? One sec. Sorry. and people that were like keeping me from being able to fully get up to speed on the highway. Um, if you do need a whole team on a project to be bought into this way of working, is there a way that you can still make it an experiment by doing it on a um a smaller subset? And I mean like is there a uh a side project a like a is it repos like is it because of a repository you're using? Is it because of truly uh like you know methodology in the sprint or whatever? Um c can you find ways to do a smaller scope version of it just as an experiment so that everyone who's doing the thing is bought into it and you can do it with a smaller subset of people.

right there. There's a lot of ways that you can slice and dice that. Let's move over to this guy. Um because he wants to go a lot faster than me. And the idea there being instead of trying to get everyone who's not even willing to try on board initially, you can run the experiment with the subset of people that are willing to try and are interested or engaged or at least engaged to neutral because you might have some people that are neutral that are like sure like I'll I'll jump in and try like that's fine whatever. Um but by doing this you can actually try it for real. You can collect data for real. You can have evidence for real, right? And you can get started with something. And you might even learn for yourself that like whatever you're proposing has improvements to be made, right?

You can you can literally get data to find what some of the gaps are and what some of the the reality is around benefits, right? And so I I think finding ways where you can not only time constrain it, but use a smaller subset of people uh is is a really helpful strategy. And so I've seen this kind of thing work. I've seen even if even if you have a team, right? I I've when I've managed uh like some smaller teams in the past, we've had conversations around look like if the team culture is such that we accept that we can run experiments as a team and that means that like as a team we all agree when we try an experiment we'll have it time boxed 2 3 4 weeks whatever it is we have an agreement that like we are coming back to discuss this Right?

It's not a permanent change. And one of the nice things about if you have sort of team agreements like this or like a team culture that supports this is that you can try things out. People can propose things and they can be they can be shitty ideas in the end, but at least people get to try them and there is buy in and support to go try these things, right? You can push back on them and say, "I don't think that's going to work." But if you don't have like good evidence otherwise, then it's like, well, you might as well try the experiment to prove it. And then if it doesn't work, great. The whole team learns, right? You learn as a team that, hey, this way of doing things maybe isn't great or it's neutral or maybe it's really awesome. Or maybe you run the experiment and you go, hey, look, we actually see that there there's something here.

Maybe we're not doing it quite right, but like you know, so that the metrics that we're trying to look at to prove the benefit not quite there. But you might even have people that weren't in agreement from the beginning going, "Wait a second." Like, now that we're trying this, I think I think if we try shifting it a little bit, like I actually could see this working. So being able to try out things as an experiment I think is really important. Okay. So, um it's something that I encourage as a team culture, but uh you know, that's a sort of a longer term thing if you're um you know, doing more of this kind of stuff in the future, maybe that's something that you can kind of suggest on the team, right?

If this is successful in the end or even if it's not successful, but your team ends up trying it, you know, getting getting the team to a point where you can be like, "Hey, why don't we try something else, a temporary thing? Let's experiment. Okay, next thing I want to talk about is sort of a buy in through inception. And this kind of goes back to what I was saying around people don't love change. They want to resist it. And so I think one of the things that can help with that is bringing on people to be part of the change. It's not a not a solution for it, but I think it helps a lot. So for example, uh I don't actually know what uh this proposed project was trying to to help with, okay, but let's just make up something.

So, let's assume that this was like, hey, if everyone changes how they're working on the team, we can actually make sure that we never have a flaky test get committed into the codebase ever again. And that's actually something that's a huge pain in the ass for us. Okay. Um, so that's your proposal. You have some people that aren't bought in. And so for your proposal, you just have people that are like, "Nope, like I don't support this." And they seem to be coming up with excuses and resisting. So, one of the ways to try and address this is to to talk to these individuals about how they perceive that problem, right? Because if you're going to them with a solution to a problem they don't think exists, then like that's going to be really hard to get buy in.

Uh and furthermore, if they if your proposal like whatever you're suggesting is a solution, uh maybe they do acknowledge the problem exists, but they think that your proposal is actually making new problems for them, they're going to want to resist, right? There's a whole bunch of different reasons why people will be resisting. So instead of trying to convince people, right, where they're like, cuz they might just be defending it and you're just kind of on the offense and then defending what they have to say and it doesn't feel like you're moving. Um, how can you find ways to bring those people on so they can be part of shaping what the solution is? And to make this, you know, into into a huge generalization, one of the sort of strategies that I use with teams is that and especially like coming into a new team, I I think that it it is in uh my worst interest to come into a team and try to make changes, right?

Uh even if I were brought into a team and a manager was like hey by the way like my ma new manager would be like I want you on this team because there's a lot of problems and uh you kind of have to you know forcefully drive some changes like number one I probably wouldn't take something like that. Uh, but number two, um, I still wouldn't just demand change or like say what the change is and everyone's got to do it because I think that's a terrible way to actually get real support. And the way that I would try to do that is I was kind of joking when I said inception, but like if you've seen the movie, the idea with Inception is that you make people think the idea is theirs. And it's because it kind of is, right? When they're bought in and they're trying to also solve a similar problem, they can be part of the solution, then it's kind of like inception, right?

You get people to to help with solving the problem. So, it is part like the solution is partially their idea. They might eventually arrive at the exact same thing and they might not. And the goal to to be very clear here, the goal is not that you eventually convince everyone you are right. Right? That's not a you in the moment it might feel like that cuz you're like I have this proposal. I think it solves the problem. I need to convince people that I'm right. That's not actually your goal though. Your goal is that you want to improve the team, right? Like that's actually the goal. to be comp like I'm making a bit of an assumption and a stretch here, but like let me throw this out there. You have this proposal, most of the teams bought in, a couple people aren't, and so you're trying to get people to agree with you, right?

So that you can have the solution. Imagine that you are proposing this and one of the stakeholders that disagrees is like, I need to shut this down, but here's a different solution and it's actually twice as effective and requires half as much work. Like if that if such a thing existed, you might go, "Oh like maybe we should do that." Right? Like the goal isn't actually that you are right. The goal is that you see improvements for the team that you're on. So when you try to get other people to work with you and be part of creating those solutions, um it might end up being a different solution. It might look different from what you're proposing and that's actually totally fine. In fact, I think some of the best solutions come up that way, right? There's gaps in what you're understanding and there's nothing like nothing wrong with you for that.

there's just gaps and you have other people coming on board to try and help you know come up with proposals to address those things. So I think if you're working with people like this obviously it's going to depend on exactly what they're resisting if they even acknowledge this as a problem. you could try getting them involved in a way where you're like look like okay like I hear what you're saying um you see this part of the proposal is actually worse more work um so for this type of challenge because other people are experiencing this like can you like would you be willing to come up and provide some some ideas for like how you might approach that in a way that that doesn't introduce this new problem for you right or is less work for do or is more resilient or it's faster or whatever.

Um, whatever the thing is you're proposing like can you get this person brought on board so that it's not them just signing off on it, they're actually helping come up with the ideas with you. I think this kind of approach can work really well. And um in the end too, like yes, it's more work cuz now you're trying to collaborate with more people, but you actually might have um you know, someone who's willing to partner with you and that can actually help get things done more effectively. Okay, so I actually have more to talk about on this, but I have to wrap it up there because I just got to CrossFit. So, um I think two things I kind of talked about are uh one doing experiments. I think by far this is what I would recommend um leaning into. And that looks like time boxing things.

That looks like uh doing them with smaller cohorts and basically collecting data. And that means that it's okay if you find some things that don't work well. It's great if you find data points that uh align with what you're trying to do. Um and you can learn a lot, but the extension to that is like can you try to get your team bought into a u you know a culture like this over time that it's okay to run experiments because even if you have everything working perfectly today, right? Your team is operating totally effectively, you guys, you know, everything's good to go. uh in a six months in a year in two years. Uh if a team is not evolving to software landscape around them that's probably evolving you're going to like you will not be as efficient or have uh you know zero problems or whatever indefinitely because things around you are also changing.

Um, just imagine like, you know, over the past couple of years like AI becoming more prevalent if a team was like, "Hey, we we run perfectly smooth. Nothing nothing's going to stop us." And then you have AI coming around and a team is like, "Well, we can just fully ignore this because like that's just not relevant." Like that's changing everything. So like how how do you have uh the ability to adapt built into your team? I think there's a lot of benefit to that. So um I would encourage like trying to drive team culture in that direction. Um and then the second part I was talking about was just buyin and uh buy in through inception. So really bringing people on board instead of uh being feeling like you're in positions where you're constantly debating with people and you're like well I have to get this person's sign off or else it's not moving forward.

um instead of putting yourself into a position where it's like me versus them, like how can you change it so that it's like them with me? And that's what I'd recommend. So, thanks for watching. See you in the next one.

Frequently Asked Questions

These Q&A summaries are AI-generated from the video transcript and may not reflect my exact wording. Watch the video for the full context.

How do I move a project forward when some key stakeholders don't buy in?
I don't think you need 100% buy-in to start a change. I suggest trying an experiment with a subset of people to see real results and collect data. I use time-boxing to limit scope and learn what works and what doesn't.
What does 'buy-in through inception' mean and how can I apply it to get stakeholders on board?
I try to bring these individuals on by involving them in the problem and shaping the solution with them. I aim for inception-like buy-in: the goal isn't to prove I'm right, but to improve the team. I accept the possibility that the final solution may look different from my initial proposal and may come from others.
Why should I run experiments with a subset of the team instead of waiting for full buy-in?
I would propose doing experiments with a smaller cohort to gather real data and see whether the idea actually delivers value. I would time-box the experiment and clearly define the scope so we can learn quickly. I can learn from the results, adapt the approach, and demonstrate value even without full team buy-in.