Introduction
What really wears you out at work is not a boss who is simply strict.
If a boss is strict but makes clear decisions, sets priorities, states the goal and tells you where your responsibility starts and ends, you can still work with that.
The truly exhausting boss 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 comment in a chat
- Changes their position later
- Blows up one small flaw into blame for the whole job
- Ends up blaming the employee's personality
Under a boss like that, 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 look at the goal, the current situation, the cause, who is involved, the conditions for doing it, the risks and who makes the call. The boss only looks at surface impressions and a few rough edges, and criticizes those.
So the two of you end up talking on different levels.
You are talking about how the work is set up. The boss is talking about how it looks. You are solving the main problem. The boss is picking out small things to improve.
Let that gap pile up, and the boss stops being a source of support and becomes plain noise.
1. All you need from a boss is decisions, priorities and responsibility
Some people can move work forward mostly on their own.
For example, people who can do things like this:
- Sort out the goal
- Understand the current situation
- Find the bottleneck
- Lay out options as 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 quickly when needed
For someone who can do all this, the role they need from a boss is quite small.
What they really want from a boss is only this:
- Make the decision
- Set the priorities
- Formally push the request through to other departments
- Take responsibility
- Explain things to the people above and act as a shield
- Not add pointless afterthoughts
A boss who doesn't do these things is a real obstacle.
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 give no formal backing. They ask "how is it going?" but take no responsibility. And in the end they press you with "why did you do that?" or "why didn't you do this?"
That adds no value as a boss. It adds 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 problem comes after that.
Can they turn the vague things they heard from above into clear instructions the team below can act on?
After a meeting, they should break it down like this:
- What was decided
- What has not 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 is really ready to hand down to the team
Only when it is broken down this far can the people doing the work move.
But a manager who can't do this just throws the fuzziness from above straight down to the team.
"Apparently something starts in July." "Talk to S and get it moving." "Set up a meeting sometime this month." "Just do something for now." "How is it going?" "Why isn't this moving?"
This person attends the meetings but does not define requirements.
Talking 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 are good at defining requirements, using your boss as someone to consult can wear you down.
That's because consulting them tends to bring 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 help, who the contacts are and what the priority is.
This way, you narrow down what the boss has to think about.
You are not making your boss think from zero. You are making them choose. You are making them decide, and only decide. You are making them say where responsibility lies.
If you 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 small improvement points
The really annoying thing about shallow managers is that even when the main problem is solved, they pick at side 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 is addressed to the person themselves
- Print that it is for the training participant personally
- Also print the participant's department and name
- Add an arrow showing where to look
- Ask them, if they are 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 address of the cover slip is messy." "This is a complaint, isn't it?" "Isn't this one-sided?" "Talk to the person and find the real cause." "So what is 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 are 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 is no reason to reject the fact that the main problem was solved.
5. When the "one-sided" criticism misses the mark
When you have given instructions in writing, you sometimes get told it is "one-sided."
But if the slip includes things like the following, it is not one-sided:
- That it is addressed to the person
- That the document hasn't been arriving and that is causing trouble
- That if there is a bottleneck or some circumstance, they are asked to let you know
- That if there is no problem, they can throw it away
- That there is a way to reply
This is not a one-sided order. It is a request to find out 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:
- Find out who handed out the document
- Find out that person's department
- Go to that department to talk
- Check the circumstances with the person or those involved
- Organize what you heard on the HR side
- In the end, write it down anyway
That is a lot of effort. And because it is 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 reads the slip and replies if needed, the whole thing is settled with the person checking. A record is kept. There is no need to hunt for the people involved.
Being considerate doesn't always 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 delivery.
What you should look at here is separating the solved main problem from what is left.
- 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
- What's left: 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 something to improve next time, not the main problem
The comment that the handwriting is hard to read is not completely meaningless.
From next time, just print it. Use a standard template. Type the addressee in as well.
But that is a side improvement.
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 side improvement points to try to cancel out 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 hiring more staff 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 unanswered. 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 is already a draft. It is not the time to think from scratch. It is the time to decide whether to adopt the existing proposal, whether to revise it, and who will do it.
What is needed here is not a brainstorm from zero. It is a meeting to make a decision.
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 is very valuable.
But if the boss can't see 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 put them in order, and has already worked things out in their head. That is the only reason it was fast.
It wasn't shallow because it was fast. It was fast because they had 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 is 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 handed in.
Of course, discussing things with several people is not bad in itself.
But once there is 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 more checking?" "Who does it, and by when?"
The second kind gets far more done.
If someone has already done the thinking, use their draft. There is 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 handed in 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 is how it feels.
11. What people who define requirements need is not an understanding boss, but 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 start."
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 is not excessive coaching. It is 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 "translation skill"
Management takes more than talking to the people above.
It takes the ability to turn 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 translation is less a boss than a machine for producing undefined work.
Meanwhile, someone without a title who can do this translation 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 are unsuited to management. They are 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 have 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 on 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 is a result. If there are small 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 is the bottleneck, and what do we tackle first?" If the proposal has been submitted, the next step is not thinking from scratch. It is deciding.
For people who define requirements, a shallow manager's criticism is a real nuisance.
But there is 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 on 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 unanswered
- 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 slang 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 is a result. If there are secondary improvement points, fix them next time.
A boss's role is not to pick at surface flaws and grill their staff. It is 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.
