In this article
Computer science programmes teach algorithms. Bootcamps teach frameworks. Almost nobody teaches you to write the process before the program.
That gap costs teams money. I’ve paid it myself — building the wrong thing efficiently, twice, because the spec lived in someone’s head and the code lived in the repo and never the twain did meet.
An SOP is a spec humans can read
When I say SOP, I don’t mean a 40-page corporate manual. I mean a clear answer to:
- What triggers this workflow?
- What are the steps, in order?
- Who owns each step?
- What does done look like?
- What happens when something fails?
If you can’t write that in plain language, you’re not ready to name your functions yet.
Why engineers resist it
It feels unglamorous. It doesn’t show up in a portfolio screenshot. It doesn’t spark dopamine like a green test suite.
But code without process is a photograph of a moving target. The moment the team changes, the tool drifts — unless the process was captured first.
Where this habit pays off
Client projects with recurring workflows. Internal tools used by more than one person. Anything where “we’ll figure it out in Slack” has been the spec for too long.
The SOP becomes the contract between product, ops, and engineering. Code implements it. Reviews reference it. Onboarding uses it.
Slowness at the start is often speed at the end — because you don’t rebuild the same misunderstanding twice.
My default now
SOP first, even rough. Review with the people who do the work — not just the people who approve budgets. Then code once, with intent.
Nobody taught me this in school. I learned it from breaking things in production and writing the doc I wished had existed on day one.
