"My Manager Doesn't Trust Me Yet". What I Tell Every Mentee Who Says this

Six months into a new senior role, a mentee told me his manager didn't trust him yet. The fix had nothing to do with his work.
Krunal Parmar
I help software engineers land Big Tech roles and level up - structured, outcome-focused 1:1 mentorship.
Get in touch

A mentee of mine, six months into a new senior engineer role, opened our session with a sentence I have now heard from at least fifteen people I have worked with: "I think my new manager doesn't trust me yet. I don't know why. I'm doing good work."

He was. I had read the projects he was leading. The technical depth was there. He had moved from a hands-on team to a more cross-functional one, and the work itself was no harder than what he had been doing for years.

What had changed was the audience. He had gone from a team that already trusted him to a room of senior people who had no prior context. And in that new room, he was sounding small without realising it.

I asked him to do one thing before our next session: forward me three Slack messages he had sent his manager that week. No editing. Just paste them in.

He sent them on Sunday night. Here is what they looked like (paraphrased, names removed):

"Hey, sorry to bug you on a Friday, but I was thinking, and this might be totally wrong, but I wonder if maybe we should reconsider the rollout plan? Just a thought though, no worries if not."

"Quick one (sorry!) - I'm not 100% sure I'm reading this right but it kinda looks like the dashboard might be off? Could be me. Let me know!"

"Apologies for the delay! I've been meaning to send this. I think the design is fine? Happy to dig in more if useful, but probably you've already thought about this."

Three messages. Eleven hedges between them. Two apologies for things that didn't need apologising for. Zero clear asks. And by the third one, I could feel the manager on the other end skimming.

That was the conversation that broke it open. The technical work wasn't the problem. The packaging was.

This is the single most repeatable pattern I see across the 100+ developers I have mentored. Strong engineers, often from cultures where modesty is a real value, often the smartest person in the room on their actual domain, accidentally training the room to discount them through the words they use to wrap their ideas.

Here is the actual coaching arc I run with people on this. It usually takes about three sessions to land. I am writing it down because the same conversation, in slight variations, keeps coming up, and I want to be able to point new mentees at something concrete.

Session 1: see it

The first move is just noticing. Most people who hedge a lot have no idea they do it. It is a verbal tic shaped over years and it has gone underground.

The exercise is the one I described above. I ask the mentee to send me, unedited:

  • Three recent Slack messages to their manager or a senior peer.
  • One recent meeting recording, or just a recap of what they said in the last meeting they were in.
  • One PR description they wrote.

Then we go through them together and I circle every hedge. Not to shame them. To make them visible.

Common ones:

  • "I'm not sure, but..."
  • "This might be a dumb question..."
  • "Sorry to bug you..."
  • "Just a thought..."
  • "I could be wrong..."
  • "Does that make sense?" tacked onto every paragraph
  • "I think probably maybe..."
  • "Quick one!"
  • Apologising for response times that were not late

The reaction is almost always the same. They look at the count and say something like "oh god, I had no idea." That is the whole point of session one. You cannot fix what you cannot see.

Session 2: replace, don't suppress

The instinct after session one is to overcorrect. People come back two weeks later sounding stiff, like they swallowed a self-help book. That is not the goal. The goal is to replace the hedge with the actual thing the hedge was trying to do.

This is where I introduce a small rule I have stolen from my own writing edits: every hedge is doing one of three jobs. Figure out which, then do that job directly.

The three jobs:

  1. Genuine uncertainty. "I might be wrong" sometimes really does mean "I'm not sure of the data." Fine. The direct version is "I haven't validated this against production data yet, so treat it as a hypothesis." That is a confident statement of where your knowledge ends. Specific, actionable, and it does not undermine you.
  2. Politeness. "Sorry to bug you" is usually trying to acknowledge that the other person is busy. The direct version is "When you have a few minutes today" or just no preamble at all. Senior people do not need to be cushioned. Most of them prefer the message that gets to the point.
  3. Inviting pushback. "Just a thought, no worries if not" is often trying to leave the door open for the other person to disagree. The direct version is "Here is what I would do. Curious if you see it differently." That keeps the door open without volunteering yourself as a doormat.

