Some ways of asking for work are quietly dangerous.
Just send me something like this every month.
That's the one.
It looks like a perfectly normal request.
There's last month's sample. There's past data. You can sort of tell the format.
So whoever does the work follows the vibe and handles it every month.
But that "like this" tends to blow up later.
Why isn't this field in there?
Are you sure it's okay to send it now?
Mr. So-and-so said it should be different, though?
It used to be there, didn't it?
And from the worker's side, the reaction is:
How should I know?
Tell me the fields, the cutoff date and the due date up front.
This isn't just a gripe.
It's a structural problem that shows up again and again in routine work.
"Like this" is not a spec
"Just send it monthly like this" is not a spec.
It's a sample.
A vibe.
A habit from the past.
A trial run.
If you really want it treated as a spec, you need to settle at least the following:
- Fields that must be included
- Fields that are optional
- Which source data to use
- As of which date the data should be pulled
- On which day it gets submitted
- Who decides when something changes
- Rules for adding requests that come in from other departments
If none of that is decided, the person doing the work can only go off past samples and guess, "probably like this."
So when someone later says,
Isn't this missing?
it isn't necessarily the worker's mistake.
There simply was no spec.
If nobody said anything for three months, the process was tacitly accepted
What matters here is the case where it has actually run this way for months.
Say you took over the job and, for three months, submitted the employee roster at the start of each month.
Nobody ever told you "the timing is wrong," "this field is missing," or "this cutoff date doesn't work for us."
Then suddenly someone says,
We're issuing it on the 16th, so are you sure it's okay to send it on the 1st, right now?
That can't be written off as a past mistake.
After all, the roster was accepted that way for three months.
Of course, things change along the way. Another department may start using it differently, someone may realize job titles are needed, or the issue timing may need a second look.
There's nothing wrong with that.
But that's "a new requirement has come up."
It's not "the previous person got it wrong."
If you took it without a word for three months, the process was at least tacitly accepted on the ground.
If you then change the required fields or the submission timing, the thing to do is update the spec, not blame anyone.
The problem isn't that job titles are missing
Take a monthly employee roster, for example.
Another department says,
We might not be able to tell without job titles.
So the boss or the person in charge asks the worker,
You didn't put job titles in this?
Right there, the conversation has already drifted.
The problem isn't that job titles weren't included.
The problem is that nobody defined job titles as a required field.
So the conversation should simply go like this:
I see, so job titles are needed from now on.
Then I'll add them as a field starting next time.
And that's the end of it.
We learned an undefined field is needed.
So we add it to the spec going forward.
That's all there is to it.
Don't turn a new request into a "spot the mistake" game
In any job, you sometimes find out later that a field is needed.
There's nothing wrong with that.
It's perfectly normal for another department to try the data out and realize,
Job titles would make it easier to read.
It's hard to check without knowing the cutoff date.
It'd help to have this field, too.
So the right response is simple:
We'll add it from next time.
If you need it for this round too, I'll send a revised version.
From now on, this field will be standard.
That's enough.
But in workplaces that are bad at solving problems, this somehow gets turned into a "spot the mistake" game.
Why isn't it in there?
It was there before.
Who said it was different?
Are you saying that contradicts what we said earlier?
So you're saying the person who pointed it out was wrong?
No.
That's the wrong question.
If a new request comes in, add it to the spec.
If something is found to be missing, make it standard from next time.
If the cutoff date is vague, set one.
That's all.
You don't need to say "the person who pointed it out was wrong."
You don't need to say "the worker made a mistake."
You don't need to say "the previous person was at fault."
All you need to do is decide how it works from now on.
If it isn't decided, just decide it
The most important point in all of this is:
If it isn't decided, just decide it.
Nobody has decided whether to include job titles.
Then decide whether to include them.
Nobody has decided whether to send data as of the 1st or the data right before the 16th issue.
Then set the cutoff date.
Nobody has decided which day of the month it's due.
Then set the due date.
Nobody has decided how to handle added requests from other departments.
Then set a rule for how to fold them in.
That's it.
And if you turn it into
Who said that?
Does this contradict what was said before?
Is this a mistake?
Why wasn't it included?
Whose understanding was wrong?
it instantly becomes a pointless meeting.
That's not problem solving.
It's leaving the undefined part undefined and just hunting for somewhere to park the blame.
If you're going to dig through old files, decide why first
In situations like this, some people start digging through past documents.
What did the old rosters look like?
Did they include job titles before?
Since when has it been missing?
Which person's tenure did it change in?
Of course, looking at past documents isn't bad in itself.
It makes sense if the goal is
to decide the standard fields from now on,
to understand how things differ from before,
or to check what other departments were looking at.
But if the goal becomes
who left it out,
who got it wrong,
whether the person who pointed it out is right,
whether the worker made a mistake,
it's almost pointless.
That isn't improving work. It's mining for someone to blame.
Digging into the past won't tell you whether this month's roster needs job titles.
Digging into the past won't tell you whether the cutoff date is the 1st or the 16th.
Digging into the past won't magically produce a rule for due dates.
Reviewing the past is useful as material for deciding the spec.
Using it to find the culprit is a waste.
Unless you separate the two, routine work stays fruitless forever.
Turn it into a "who's to blame" trial and work grinds to a halt
In this kind of workplace, a trial starts the moment a problem comes up.
Who said that?
What did the previous person do?
Was the person who pointed it out wrong?
Did the worker fail to check?
Whose understanding is correct?
Of course, for a serious accident or a legal violation, finding the cause is necessary.
But for routine work like monthly roster fields, where all that happened is that an extra field came up, that kind of trial isn't needed.
All that's needed is this one line:
Then from now on, we'll make job titles a standard field.
That's enough.
If needed, you can follow up with:
Is the cutoff date the 1st of each month?
For the roster issued on the 16th, what's the monthly submission deadline?
That's the actual work.
Deciding "what do we do from next time" is 100 times faster than hunting for "who's at fault."
Vibe-based requirements invite after-the-fact grading
What's scary about "just do it like this" is that it lets people grade the work afterward.
There's no clear list of fields at the start.
No cutoff date.
The due date is fuzzy.
The source data keeps changing.
Yet the deliverable still arrives every month.
So whoever looks at it later can say,
This field is missing.
It's different from before.
Is it really okay to send it now?
Somebody else said it should be different.
But that's grading only the deliverable, and ignoring the vagueness at the time of the request.
If it had been settled at the start, like this:
The employee roster must include name, department, job title and hire date.
The data cutoff is the 1st of each month.
The due date is the 10th of each month.
It feeds into the roster issued on the 16th.
then it would be easy.
If the output deviated from that spec, you could call it a work error.
But if all that was said at the start was "like this," treating something as required after the fact is risky.
That isn't a spec violation. It's a spec that was never set.
If the source data changes, you need a cutoff date or results will drift
For something like a roster, the source data changes.
Job titles change.
Departments change.
People join and leave.
Names and spellings change.
The information differs depending on when you issue it.
That's exactly why "as of which date?" matters.
Do you send data as of the 1st?
The data right before the 16th issue?
The data from the moment the request arrived?
The data after personnel announcements have been reflected?
If that isn't decided, and someone asks,
Are you sure it's okay to send it now, on the 1st?
the worker is stuck.
That's not a question of the worker's judgment.
The cutoff date simply hasn't been decided.
Work without a cutoff date drifts every time.
Instead of getting angry after it drifts, decide the cutoff date first.
To improve it, fix the fields, the cutoff date and the due date
To stabilize this kind of work, you don't need a big reform.
Just deciding these three things makes life much easier.
1. Fields
For example:
- Name
- Department
- Job title
- Employee number
- Hire date
- Notes, as needed
Which ones are required?
Which are optional?
Which fields do other departments need in order to use it?
Decide that.
2. Cutoff date
For example:
- As of the 1st of each month
- As of the 15th of each month
- As of the business day before the issue date
- After personnel announcements have been reflected
If the source data changes, results will always be off without a cutoff date.
3. Due date
For example:
- Submit by the 10th of each month
- Because it's used for the roster issued on the 16th, the monthly deadline is the Xth
- If that day is a holiday, the previous business day
If the due date is vague, the "is it okay to send now?" question comes up every time.
In other words, what's needed isn't grit.
It's a spec.
Replies you can actually use at work
When a request to add a field comes in
I see, so job titles are needed from now on.
Then I'll add them as a field starting next time.
If you need them for this round too, I'll redo it with job titles.
When nobody said anything about three months of the same process
For the past three months we've been submitting at the start of the month, and no issues were raised.
If you'd like to change the cutoff date or submission timing to fit the roster issued on the 16th, I'd suggest deciding on it as the standard from next time.
When the required fields were vague
Until now there was no specific list of required fields, so I've been working from the sample.
From now on I'll include job titles.
When asked about the issue timing
For the roster issued on the 16th, it would reduce misunderstandings if we decided which date's data to use.
Could I confirm whether data as of the 1st each month is fine, or whether it should be data from right before the issue date?
When it looks like it's turning into a discussion of who was wrong
I don't think anyone was wrong. My understanding is that the fields and cutoff date just hadn't been clearly set.
I'd suggest deciding, as the new standard, whether to include job titles.
The key to these replies is not getting dragged into the blame game.
Bring it back from "who's at fault" to "what do we do from next time."
Wrap-up: if you ask by vibe, don't grade afterward
"Just send it monthly like this" is a handy phrase.
But if you run things on it as is, it's easy to end up in a dispute later.
The fields aren't decided.
The cutoff date isn't decided.
The due date isn't decided.
The source data changes.
Other departments' requests change.
And yet it can be accepted without a word for three months.
In that state, it's risky to come back later and blame someone with "you didn't put this in?"
If a needed field turns up, add it.
If the cutoff date is vague, decide it.
If the due date is vague, fix it.
That's all there is to it.
When you find something undefined, don't hunt for who's responsible. Define the spec.
That's the job.
When something that should end with
A new request came in.
OK, I'll add it.
gets turned into
Who's at fault?
Is it a mistake?
Does it contradict what was said before?
Are you saying the person who pointed it out was wrong?
don't go along with it.
That's not work. That's a kangaroo court.
What routine work needs isn't a loud, intimidating tone or blame-mining.
It's fields, a cutoff date and a due date, written down.
