From writing to content operations

Most technical writers stumble into operations. You’re hired to write documentation. Your team grows. Someone needs to manage the style guide. Someone needs to decide who owns what. Someone needs to decide whether documentation lives in Confluence or Google Docs or Notion or all three at once. That someone is you.

By year five, you’re not writing anymore. You’re managing Trello boards. You’re trying to enforce Asana task templates that nobody uses. You’re sitting in meetings about whether to migrate SharePoint or consolidate Notion workspaces. You’re the only person who knows how the documentation actually flows. And you’re still called a “writer.”

This happened to me. It took me a decade to see the pattern.

I didn’t choose operations. Operations chose me.

I started as a technical writer at a SaaS company, then Docker, then a systems integrator. Each time, the same arc: hire a writer, documentation grows, nobody owns the strategy, bureaucracy hardens, hiring takes weeks because onboarding is broken, and somehow the writer is responsible for fixing all of it.

Except I eventually realized — the problem was never the tools. Trello doesn’t fail because it’s bad at project management. SharePoint doesn’t fail because it’s bad at collaboration. Confluence doesn’t collapse because it’s unintuitive. They fail because nobody decided who owns what, nobody established approval gates, nobody carved out time to kill the stale pages.

The tools were where the dysfunction was visible. The actual problem lived in governance.

Once I understood that, I could actually fix things.

I learned how to design ownership models that don’t depend on one person remembering everything. I learned how to set approval gates that slow down chaos without strangling velocity. I built frameworks for deciding what goes where — and more importantly, what doesn’t go anywhere because it’s dead weight.

I worked with federal contractors who had to audit their documentation for compliance. I worked with SaaS companies spinning up customer success content at scale. I worked with systems integrators who had to unify documentation across 15 different client implementations. I watched what works and what collapses under pressure.

That’s not consultant experience. That’s the difference between seeing patterns at fifty companies and making the same mistakes over and over at one.

Recruiters and hiring managers, this is why I matter to you: If you hire someone who knows how to write, you get better documentation. If you hire someone who understands the infrastructure underneath documentation — who’s actually built governance models, consolidated tool ecosystems, and designed decision-making processes that scale — you get someone who can unblock your entire organization. Not someday. In weeks.

I’m not looking for a job title that says “writer” anymore. The work I do now is diagnostic. It’s infrastructure. It’s fixing the systems underneath the systems. And if that’s the person you need, we should talk.