The best operations work is invisible, which is the problem

A developer's work accumulates in public: repositories, commits, shipped features with their name attached. An operations person's best work is a negative space. The payroll that never failed. The supplier crisis that never reached the CEO. The onboarding that stopped losing new hires in week one. Done perfectly, it produces no artefact at all, and artefact-free work is invisible to every evidence-shaped process, including, until recently, ours.

So ops people write CVs full of responsibility verbs. Managed, oversaw, coordinated, streamlined. The words are true and weightless, indistinguishable from the same words written by someone who did it badly. Hiring for operations becomes an interview-charisma contest precisely because the paper signal carries nothing, and the quiet person who actually kept the machine running loses to the confident narrator who stood near it.

The work has a shape, even when it has no artefact

Invisible work becomes visible the moment someone describes its mechanism. Not managed supplier relationships, but: four suppliers, one of them failing every quarter, and here is the scoring system I built to catch the failures early, and here is what stopped happening after. The before, the mechanism, the after. Anyone who really did the work can describe its mechanism in concrete detail, and almost no one who did not can fake that detail under their own name in public.

Describing is publishing

That description is a project here. Our onboarding does not ask for your repositories first; its opening question is what would break if you went away for a month, which is the operations question. Write what would break, how you kept it from breaking, what it looked like when you arrived and when you finished. Tag it. Publish it. The negative space becomes a page, and the page is searchable by companies who have learned, usually expensively, what good operations is worth.