No department wanted to think about the whole picture.
Then they sat in a room with a deadline and no escape.
Oran said nothing. That was the point.
The CEO gave them a room, a whiteboard, and a deadline.
"Figure out what the audit report needs to contain.
You have until noon."
Then he left.
Four department heads. One Oran, in the corner, with a notebook.
Oran opened his notebook and wrote the date.
Then he put his pen down.
Then he waited.
It started the way these things always start.
Production spoke first.
They wanted the report to show output numbers.
Units produced. Units shipped. On-time delivery rate.
Numbers that make Production look like the engine of the company,
which it is,
which is also why they wanted to control which numbers appeared.
QA spoke second.
They wanted defect rates. Inspection pass/fail ratios.
Yield by product line. Corrective action response times.
Numbers that make QA look like the guardian of the company,
which it is,
which is also why they wanted to control which numbers appeared.
Engineering spoke third.
Process parameters. Spec compliance rates. Deviation reports.
Numbers that make Engineering look like the brain of the company,
which it is,
which is also why they wanted to control which numbers appeared.
Each department presented their version of the report.
Each version was a document that made their department look correct
and made it structurally impossible
to see anyone else's data in context.
For forty minutes, they argued.
Oran wrote in his notebook. He did not look up.
Then something happened.
Nobody remembers who said it.
This is important. This is why it worked.
Someone — it might have been QA, it might have been Engineering,
it definitely wasn't Manufacturing — said:
"What does the customer need to see?"
The room went quiet.
Not the hostile quiet of a meeting that's going badly.
The different quiet of a room that has just heard
the question it was supposed to be answering all along.
Slowly — without anyone declaring it,
without anyone taking credit for it,
without anyone formally proposing it —
they started building a table together.
What goes in each row.
One row per production batch.
What goes in each column.
Batch ID. Product code. Start time. End time. Shift.
Output quantity. Defect count. Defect type.
Process parameter: temperature. Process parameter: pressure.
Inspection result. Inspector ID. Inspection timestamp.
Material lot number. Material supplier.
What links the pieces together.
The batch ID appears in Manufacturing's records,
in QA's inspection log,
in Engineering's process data.
That's the key. That's always been the key.
Nobody had written it down before.
By 11:45, there was a proposal on the whiteboard.
One table. Every department's data. One shared structure.
Not perfect. Not complete.
But agreed.
Oran had filled three pages of notes.
He had said nothing.
After the meeting, the VP of Manufacturing stopped him in the hallway.
"You didn't say a single word in there."
Oran nodded.
"That was intentional, wasn't it."
It wasn't a question.
Oran thought about how to answer.
The honest answer was: yes.
Because Oran had learned something over two years of trying to get departments
to agree on data structures:
The moment IT proposes the schema,
it becomes IT's schema.
IT's problem. IT's fault when it's wrong.
IT's responsibility to defend in every meeting forever.
But if the departments build it —
if they argue their way to it,
if they write the column names on the whiteboard with their own hands —
it becomes their schema.
They own it.
They have to live with it.
They are much less likely to quietly ignore a system
they helped design.
The best system design meeting Oran ever attended
was the one where he didn't design anything.
He just made sure everyone was in the same room,
with the same deadline,
and no escape route.
That afternoon, Oran transcribed the whiteboard into a document.
He sent it to all four department heads with one line:
Please confirm this reflects the agreement from this morning's meeting.
Three confirmations came back within the hour.
The fourth came back the next morning,
with two small changes to column names
that didn't change anything structurally
but allowed the VP of Manufacturing to feel
that he had contributed.
Oran accepted both changes.
He updated the document.
He added a version number.
v1.0. Agreed. Dated.
Then he opened a new file and started writing the actual schema.
CREATE TABLE production_summary (
batch_id VARCHAR(50) PRIMARY KEY,
product_code VARCHAR(50) NOT NULL,
line_id VARCHAR(20) NOT NULL,
shift VARCHAR(20) NOT NULL,
start_time DATETIME NOT NULL,
end_time DATETIME,
output_qty INT,
defect_count INT,
defect_type VARCHAR(100),
process_temp DECIMAL(6,2),
process_pressure DECIMAL(6,2),
inspection_result VARCHAR(20),
inspector_id VARCHAR(50),
inspected_at DATETIME,
material_lot_no VARCHAR(50),
material_supplier VARCHAR(100)
);
He looked at the table for a long time.
Then he opened a new document and wrote at the top:
Problems with this table.
And started listing them.
The best system design meeting Oran ever attended
was the one where he didn't design anything.
He just made sure everyone was in the same room
with the same deadline and no escape route.
The table they built had seventeen problems.
He would discover them one by one
over the next two weeks.
But it was their table.
And that mattered more than he could explain.
Next: Ep5 — The Many-to-Many Disaster
The report table is agreed. No one is responsible for it.
One batch. Multiple inspection results.
One material lot. Multiple batches.
One spec. Two versions. No migration plan.
Oran discovers that a table everyone agreed on
and no one is responsible for
is not a table.
It is a beautiful, shared, distributed lie.
← Ep1: The Excel Republic
← Ep2: The Big Customer
← Ep3: The Auditor Arrives
Coding Cat Oran is a serialized fiction about building real production systems inside real companies.
The politics are real. The whiteboard is real. The cat is fictional.
The VP of Manufacturing is, unfortunately, also real.
By SysLayer · dev.to/syslayer