Consulting leaves a lot of room for the expectation that you’ll have an answer on the spot. Sometimes I do, sometimes I don’t, and sometimes I disagree with what I’m hearing.

I’m not necessarily successful or famous for this. I’m not a maestro here trying to give you the truth about consulting. I am sharing what I do, as a practitioner, from these years as a consultant.

1) When I don’t have an opinion yet

You know the moment: “I suddenly feel unprepared, hearing about this piece of technology or service for the first time now” or “I have never encountered this type of problem before”. How do I buy myself time? I do not want to project fake confidence. I am not a “fake it until you make it” type. Side note: it feels stressful in that moment, but in hindsight, I know I don’t want to only solve problems I’ve already solved before in my career.

You may hear me saying things like “let me look that up” or even better “let’s figure it out together.” It changes the whole dynamic: I can gather more knowledge from the other side, and start reasoning together with them. Instead of admitting a gap and leaving it hanging, or hiding it, I turn it into shared work, a moment of learning in the open, and get a more detailed picture even if I do not know the implementation details yet. Later, I will still need time to research and come up with solutions, but this keeps the conversation going and being constructive, rather than becoming awkward.

Some other times there is a feeling that gets in the way, and I find myself doubling-down with stressful negative thoughts that consume energy, like: “I’m a consultant, they hired me because I’m supposed to be the expert”.

I’ve learned to go past that feeling. Not knowing something in the moment doesn’t cancel the expertise, it’s being honest. Being kind to your own brain about it matters more than performing certainty.

2) When I have an opinion, but it’s controversial

The real insight here is telling apart a value from a scar.

Example: “Capacity doesn’t change just because priorities did. If we’re adding something mid-sprint, something else of equal effort has to go”. That’s a principle, and I hold it firmly, even if it could be controversial, and it puts the client in front of trade-offs they may not like to hear. Capacity is finite. That doesn’t mean pushing back or reducing scope, it means addressing the request flexibly: moving it on the timeline, and being clear that “the team is at capacity” isn’t the same as “we shouldn’t do this”.

“In this project we are going to be working with service X” From my past experience, I remember that working with service X was a nightmare. This is one data point from one context, and treating it as universal truth is where bias sneaks in. The fix isn’t suppressing the experience, it’s presenting it as evidence to check rather than a verdict. Instead of saying a service “is terrible,” I try to hand it over as evidence: “this is what I’ve seen, worth checking if it still holds here” to keep the information useful without using my previous bad experience as an objective fact.

3) When my opinion contradicts theirs

I need to make a distinction here: If it is a “normal” disagreement I will try to stop for a second, breathe, try not to take it personally, make my recommendation backed by my reasoning (and I may not be right, you know?) and be constructive. Instead, I don’t promise something I know is wrong, or even just feels wrong, just to make the client happy. Maybe they will receive it, maybe not. But I did what I could. Building software shouldn’t be an intense life-or-death matter except when it touches my principles and ethics (examples: exploiting user privacy). At that point, I draw a line and feel free to be more direct, to avoid giving room for other interpretations.

None of this makes not-knowing comfortable, or disagreement painless. But naming these moments instead of pretending they do not happen has made them easier to sit with for me, as I still work on this skill every day.