I get the mentee to rewrite their three Slack messages from session one using these substitutions. Then I make them send those rewrites for real, to the actual people, that week. Not as an experiment. As a default.

The first week of doing this is uncomfortable. By week three, most people stop noticing they are doing it.

Session 3: bring the next step

This is the one that moves the needle on how senior people see you, and it is independent of the hedge work.

The reframe: stop bringing problems. Start bringing problem plus proposed move.

Concretely, if my mentee was about to send their manager:

"Hey, the deploy pipeline failed three times this week. Wanted to flag it."

I get them to rewrite as:

"Deploy pipeline failed three times this week. I think it's the new health check timeout we added last sprint. I'd like to revert it tomorrow morning and watch for a day. Anything I should consider before I do?"

Same problem. Wildly different read on the speaker. The second version still leaves room for disagreement, still asks for input, but it positions the speaker as someone moving on the problem rather than handing the problem upward.

I tell every mentee the same thing about this exercise: the proposed move does not have to be right. It just has to exist. You will be wrong sometimes. You will get corrected. That is fine and it is part of the trust-building. What you cannot do is repeatedly hand a problem upward with no proposal attached. That trains the senior person to think of you as a reporter of issues rather than a solver of them.

This one habit, sustained for a quarter, is most of what a promotion to senior looks like at a lot of companies. I have watched it happen multiple times.

What changed for the mentee I started this post with

About eight weeks after session one, he sent me a screenshot of his next 1:1 notes from his manager. The line that mattered, paraphrased:

"You've stepped up a lot recently. The way you brought the migration plan to leadership last Thursday was exactly what I needed from you in this role."

He had not changed what he was working on. He had not learned a new technical skill in those eight weeks. He had stopped wrapping his ideas in apologies and he had started bringing the next step.

Here is the bit that I think is worth being honest about. The original Slack messages he sent me were not the work of someone who lacked confidence in their ideas. He had strong opinions on the rollout, he had spotted the dashboard issue correctly, he was right about the design. The hedges were a habit he had built up because in his previous role, in a culture where junior engineers were expected to defer, that style had been correct. In his new role, in a more flat-hierarchy team where senior people were expected to assert, the same style was reading as lack of substance.

It was not a confidence problem. It was a calibration problem. He needed to update the wrapper to match the new room.

A note for mentees who feel uncomfortable with this

Some of the people I work with push back on this work, and I want to be honest about it. They feel like they are being asked to perform a personality that is not theirs. To talk like a confident American manager when they are not one.

I take that seriously. I am from a culture where hedging is, in part, a sign of respect. I do not think the answer is to abandon that. The answer is to recognise that the same tools serve different functions in different rooms, and to choose deliberately. With your peers from a similar background, soften the message; that is a real signal of warmth. With a senior leader in a high-stakes meeting, drop the softening; that is the signal they need to take you seriously.

This is not about becoming a different person. It is about getting better at choosing the wrapper.

What I would tell you if you were in front of me

Pick one habit and run it for two weeks before adding another.

The one I would start with: catch yourself hedging, but do not try to stop yet. Just count. Two weeks of counting will do more for your awareness than any rule I can give you.

The second one: the next time you would normally bring a problem to your manager, write down one proposed next step before the message. Send it with the proposal included.

That is it. Two habits, two weeks each, for one quarter of the year. Most of my mentees who do this report that something visible changes in how they get treated by senior people in that window. None of it is a personality transplant. All of it is just better packaging on work you were already doing.

If you are working on the same thing and have a sharper version of any of this, I would genuinely love to hear it. Most of my best coaching moves are stolen from people I have mentored.

If you are facing the same problem, let's chat and fix it! 

Ready to find the right
mentor for your goals?

Find out if MentorCruise is a good fit for you – fast, free, and no pressure.

Tell us about your goals

See how mentorship compares to other options

Preview your first month