Introduction
What really wears you out at work isn't a boss who is simply strict.
If a boss is strict but makes clear calls, sets priorities, states the goal and tells you where your responsibility starts and ends, you can still work with that.
The truly exhausting boss is the one who does things like this:
- Doesn't make decisions
- Doesn't share information
- Doesn't turn vague ideas into clear requirements
- Waves things through with a fuzzy verbal comment
- Flips their position later
- Blows up one small flaw into blame for the whole thing
- Ends up pinning it on the subordinate's personality or traits
Under a boss like that, the people who are good at defining requirements (spelling out what needs doing, why, who decides, and under what conditions) suffer the most.
To get work moving, you're looking at the goal, the current situation, the cause, who's involved, the conditions for carrying it out, the risks and who makes the call.
The boss, meanwhile, only looks at surface impressions and a few rough edges, and criticizes those.
The result is that the two of you end up talking on different levels.
You're talking about how the work is designed.
The boss is talking about how it looks.
You're solving the main problem.
The boss is picking up minor points for improvement.
Let that gap pile up, and the boss stops being a source of support and turns into plain noise.
1. All you need from a boss is judgment, priorities and responsibility
Some people can move work forward largely on their own.
For example, people who can do things like this:
- Sort out the goal
- Grasp the current situation
- Pinpoint the bottleneck
- Break options into Plan A, B and C
- Spot risks before they happen
- Talk to other departments
- Bring the people involved on board
- Keep a written record
- Stop things if an accident looks likely
- Put together a proposal document quickly when needed
For someone who can do all this, the role they need from a boss is quite narrow.
What they actually want from a boss is only this:
- Make the call
- Set the priorities
- Formally push the request through to other departments
- Take responsibility
- Handle explanations to the people above and act as a buffer
- Not add pointless afterthoughts
Conversely, a boss who doesn't do these things is a real hindrance.
They say "go ahead" but never decide anything.
They say "think for yourself" but never set priorities.
They say "talk to the other department" but never give any formal backing.
They ask "how's it going?" but take no responsibility.
And in the end they grill you with "why did you do that?" or "why didn't you do this?"
That isn't adding value as a boss.
It's adding noise to the work.
2. "Being able to talk to the higher-ups" and "being able to define requirements" are different skills
Some managers are perfectly able to talk to the people above them.
They talk to executives.
They sit in meetings.
They ask for opinions.
They come back with something that sounds like a direction.
They say "we'll get on it" in a convincing way.
From the outside, that alone looks like what a manager does.
But the real issue comes after that.
Can they turn the vague things they heard from above into requirements the team below can act on?
After a meeting, they should break it down into something like this:
- What was decided
- What hasn't been decided yet
- Who makes the decision
- Who does the actual work
- Who needs to be told what
- What gets done by when
- Under what conditions we go ahead
- Under what conditions we stop
- What the risks are
- Whether it's actually ready to hand down to the team
Only once it's broken down this far can the people doing the work move.
But a manager who can't make this conversion just throws the fuzziness from above straight down to the team.
"Apparently something's starting in July."
"Talk to S and get it moving."
"Arrange a meeting sometime this month."
"Just do something for now."
"How's it going?"
"Why isn't this moving?"
This is someone who attends the meetings but doesn't define requirements.
Being able to talk to the people above and designing the work so the people below can move are two separate skills.
3. If you can define requirements, treat your boss as an approval gate
If you're good at defining requirements, using your boss as someone to consult can wear you down.
That's because consulting them tends to produce more vagueness, shallow comments that pull you off the main problem, or a later change to what counts as "done."
In that case, it's better to treat the boss not as an advisor but as an approval gate.
For example, you could say:
I'm going ahead with Plan A for this. The concerns are B and C, and both are already handled. If there's no problem, I'll proceed with A.
Or:
There are three options: A, B and C. Considering the impact and effort, I think A is the sensible choice. Please decide which one we go with.
Or:
Because this rolls out company-wide, we need to make a formal request to other departments. If we go ahead, please decide which departments will cooperate, who the contacts are and what the priority is.
This way, you narrow down what the boss has to think about.
You're not making your boss think from zero.
You're making them choose.
You're making them decide, and only decide.
You're making them define where responsibility lies.
If you're someone who can define requirements, the better approach is to organize things yourself first, then ask your boss for approval, a choice, a formal request and ownership of responsibility.
4. Even when you solve the main problem, you get written off over minor improvement points
The really annoying thing about shallow managers is that even when the main problem is solved, they pick at secondary flaws and reject the whole thing.
Say a document addressed to one employee had been returned to HR three times.
To fix the non-delivery, you set up a process like this:
- State clearly that it's addressed to the person themselves
- Print that it's for the training participant personally
- Also print the participant's department and name
- Add an arrow showing where to look
- Ask them, if they're having trouble receiving it, to write the reason and send it back to HR
- Tell them that if everything went fine, they can throw the slip away
- Send it with the main document attached
As a result, the main document reached the person.
In other words, the main problem, "it doesn't get delivered," is solved.
But a shallow review goes like this:
"The handwriting on the cover slip's address is messy."
"This is a complaint, isn't it?"
"Isn't this one-sided?"
"Talk to the person and find out the real cause."
"So what's the real cause? We don't know."
This is a pretty weak review.
That's because it isn't looking at the main problem it should be looking at.
What should be checked is this:
- What caused the three returns
- Whether a route that reaches the person was created
- Whether the person has a way to reply if they're in trouble
- Whether the main document arrived
- Whether the same non-delivery can be prevented in future
That the handwriting on the cover slip is hard to read is, at most, something to improve next time.
It's no grounds for rejecting the fact that the main problem was solved.
5. When the "one-sided" criticism misses the mark
When you've given guidance in writing, you sometimes get told it's "one-sided."
But if the slip includes things like the following, it isn't one-sided:
- That it's addressed to the person
- That the document hasn't been arriving and that's causing trouble
- That if there's a bottleneck or circumstance, they're asked to let you know
- That if there's no problem, they can throw it away
- That there's a route for replying
This isn't a one-sided order.
It's a request to confirm why the document wasn't arriving.
In fact, it puts less burden on the other person than tracking someone down and talking face to face.
"Go and talk to them" sounds considerate at first.
But turned into an actual workflow, it looks like this:
- Identify who distributed the document
- Identify that person's department
- Go to that department to talk
- Confirm the circumstances with the person or those involved
- Organize what you heard on the HR side
- In the end, record it anyway
That's a lot of effort.
And because it's verbal, it can easily turn into a "you said / I never said" argument later.
On the other hand, if you set it up so that the person looks at the slip and replies if needed, the whole thing is settled with the person checking.
A record is kept.
There's no need to hunt for the people involved.
Being considerate doesn't necessarily mean talking in person.
Making it so the other person isn't confused, takes the least effort and leaves a record is also a form of consideration.
6. If you say "find the real cause," look at whether the setup gets closer to it
The words "find the real cause" are correct in themselves.
But right words alone mean nothing.
If you want to find the real cause, there are things you need to look at:
- The recipients on the past three occasions
- How the name was written
- How it was sent
- The reason for each return
- Whether the person received it on their end
- The address, department and internal mail route
- Who stopped it, and where
- At which stage it was returned
If you don't look at any of this and only say "maybe the handwriting is bad" or "talk to the person," that isn't root cause analysis.
And this time, the main document did arrive.
So at the very least, this fix improved deliverability.
What you should look at here is separating the resolved main problem from what's left over.
- Main problem: the document addressed to the person doesn't reach them
- Action: clearly mark it as addressed to them, add a way to reply and send it
- Result: the main document arrived
- Remaining issue: the handwritten part of the cover slip should be printed from next time
Just organize it like that.
Saying only "the handwriting is bad," "it sounds like a complaint" or "it's one-sided," without doing that, is shallow.
7. "Messy handwriting" is an improvement for next time, not the main problem
The comment that the handwriting is hard to read isn't completely meaningless.
From next time, just print it.
Use a standard template.
Type the addressee in as well.
But that's a secondary improvement point.
The main goal this time was to fix the non-delivery problem.
That main goal has been achieved.
So the right thing to say is this:
The document addressed to this person had been returned several times, so we used a slip to tell them it was addressed to them, and to ask them to reply to HR if there was any reason for the non-delivery or any bottleneck. As a result, the main document reached the person and the original non-delivery problem has been resolved. As for the handwritten part of the slip, we'll print it from next time.
With this framing, the main problem and the improvement point are separate.
A shallow manager can't make this separation.
So they use secondary improvement points to try to negate even the main result.
8. Even when you submit a proposal, a boss who can't decide starts a meeting from scratch
The same thing happens with proposals.
You look at a department's issues and think about what the bottleneck is.
For example, you realize that securing staff or recruiting is needed first.
You set priorities.
You build an outline in about 30 minutes.
You turn it into a proposal in about a day.
You submit it to your boss.
What should come next is one of the following:
- Adopt it
- Revise it
- Pass on it
- Try only part of it
- Decide who will run it
- Decide which departments to involve
- Decide what gets done by when
But a boss who can't decide can't make use of a proposal.
They leave the proposal on read.
They don't decide.
They don't set up a team.
Later, other people start saying similar things.
Then it becomes "let's all think about this from scratch."
This is a huge waste.
There's already a draft.
It's not the stage for thinking from scratch.
It's the stage for deciding whether to adopt the existing proposal, revise it, and who will do it.
What's needed here isn't a zero-based brainstorm, it's a decision-making meeting.
For example, you could say:
A proposal has already been submitted, so this time I'd like to use the meeting not for generating ideas from zero but for deciding whether to go ahead, the priorities and who covers what.
That is how it should have been done in the first place.
9. Ideas from fast thinkers tend to be taken lightly
People who can produce a proposal in a short time sometimes lose out.
They build an outline in 30 minutes.
They turn it into a document in a day.
They organize everything from the issue to the cause, the priorities and the proposed measures.
That's inherently very valuable.
But if the boss lacks the ability to recognize that value, it gets treated as just "some proposal that got sent over."
It looks like not much time was spent.
So it gets taken lightly.
In reality, the person has been watching the issues all along, has structured them, and has already worked things out in their head. That's the only reason it was fast.
It wasn't shallow because it was fast.
It was fast because they'd already been thinking about it.
A boss who can't understand this later starts the same conversation from the beginning with everyone.
And after a long time, they rediscover something close to the proposal that was already on the table.
For an organization, that's extremely wasteful.
10. A "catch-up meeting" steals time from the person who already did the thinking
A catch-up meeting is one where a group goes back and thinks from scratch about something that someone has already worked out and submitted.
Of course, discussing things with several people isn't bad in itself.
But once there's already a draft, the purpose of the meeting should change.
A bad meeting goes like this:
"First, let's all think about it from the beginning."
"What are the issues?"
"What's the problem?"
"What ideas do we have?"
A good meeting goes like this:
"Let's go through the proposal that's already out."
"Which points do we adopt?"
"Which points do we revise?"
"Which points need further checking?"
"Who does it, and by when?"
The latter gets far more done.
If someone has already done the thinking, use their draft.
There's no need to think it all over again.
When a boss can't do that, the people who can think end up exhausted.
"I've already thought that through."
"I've already submitted the materials."
"I got it to the point where all that's left is to decide."
"And we're starting a meeting from zero again?"
That's how it feels.
11. What people who define requirements need isn't an understanding boss, it's one who stays out of the way
For someone who defines requirements, the ideal boss doesn't have to be exceptional.
At a minimum, they just need to not get in the way.
For example, a boss who says things like this makes it much easier to work:
"Go ahead with Plan A."
"I'll push it through with the other departments myself."
"There's a risk just here, so add one sentence."
"Bring it to me when you need a decision."
"Let's pass on this one for now."
"This is a company-wide rollout, so let's settle the formal setup before we proceed."
Even just this helps a great deal.
On the other hand, a boss who says things like the following gets in the way:
"Why?"
"What are you going to do?"
"Where's the plan?"
"But by tomorrow."
"This one too, by tomorrow."
"This is a complaint, isn't it?"
"The handwriting's messy, isn't it?"
"I don't know the real cause."
"That's just how you are."
This doesn't move the work forward.
It muddies the work.
What people who define requirements want isn't excessive coaching.
It's decisions, responsibility and an attitude of not getting in the way.
12. Whether someone suits a management role depends not on their title but on their "conversion ability"
Management takes more than talking to the people above.
It takes the ability to convert the vague direction from above into requirements the team below can act on.
Specifically, abilities like these:
- Make the goal clear
- Bring out the undecided items
- Decide who makes the call
- Decide who does the work
- Set the priorities
- Set the deadlines
- Decide what to drop
- Send formal requests to other departments
- Get the people doing the work into a state where they can move
- Keep a record so nobody can flip later
A manager who can't do this conversion is less a boss than a machine for producing undefined work.
Meanwhile, someone without a title who can do this conversion is very strong in practice.
"Which will we go with, A, B or C?"
"That concern is already accounted for."
"Under those conditions, we'll go with A."
"These are the people who need to be notified."
"I just need you to decide."
"We'll handle the actual work on our side."
Someone who can say this has quite a lot of the ability of a manager or project manager.
It's not that they're unsuited to management.
They're just unsuited to the old-school kind of management that moves people through vague authority.
They may well be suited to project-manager-style management, which moves things forward through defining requirements, building agreement, managing risk and coordinating the people involved.
13. Ways to put it that you can say openly
Emotionally, you may think "annoying," "shallow" or "ridiculous."
But in practice, it's better not to say that outright.
Rephrasing it like this works for the open version.
Separate the main problem from secondary improvements
The main goal here, getting the document to the person, has been achieved, and the non-delivery problem is resolved. As for how the slip is filled out, we'll print it from next time as an improvement.
When you've already submitted a proposal
A proposal has already been submitted for this. Next time, rather than brainstorming from zero, I'd like you to decide whether to go ahead, the priorities and who covers what.
When a decision is needed
There are three options: A, B and C. Considering the impact and effort, I think A is the sensible choice. Once you decide, I'll proceed accordingly.
When extra requirements appear after the fact
Under the original instructions, I've completed up to X. If you also need Y, please make it clear as part of the scope and I'll proceed.
When told it's one-sided
This was not a one-sided request. It was a request to confirm, asking the person to reply if there are reasons or bottlenecks behind the non-delivery.
When told to talk it over in person
This can be settled by the person checking it themselves, and since the slip includes a way to reply, I handled it by paper first. If a verbal check is needed on top of that, I'll do it once the people and the points to confirm are clear.
14. Conclusion: don't let shallow criticism wipe out your main result
What matters at work is separating the main problem from the secondary improvement points.
If the main problem is solved, that's a result.
If there are secondary rough edges, those are things to fix next time.
Don't mix the two.
If the problem was a document that wasn't reaching the person, the main question is "does it arrive?"
If the main document arrived, the main problem is solved.
If the handwriting on the cover slip is hard to read, just print it next time.
If it's a proposal about a department's issues, the main question is "what's the bottleneck, and what do we tackle first?"
If the proposal has been submitted, the next step isn't thinking from scratch, it's deciding.
For people who define requirements, a shallow manager's criticism is a real nuisance.
But there's no need to be dragged along by that shallow criticism and deny your own results.
What to look at is the goal, the cause, the priorities, the conditions for carrying it out and the result.
Surface flaws can simply be improved.
The fact that you solved the main problem doesn't need to be erased.
Practical template collection
1. Log for handling a non-delivered document
The document addressed to this person had been returned several times, so we used a slip to tell them it was addressed to them, and to ask them to reply to HR if there was any reason for the non-delivery or any bottleneck.
As a result, the main document reached the person and the original non-delivery problem has been resolved.
As for the handwritten part of the slip, we'll print it from next time.
2. Separating the main problem from improvement points
The main goal here, X, has been completed.
As for Y, we'll handle it as an improvement from next time.
3. When you want an existing proposal to be used
A proposal has already been submitted, so this time I'd like you to decide whether to go ahead, the priorities and who covers what, rather than starting ideas from zero.
4. When you want your boss to decide among A, B and C
At this point, we could go with Plan A, B or C.
Considering the impact and effort, I think Plan A is the sensible choice.
If there are no problems, I'll proceed with Plan A.
5. To head off a boss's afterthoughts
Under the original instructions, I've completed up to X.
If you also need Y, please make it clear as part of the scope and I'll proceed.
6. When told to talk it over in person
This can be settled by the person checking it themselves, and since the slip includes a way to reply, I handled it by paper first.
If a verbal check is needed as well, please tell me who and what to confirm.
Related article ideas
- The no-authority trap: a workplace where you carry responsibility for results without any authority
- Don't hoard undefined work: how to clarify who decides and who covers what
- When a self-declared goal system breaks: the trap of setting your own targets
- An email template for preventing after-the-fact evaluations
- A defensive log for when your proposal gets left on read
- The moment your boss becomes a hindrance: when review turns into nitpicking
- The danger of undefined work in HR
- Why company-wide initiatives shouldn't become one person's personal goal
Notes for when this is published
This article contains content close to real experience, so it must be anonymized before publication.
- Don't name the company
- Don't name individuals
- Blur the department name
- Replace insider terms like "monkey" with "boss" or "manager"
- Generalize the type of document and the content of the work
- Remove specific dates
- While job hunting, treat it as an unpublished draft
- If publishing, frame it not as anger but as "work design," "defining requirements" and "the role of a manager"
In closing
If you can define requirements, don't lose sight of your own results because of shallow criticism.
If you solved the main problem, that's a result.
If there are secondary improvement points, fix them next time.
A boss's role isn't to pick at surface flaws and grill their subordinates.
It's to set the goal, decide the priorities, take responsibility and create a state in which the people doing the work can move.
A boss who can't do that is noise, not support.
And you shouldn't let noise erase your main result.
