Getting it right and watching nothing happen is one of the stranger experiences in consulting or in-house design work. The instinct is to diagnose the failure as quickly as possible. The framing was off, the sponsor wasn't positioned, the timing was wrong, so on and so on. Those are all real factors, but the failure mode that runs deeper starts with the expertise itself.
Certainty is often what kills buy-in.
When you arrive with the answer fully formed, your data marshaled, logic tight, recommendation clear. You've done something that feels like good work and functions like it. The problem, you've removed the organization's stake in the conclusion. People defend positions they helped reach. Delivered conclusions, even correct ones, arrive without the process that creates ownership, and organizations can sense the difference between the two. And even if your solution is the best for the given problem, if the stakeholder doesn't feel they had a hand in that solution, they could shut it down all together.
The most durable decisions are the ones people remember shaping. When the problem gets framed in a way that makes their experience relevant to solving it, they arrive at the conclusion alongside you. Bring a fully formed answer from outside and they receive it as yours, not theirs. Better evidence that this is the right solution doesn't fix this. The quality of the solution was never the obstacle, it's who and how the solution came to be.
Certainty compounds the problem a lot. The more airtight the argument, the less space there is for the org to push back, adapt, or invest. A presentation that has pre-answered every objection hasn't created a conversation ... it's issued a verdict. Verdicts produce compliance at best and resistance more often, and neither one moves an organization.
The practitioners who struggle most with this are often the most capable ones. They got good at their work by developing sharp judgment, building confidence in their conclusions, and presenting those conclusions with conviction. Inside an organization trying to change, those same qualities can close off the conditions that make change possible ... you know, that moment when the org arrives at the problem in its own terms and understanding and claims some ownership of what comes next.
Deploying expertise differently doesn't mean hiding it. It means choosing the moment when conclusions do the most work. Before that moment, questions get you further than answers. They are not leading questions dressed up as listening, but genuine interest in how the org has already thought about the problem, where it's tried and stalled, what it believes is in the way. You need to hear the business and stakeholders, this helps bring them along with you on the journey of solving. When the diagnosis lands after that kind of conversation, it arrives as confirmation of something the org already sensed rather than a correction of something they got wrong. The insights are still the same, however the path to ownership is different. That shift is what separates a recommendation that gets acted on from one that gets owned.
There are engagements where this isn't possible however. It might be due to compressed timelines, predetermined outcomes, sponsors who want the verdict delivered and done. The "I don't care how you fix it just fix it..." Even in these situations ask yourself, how might I find a way to get some degree of ownership in the direction from the right people?
A lot of this runs against most of what practitioners are trained to do. The value proposition of a consultant or a senior design leader is expertise, you are on this team because you know how to solve this problem. You've seen enough to know what the org can't see about itself. And you demonstrate that expertise as to why you are there to help solve the problem. But past a certain point, the same demonstration starts working against you unless you gain that org level connection.
The organizations where design work actually lands tend to be the ones where someone on the team understood this well enough to slow down. To ask and genuinely understand before concluding and providing a solution. To let the client articulate the problem and then build the solution in a way that felt like theirs, to collaborate and approach it like a team. The rigor didn't change, your capabilities and knowledge that got you there didn't change, what changed was how much room the org had to get there alongside you.
This post feels like a bit of a ramble and I've gone through it a number of times to adjust it ... if you take anything from it is the need to get by in and co-creation with your client or org is so very important in making sure "being right" can be enough and bought into.