Write the SOP before you have to do it twice

Two standard operating procedures and a forty-six thousand row report, and why documentation is how a small team scales.

I wrote two standard operating procedures this week, and I now think of that as the highest-leverage thing a lean IT team can do.

The first covered new-user provisioning end to end: create the account in the directory, sync it, enable the identity provider, assign the right groups and licenses, and set up each business application the person needs. The second covered the laptop exit protocol for departing staff, including when to wipe versus reset and how to check HR's replacement request before touching hardware.

Neither SOP existed before. Both described things I had been doing from memory. The moment I wrote them down, the process stopped living in my head and started living somewhere a colleague could follow, or the next person in my seat could follow, or I could follow on a day I was tired and rushed.

I also built a large supplier reporting workbook off the ERP and reporting tools, about forty-six thousand rows, and set it on a recurring refresh. That was a different kind of documentation: turning a one-time request into a repeatable report nobody had to rebuild by hand.

The honestly important number that week was forty-five tickets closed, up fifty percent. But the SOPs are what let me close that many without dropping a step.

The rule I use now: if I am about to do something for the second time, I write it down as if I will have to hand it to someone else, because eventually I will. On a small team there is no documentation department. The person doing the work is the person who has to write the runbook, and the team only scales when that actually happens.

Write the SOP before the third time. Then follow it instead of reinventing it.

← All writing · Portfolio