The boss called a company-wide meeting. Twenty minutes, conference room, Friday 2pm.
"Oran, you'll present the new system. Show everyone how it works."
Oran had three days to prepare. He felt ready. He'd rebuilt the permission layer, redesigned the inventory module, added the approval workflow. The system was solid.
He made a slide deck. Fifteen slides. Entity-relationship diagrams. SQL snippets. A flowchart of the permission check logic. Technical. Thorough. Accurate.
Friday came. 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. The GM.
Oran clicked to the first slide: an ER diagram with five tables and foreign key arrows.
The room went silent. Not the good kind.
He lost them in ninety seconds.
Duke leaned over to a coworker and whispered something. Ms. Lin politely took out her phone. The GM was nodding — but the way people nod when they want you to finish faster.
Oran made it through seven slides before 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 had spent weeks building the system. He could explain every table, every join, every constraint. But he couldn't say, in one sentence, what it meant for the people in this room.
That weekend, Oran sat at his kitchen table and rewrote everything.
Not the code. The words.
He realized that technical people think in structure — tables, relationships, data flow. But everyone else thinks in outcomes — what can I do, what changes for me, what problems go away.
He needed to translate.
He made a new deck. Three slides.
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, every change, every 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.
Monday. Oran presented again. Same room. Same people.
This time, Duke nodded — the real kind. Ms. Lin put her phone away. The sales team asked questions. Good questions. "Can I get a weekly report of my orders?" "Can we add a read-only role for the auditor who comes quarterly?"
The GM said, "This is what I wanted to hear last week."
Oran learned something that day that wasn't in any course he'd bought:
The system doesn't exist until people understand it.
You can build the most elegant schema in the world. If you can't explain it to Duke in one sentence, it doesn't matter.
And here's the thing — this skill made Oran a better developer too.
When he forced himself to describe the permission system as "you see only what's relevant to your job," he immediately spotted a gap in his own design. He hadn't built a dashboard that showed users their own access. He'd built the backend but forgot the human-facing layer.
Translating tech into human language isn't dumbing it down. It's a design review in disguise.
Every time you explain a feature in plain words and it sounds confusing — that's a sign the feature itself is confused.
Oran went back to his desk and added three things to his system:
- A "My Access" page where users see their own permissions in plain language
- A role summary page for department heads — no SQL, just a clean table
- Notification emails when access changes: "You've been granted the Warehouse Staff role by Duke on March 15."
Small features. Huge difference. Because now the system spoke human.
Next episode: Six months later. The GM asks Oran to lead the next project. Oran isn't just the developer anymore — he's the one who decides what gets built. The orange cat grows 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.
Top comments (0)