Throughout my career, I’ve created help materials that empower users to make the most of complex enterprise solutions. My role as a technical writer is essentially one of translation: translating features into user processes, translating developer jargon into text understood by anyone, translating business needs into user processes.

I’ve always worked on enterprise tools. If my materials are hard to understand, users aren’t able to be productive at work. I take this responsibility seriously: I’m passionate about solving users’ problems.

Technical writing shouldn’t be about helping someone use a badly designed tool. I’m involved in the whole development process, reading specs, testing features, pointing out design decisions that make features hard to use, and filing enhancement requests.


My first role involved transitioning a set of per-customer training guides into a single help guide for all customers, making the documentation process scaleable. This task set the tone for my career: documentation should be helpful for users, but scaleable for the team creating it.

Later, I took up a project to learn Ruby and implement various scripts to automate parts of my job. I also saw the value of a well-rounded writing team with even basic coding skills. The time that a team like this saves by automating tasks translates into new, exciting content that we can create for users.

Recently, I had the opportunity to be the first tech writer on a team. In addition to crafting the first style guide and much of the documentation, I also created my first UI Terminology Guide. I’ve come to beleive that any software project should have one of these: it guides all text that we put into our application, ensuring that it is clear, concise, and consistent.

What’s Next

Currently, I’m pushing my own boundaries in my first management role at Veeva. In balancing a lot of disparate responsibilities, I’ve found that qualities that served me well as an individual contributor can hobble me as a manager. So, I’m learning and developing new “soft” skills for this next phase of my career.

I’m also looking at ways that I can grow my skills in new directions: speaking at conferences, contributing documentation to open source projects, and diving deeper into coding.

I’m almost a decade into my career, but I’m happy to say that there is so much I don’t know yet!

© Cory Williamson–Cardneau      2017