Work Philosophy

I believe the best documentation is built together.

Technical writing isn’t a solitary craft. The clearest, most useful documentation comes from genuine partnership with engineers who know the system, PMs who understand the user, and stakeholders who see the bigger picture.

I’ve found that my best work happens when I’m embedded in a team, not adjacent to it. When I understand not just what to document, but why it matters to the people building it and the people using it.

Clarity is a form of respect.

When someone reads documentation I’ve written, they’re giving me their time and trust. They have a problem to solve. My job is to respect that by being clear, concise, and genuinely helpful. Not to show off technical knowledge, but to transfer it.

This means cutting jargon when plain language works. It means anticipating questions before they’re asked. It means caring deeply about the reader’s experience, not just the technical accuracy.

What I bring to a team

Deep listening
I ask questions until I truly understand the technology, the user need, and the context around both.

Bridge-building
I translate between technical and non-technical audiences, finding the language that works for everyone.

Genuine investment
I care about the success of the product and the people I work with, not just the docs I produce.

Calm in complexity
ML and AI systems are inherently complex. I’m comfortable sitting with ambiguity until clarity emerges.

The relationships matter as much as the work.

Some of my most meaningful professional experiences have been the friendships built through shared goals: traveling to conferences together, solving hard problems over coffee, celebrating launches as a team.

Work friends through the years!