What Your Manager Is Thinking When You Complain
Three things managers notice when they hear you complain during 1-on-1 meetings
A few months ago, one of my engineers came to a 1-on-1 with a list of blockers. It was a long list.
The PM kept changing requirements. The other team wasn’t responding to their pull requests. Their manager (me, apparently) wasn’t giving clear instructions.
I listened, and I took notes.
Then I tried to verify: The PR response time was longer but reasonable. Requirements changed for valid reasons. My instructions were written on a doc that other members could work with easily.
Something seemed off.
I checked the notes between us, and realized that this is not the first time he pointed all blockers to someone else.
We do run into low performers from time to time, and the frustrations are real. Some teammates disappear during incidents. Some PMs change requirements every week.
But there’s a difference between running into difficult people occasionally, and running into difficult people everywhere. And this is where managers start pondering.
Three Signs Managers Look For When You Complain
One thing I’d like to point out as a manager: the signal you think you’re sending in a 1-on-1 meeting and the signal your manager is actually receiving are often very different.
When you say “everyone is blocking me,” you mean to communicate frustration and context. What your manager sometimes hears is improvement areas in ownership and collaboration skills.
1. Did You Try to Unblock Yourself?
There’s a difference between handling a blocker and simply handing it off.
In my 1-on-1 meetings, I can usually hear two different versions:
“I’m stuck on X, here’s what I’ve tried, here’s where I need your help” => 👍
“Y team hasn’t responded. I don’t know what to do next.” => 🤨
Software engineers are expected to try a few options before escalating. Asking for help is fine. But make sure you try to unblock yourself first.
2. Did You Make it Easy for Others to Respond?
Imagine you need another team to review your design doc. You send it over. A week passes. Nothing. Your instinct is to follow up and ask why they haven’t responded.
But here’s what I see from the manager’s side: the other team has their own priorities. Similar to asking smart questions, they need to know why this is urgent. They need to know what you need from them and your timeline.
Getting alignment is about making it easy for the other person to respond. That means giving them context and a clear ask that helps you costs them almost nothing.
3. Did You Try to Have a Direct Conversation?
When a PM consistently changes specs at the last minute, the common response is to absorb it, and then complain about it in 1-on-1 meetings.
However, what rarely happens is a direct conversation with the PM first: “Hey, I’ve noticed specs tend to change last-minute. It creates a lot of rework on our side. Can we talk about how we can make that work better for both of us?”
The conversation itself does two things: it aligns behaviors, and it shows everyone around you that you tried to solve it before escalating.
That conversation feels uncomfortable, so most engineers skip it and go straight to their manager instead. That’s a reasonable expectation for a junior engineer. For someone aiming at the senior level, it’s a gap.
What It Looks Like in Practice
I went back to that engineer after our 1-on-1. I asked them one question instead: “What do you think the PM needs from you to stop changing the requirements?”
They were quiet for a moment. Then they said, “Honestly, I think it’s the business stakeholders who change the requirements all the time. That PM is just the middleman.”
That was the real blocker. The business stakeholders didn’t know how the Product Division works, so they changed specs whenever they wanted. Once we provided this feedback to them, they also learned to finalize the requirements at the beginning. Specs became more stable once fixed.
It turned out to be a mindset shift. It was resolved once we started to take actions.
One Last Thing
Effective senior engineers share the same trait: when something is stuck, they ask what they can do differently before they ask everyone else to change.
Your manager might actually be incompetent. Your teammate might genuinely be difficult. Your stakeholders might be unreasonable. All of that can be true, and you can still ask: what’s my move here before escalating?
That question is what separates engineers who wait for better conditions from engineers who create them.
Have you been in a situation like this? Reply and tell me what happened.
Thanks for reading this post.
I’m building a Performance Review Survival Guide. The goal is simple: help engineers understand what their managers are actually looking at during reviews, so their work stops getting overlooked.
It’s a short email course told from the manager’s perspective. What we look at. What gets counted. What most engineers miss.
If you find this post helpful, please share it with those who need to hear it. 🙏
See you in the next post.
Adler from Tokyo Tech Lead