As a PM, my proposal stalled for a month. It moved the day after I talked to the decision-maker

Mizoko — Tue, 03 Nov 2026 13:30:08 +0000

TL;DR

My proposal to hire a web designer was stuck for about a month. It moved the day after I explained it to the client's decision-maker myself.
I did not try to persuade. I stated the facts and asked them to choose: hire, or delay the release.
After the designer joined, design-related rework dropped sharply.

The problem: no one could do the design work

I was the PM on a client project, a consumer web app for beauty salons. Design work was not getting done, and quality was dropping. That caused three problems.

The release was slipping
Developers had more tasks
Rework increased, because we often realized after implementation that a design was not good

I can't create designs in Figma. The existing designer had almost no time for the project. Design became the bottleneck.

Why talking to my counterpart was not enough

My counterpart on the client side was their PM and the team lead. They were cooperative and also wanted an earlier release. They were not unmotivated, and they understood the problem.

Still, the proposal sat for about a month. We both wanted to ship sooner, so it was frustrating.

Looking back, the reason was simple. The decision-maker had not approved it. They did not see how important it was.

The facts did not reach them clearly. It may have looked like "the team can still do more" or "it is not that serious." The view that hiring was the only option left was not shared.

What I changed: I asked to explain it myself

The biggest reason it worked was that I changed my approach.

Repeating the same message was not going to change anything. So I stopped trying to change what I could not change. I asked my counterpart: "Sorry to ask, but could I get some time with your manager? I would like to explain this myself."

I asked them to choose: hire, or delay the release

I did not try to persuade the decision-maker. I told them the facts. I was certain that development would slow down with the current team.

The fact was simple. No one could do the design work, so we needed someone who could create designs in Figma.

If we don't bring in a web designer, the only option is to delay the release.

I said it softly, along the lines of "this is the situation, and it is tough." But the request was a choice: hire, or delay the release. If they accepted a delay, that was fine with us too.

My hypothesis was that hiring and moving faster was what the decision-maker wanted. I think what decided it was that they saw a delayed release as a bigger business impact than the hiring cost.

The result: it moved the next day, and rework dropped

The day after that conversation, they started hiring a web designer. Once the designer joined, the change was big.

Engineers no longer had to worry about design work
Design-related rework dropped sharply
My counterpart and the designer talked more, refined ideas together, and design quality went up

Two things I keep in mind when I go to a decision-maker

First, I put myself in the decision-maker's position and think about what matters most to them.

Second, I make it clear that I am doing this for them. In this case, I truly believed it was the right thing for the client's company, not a way to make our work easier. That is why I made sure it did not sound like "the developers just want an easier job."

As a PM, I stopped nitpicking in code reviews. Review rounds dropped from 10 to 4.

Mizoko — Tue, 03 Nov 2026 11:35:02 +0000

TL;DR

AI made refactoring cheap, so I stopped flagging minor issues in code reviews.
Review back-and-forth with our offshore team dropped from about 10 rounds to 4.
Every comment is tagged Critical, High, Medium, or Low. Only Critical and High must be fixed.

The problem: too many review rounds

I'm a PM, and I also review code. Our development team is offshore, and review threads were getting far too long.

So I stopped flagging small things. If something needs fixing later, AI can fix it quickly.

What I no longer flag

Personal preferences in variable and function names
How finely functions are split
Small duplicated code that could be shared

Minor style improvements with little business impact are optional. Delivery speed comes first.

Test code is fine as long as it covers what needs to be tested. We generally don't write TODO comments either.

These exclusions are written into the review criteria I give Claude.

What I still always flag

Anything that affects testing effort
Deviations from existing conventions without a reason
Security issues
Code whose intent isn't documented

Intent goes in a code comment or the PR description.

Four severity levels

Severity	Action
Critical	Must fix
High	Must fix
Medium	Optional
Low	Optional

Until Critical and High issues are fixed, the code can't even go to the test environment. I don't want engineers spending time on Medium and Low. The levels also make fix priorities clear.

The result

Review rounds dropped from about 10 to 4. In practice, leaving the skipped items unfixed turned out to be fine.

Takeaway

AI has lowered the cost of refactoring, so you can let small things go in code review. Focus on four things: testing effort, existing conventions, security, and intent.

DEV Community: Mizoko