From SOPs to Workflows
I was still in uniform, not far from discharging, when a soldier tracked me down through the grapevine. He was deployed, he had a piece of kit in front of him, and he'd heard that I'd been one of the first people to actually use it.
I hadn't just used it. I'd bent it — pushed it well past what it was designed for, figured out what configs worked and what would get you into trouble, and learned all of it through the kind of trial and error that only makes sense when nobody has written the manual yet. So when this soldier called, I walked him through everything. The scenarios. The edge cases. What to try and what to avoid.
That conversation, from what I understand, became the foundation of the Standard Operating Procedure for that piece of kit. It went into formal doctrine. Soldiers I'd never met were following a process that started because I'd pushed a system beyond its limits and bothered to remember what I learned.
I didn't know it at the time, but that was the pattern for the next twenty-five years.
The Australian Army runs on documentation. (Like most militaries, I imagine.) Everything has a Standard Operating Procedure (SOP for short), and if it doesn't, you write one and it becomes doctrine. It sounds bureaucratic — and in some ways it is — but there's a reason for it. When things go sideways, and they do, people need to be able to act without stopping to think through every step from scratch. The SOP is what lets that happen. It's institutional memory made executable.
When I left the military in 2005 and took my first civilian IT role — IT Manager at an agricultural equipment dealership, taking over from the company accountant who'd been holding it together with consultancy help and optimism — I discovered that the civilian world doesn't really work like this.
I won't say I went straight into oh-shit mode, but it wasn't far from it.
Five-plus years of no proactive maintenance on anything. PCs running outdated everything. No standard build, no group policies, no consistency. I started where anyone would: created a Standard Operating Environment, got Windows updates actually deploying, put some order around the basics. It wasn't glamorous work but it was necessary. You can't build on chaos.
The budget thing was also a rude awakening. In the military, when you needed something — servers, hardware, kit — you got it. You didn't have to justify it or cost it or wait for a sign-off cycle. Someone up the chain probably did, but where I was stationed, the pockets were deep. In the civilian world, I was suddenly writing business cases for things I considered obvious. That was a different kind of discipline.
But as I got deeper into the role, something familiar started showing up. I got access to the SQL Server behind the Unix ERP and started building digital reports for the parts department. No more dot matrix printouts and terminal screen menus. Repeatable, on-demand, done.
Then I went after the special tools — expensive, single-purpose kit that every branch owned one of, most of which sat on a shelf most of the time. I audited and catalogued them. When a job needed a tool a branch didn't have, you made a call and shifted it from a branch that did, instead of buying another. Small business margins are thin. Death by a thousand cuts is real. Two or three days of cataloguing for ten grand a year off tool purchases — the maths wasn't hard.
Then I found SharePoint 2003 and thought: there's something here. Everyone was building intranets with it. I could already see past the intranet — there was a process platform hiding in there if you squinted.
After two years at the dealership I wanted more, and I wanted to zero in on SharePoint. Up to that point I'd only worked with trial installs and the free portal version. But coming from a Lotus Domino background in the military, I could see where Microsoft was trying to take it. It was good. A lot was still to be desired. But the direction was right.
So I joined a regional healthcare provider as a SharePoint Administrator. The SharePoint work is what got me hired. It's not the work I remember most.
There was a long backlog of low-visibility infrastructure work that hadn't bubbled up the priority list. The antivirus servers weren't co-located with the clients they updated, so a few thousand PCs were dragging update packages across the network all day, every day. H: drive storage was filling up on a predictable cycle. Server names were inconsistent. SQL maintenance was ad hoc. None of it was hard to fix. None of it was on anyone's roadmap either.
So I worked through the unsexy list. Sorted the antivirus topology so updates weren't crossing the whole network every time. Wrote scripts to manage H: drive consumption. Standardised the server names. Built SQL maintenance routines that ran themselves. None of it had my name on it. The network got faster, the disks stopped filling, and the SQL boxes stopped throwing the same alerts every week.
Eventually the org made the call to go with a non-SharePoint platform for their next-generation intranet. I was placing my bets on SharePoint, so I moved on.
Then a state water utility. Eighteen months. Well over a hundred processes — some small, some significant.
The one I think about most was a board meeting management system. Anyone in the organisation could present to the board, but the protocols were strict: specific templates, multiple approvers, multiple revision cycles, and at the end, coordinating distribution across board members and executives, some of whom wanted printed papers mailed to their homes and some who preferred email. The whole thing took about two months to build part-time.
It saved in excess of two hundred hours a month across all roles involved. Conservative estimate.
That wasn't the highest ROI project I ever delivered. But it was the first time I understood what this work actually was. It wasn't IT. It wasn't SharePoint administration. It wasn't workflow configuration. It was the same thing I'd been doing since the Signal Corps — taking a messy, inconsistent, human process, understanding it properly, and making it executable. Turning tribal knowledge into something repeatable. Writing the SOP, except now the SOP ran itself.
I became a Nintex customer in 2008. A few years later, Nintex came to me and asked if I wanted to interview for their first evangelist and presales role across APAC and EMEA. The tools had changed by then — SharePoint had grown up, Nintex had replaced what Visual Studio used to require — but the instinct was the same one I'd had in uniform: push a system past its limits and write down what worked.
The best processes don't get noticed. They just work. Behind every one of them is someone who looked at the mess and decided to do something about it.
For me, that started in the Army. It hasn't stopped since.