Coding Cat Oran Ep4, Speaking Human

Source: Dev.to

The First Presentation

The boss called a company‑wide meeting: twenty minutes, conference room, Friday 2 pm.

“Oran, you’ll present the new system. Show everyone how it works.”

Oran had three days to prepare. He’d rebuilt the permission layer, redesigned the inventory module, and added an approval workflow. He created a fifteen‑slide deck filled with entity‑relationship diagrams, SQL snippets, and a flowchart of the permission‑check logic—technical, thorough, accurate.

Friday arrived. Oran stood in front of the room: Duke and the warehouse crew in the back row, Ms. Lin in the front, the factory floor supervisor, the sales team, and the GM.

He clicked to the first slide: an ER diagram with five tables and foreign‑key arrows. The room went silent—not the good kind. After seven slides, the GM raised his hand:

“Oran. I believe you. The system works. But I have one question.”
“Yes?”
“Can you tell me, in plain words, what this system does for us? Not how it’s built. What it does.”

Oran opened his mouth, then closed it. He could explain every table, join, and constraint, but not a single sentence that resonated with the audience.

The Revised Deck

That weekend Oran rewrote everything—not the code, the words. He realized technical people think in structure; everyone else thinks in outcomes.

He created a new three‑slide deck:

Slide 1 – What changes for you
“You’ll log in and see only what’s relevant to your job. Warehouse sees inventory. Finance sees billing. No clutter, no confusion.”

Slide 2 – What you can trust
“Every approval, change, and access grant is recorded. If you ever need to ask ‘who did this and when’—the system has the answer.”

Slide 3 – What you control
“New hire? Your department head assigns them a role. No ticket to IT. They get exactly the access they need—nothing more, nothing less.”

No ER diagrams. No SQL. No arrows.

The Second Presentation

Monday, Oran presented again to the same room. This time Duke nodded genuinely, Ms. Lin put her phone away, and the sales team asked practical questions:

• “Can I get a weekly report of my orders?”
• “Can we add a read‑only role for the quarterly auditor?”

The GM said, “This is what I wanted to hear last week.”

Oran learned a lesson that wasn’t in any course:

The system doesn’t exist until people understand it.
You can build the most elegant schema, but if you can’t explain it in one sentence, it doesn’t matter.

Translating tech into human language isn’t “dumbing it down.” It’s a design review in disguise. When an explanation feels confusing, the feature itself is likely confused.

Immediate Improvements

Motivated by the feedback, Oran added three small but impactful features:

• A “My Access” page where users see their permissions in plain language.
• A role summary page for department heads—no SQL, just a clean table.
• Notification emails when access changes, e.g., “You’ve been granted the Warehouse Staff role by Duke on March 15.”

These tiny additions made a huge difference because now the system spoke human.

Next Episode

Six months later, the GM asked Oran to lead the next project. He’s no longer just a developer; he decides what gets built. The orange cat has grown into a role nobody hired him for.

Oran’s journey is brought to you by SysLayer — practical backend guides for developers who build real products.