We needed an intern dashboard. Tasks, progress, handoffs, visibility for the team lead. The kind of thing that sounds straightforward until you ask: how does this actually work today?
Silence. Then three different answers from three people. None wrong. None complete.
That was the real project — not the dashboard. The dashboard was just where the broken process became visible.
Everyone wanted code. I wanted clarity.
The instinct on projects like this is to open Figma or the IDE and start building. Screens feel like progress. SOPs feel like bureaucracy.
I’ve learned the opposite. Screens without a process become shelfware. A dashboard nobody updates. Status fields everyone ignores. A tool the team tolerates instead of trusts.
So I stopped. I opened a doc and wrote the SOP first.
What the SOP actually captured
Not corporate fluff. Operational truth:
- Who creates a task, and when?
- What states can a task be in — and who moves it?
- What happens when an intern is blocked?
- What does “done” mean for each task type?
- Who gets notified, through which channel, with what urgency?
Writing this took two days. It surfaced three edge cases we’d have discovered in production — after someone had already built the wrong workflow into the database schema.
Then I wrote code — once
With the SOP as source of truth, the build was almost boring. States mapped cleanly. Permissions made sense. Notifications weren’t guessed — they were specified.
The team didn’t adopt it because I asked nicely. They adopted it because it matched how they already worked — just clearer, faster, and visible to everyone.
Documentation isn’t the thing you write after shipping. It’s the thing that prevents you from shipping the wrong thing.
The habit I kept
Now, on any internal tool or client workflow with more than two people involved, SOP first. Even a rough one. Even if it feels slow.
Because the intern dashboard taught me something I keep relearning: most “technical” problems are process problems wearing a UI.
