Technical Communicator

 

Ten years of experience effecting change through documentation, processes, and training.

One word at a time.

I create accurate, usable, and compliant content through effective collaboration.

Curious to hear more?

 

People call me the Subject Matter Expert (SME) whisperer.

Because internal stakeholders are our customers, too.

All good documentation or learning begins with a deep dive to understand its purpose, audience, optimal modality, and more.

I take technical communication to the next level by looking at it through a lens of stakeholder and end-user advocacy.

eLearning, instructor-led training, 300-page manual, standard operating procedure (SOP) …

You name it, I can create it.

 

How I Help

Because all good things come in threes, right?

I stick to a few things I excel at:

 

Collaborating

✦ People Leading
✦ Project Management
✦ Process Improvement
✦ Problem Solving
✦ Vendor Management

Learning

✦ Instructional Design
✦ Adult Learning
✦ Audience Analysis
✦ Adobe Captivate
✦ User-Centered Design

Writing

✦ Technical Writing
✦ Technical Editing
✦ Document Design
✦ SME Collaboration
✦ User Advocacy

 

Portfolio

 

FAQs

First things first! Many people want to know about my background in technical writing (okay, they ask what a technical writer is …). So here’s the scoop!

+ Wait, are you a technical writer or a learning designer? Aren't they two different things?

I consider myself amphibious, if you will! Technical writing and instructional design are grounded in such similar methodologies (user-centered design and ADDIE, as examples), so my education and experience as a technical communicator lend itself to both industries and job functions.

+ What does a basic day as a technical writer or learning designer consist of?

Depending on the type of technical writer or learning designer you are and where you work, it varies. For me, my typical day consists of project management (a lot of it), collaborating and communicating with my SMEs, creating design documents, developing training, technical editing, editing and proofing my team’s work, and managing a large portfolio of pilot training curricula.

+ What kinds of technical documents have you worked on?

The most common are: manuals, policies and procedures, standard operating procedures (SOPs), and technical training. Again, it varies. As an example, at one time, I worked on SOPs, technical documents and PowerPoints that describe chemical engineering processes in the food industry, training materials for Quality Assurance, a technical writing class for engineers, a regulation database and traceability matrix, a regulation gap assessment, and a trailer operator’s manual.

+ What are your tips for writing a good email or memo?

Technical writing should always be written with the end user in mind. While writing an email, I ask and answer the following questions (these also apply to any type of content):

  • Who’s your audience? In this case, who is the recipient of your email?

    • Not to mention your unintended audience. The forward and reply (all) features are powerful. Always be aware that your written words may be sent to someone else.

  • What do you want the user to do after reading the email? Are there action items?

    • If so, address this.

  • What information do you need to provide the user with to prevent them from having to search for information and accommodate themselves?

    • For example: If you’re asking someone (client, coworker, subject matter expert (SME), etc.) to decide between two graphics you created for a manual, attaching a 75-page document and asking them to navigate to a specific page isn’t the most efficient use of their time. In the email, I would attach graphics for them to review so they don’t have to dig into the abyss of their computer to find the file or hunt within the manual to find the figures I’m referring to.

    • In those instances, when I’m asking someone to do something, I try to make it as easy as possible. My emails to clients often consist of bullet points if I’m asking questions, or numbered lists if I’m referencing a procedure or a prioritized list. All of those things are rhetorical choices. And we haven’t even gotten to content yet.

  • What’s the timeline?

    • If there is a deadline, include it in the email so they aren’t wondering. This also avoids numerous email exchanges for clarification. If it’s not mentioned, it will likely be interpreted as something that is not pressing.

  • What details should be included in the email?

    • Provide the reader with the information they need to be informed, make a decision, provide a status report, etc. without having to reply to you with a question.

  • How can I structure my email to improve readability?

    • Many folks read emails on their mobile phones because they’re in meetings or at home, or because staring at a desktop is the bane of their existence.

      • Keep this in mind.

      • Bullet and number content when effective.

      • Keep things as concise as possible.

    • Many people create fancy signatures in Outlook–boxes, logos, quotes, etc. However, they don’t think about how those things affect the people their emailing or how they show up on the recipient’s end.

  • If you’re attaching something, does your recipient have the software required to open it? Do they require additional/special software to do so?

    • Preface this. Inconveniencing your user that you’re likely asking to do something is not something you want to do.

+ What skills do you feel are necessary to be a good technical writer?

I think the necessary skills vary based on what kind of writing. Some technical writers are responsible for editing and proofing content (which is also a part of my job), in which case being an expert when it comes to organization, clarity, grammar, punctuation, and consistency are paramount. I’m lucky that my job entails creating original content, which requires the aforementioned skills and more. I factor in the following components:

  • Audience

    • Reference above bullet for emails (applies here, too) and below on accessibility and usability.

  • Accessibility

    • We naturally design and create documents for people like us, which means we (unknowingly) write for abilities that are congruous to our own. However, it’s important to think about the audience(s) that are not like us that may encounter our deliverables.

      • For example: Let’s say a colleague wants to color code a spreadsheet to indicate phases of the project. What’s the problem here? The document may be sent to employees nationwide to gather feedback and metrics. What if someone was color blind? How would they access the document? Would they be able to use the document? What if the document was printed in black and white and disseminated? Then what?

    • With the documents I encounter, I avoid ableist wording. A former manager, who is an expert technical writer and has been in the field for 40 years, was reviewing my edits and wanted to know why I replaced “See Figure 10” with “Reference Figure 10.” I replied with, “What if someone is encountering this text via a screen reader? And they, in fact, cannot see? It’s exclusionary rhetoric.”

    • Developing documentation (ok, *trying* to develop) with a continuous emphasis on accessibility affects word usage, too. And acronyms, for that matter. If there’s an acronym in a document, unless you have a valid reason not to, it should always be defined the first time it’s used. Because if the reader doesn’t know what an SOP is, they’re going to miss the mark entirely.

  • Usability

    • I firmly believe that content accomplishes nothing if it is not usable and accessible. What you’re creating should always be usable. If you are asked to create instructions for an iPhone, you better make sure non-tech savvy folks can do what you’re asking.

    • I am most definitely guilty of writing with the assumption that the user has the same knowledges that I do. Because step 1 and step 2 for you or me may be step 1-17 for someone who isn’t familiar with the subject matter you’re talking about.

  • Organization and Document Design

    • If it doesn’t make sense to you, it sure as heck won’t make sense to anyone else.

    • Is it organized, structured, and designed for optimum usability? Consider including the following to aid usability:

      • Headings

      • Subheadings

      • Lists

      • Page numbers

      • Labeled references

  • Research and Critical Analysis

    • Tech writers need to have a keen eye for detail and consistency. A manual I was working on had an incorrect equation. A technical document I was working on had an incorrect temperature conversion from Fahrenheit to Celsius. The Spanish manual I was proofing had a content/grammatical error in the caption.

      • I look at the text, but I also review every caption, workflow, diagram, equation, figure, etc. because content is content.

    • A technical writer should be able to write about anything. Am I an expert on the subject, absolutely not, but I need to have a firm understanding and grasp on what I’m reading. I always research what I’m writing about before I do anything, and I continue to research as I move through the project.

  • Project Management

    • Many of my colleagues in the field become project managers more than technical writers. Regardless of the emphasis, or lack thereof, on writing and editing, this is important. You will likely have multiple writing projects at one time; you’ve got to be able to manage them all successfully, not to mention meet your deadlines. I’m responsible for the following:

      • Developing project proposal and estimates

      • Creating timelines

      • Tracking progress

      • Developing status reports

      • Assessing risk

      • Ensuring we’re on budget

      • Communicating with the client(s)

  • Cross-functional Collaboration and Communication

    • Buzzword or not, as a technical writer, your job hinges on your communication. You need to be able to

      • Listen

      • Speak with managers

      • Document what engineers (or developers or any other type of SME) are saying/doing

      • Work effectively with SMEs

      • Incorporate feedback from your reviewers

      • Report back to your manager with status updates and drafts

  • Compliance (Standards and Regulations)

    • Whether the industry is healthcare, medical device, food processing, retail, or something else, I always research what (inter)national standards apply to my document. Content is audited, sure, but I’ve found that technical writers, in some instances, are left to interpret standards. What’s legible to you may mean something totally different to me. I take this as an opportunity to be an advocate for my users and stakeholders, in addition to maintaining compliance and meeting standards.

  • Fundamentals

    • I left these last because the stuff above is the critical analysis component of technical writing. It is what users (tacitly) expect of you, although not on your job description when you apply. What’s below is what is expected of you as a technical writer. Because people assume you draft emails or make documents look “pretty” for a living–it’s so much more.

      • Writing

      • Editing

      • Proofing

      • Grammar

      • Spelling

+ I've never heard of technical writing before. How did you discover it?

I stumbled upon it by accident, to be honest. I discovered the field because I, like many other college students, was not sure what to major in. Here’s my journey: Math Education > English Education > English Studies > Publishing > English Studies > Professional Writing and Rhetoric. It was an accident and I was lucky. I found technical writing because it was an elective for publishing. I took the first class and then decided to take the second class (ENG 349: Advanced Technical Writing) because I needed the credits and I was pretty good at it.

349 was taught by Professor Angela Haas, my now mentor. She spoke about technical writing with passion and purpose. It was in her class, and then during graduate school, that I learned about and developed a passion for accessibility and usability in technical communication. I became fascinated by how we, as (technical) writers, are gatekeepers for our own users. This is something I also talked about in my classroom and I now have 108 undergraduates that curse me on a daily basis (seriously, daily) because they can’t encounter anything without thinking about usability and accessibility–without asking “Why?” over and over (and over). After ENG 349, I took a PhD-level technical communication seminar with Professor Haas, applied to graduate programs in technical and professional writing, went to Michigan State University for my master’s degree, had some stellar internships, taught first-year writing at MSU, took my first job where I tried to be the best technical writer I could be, and here I am, trying to advocate for my end users and customers, every single day.

Gratitude

 

I’ve been fortunate enough to have worked with some incredibly brilliant and kind colleagues. Here’s what they have (okay, want) to say:

 
 

“In my two decades in the aviation field, both Military and Civilian, I have learned a few things about teamwork and collaboration. Even the best laid plans will go nowhere without the right individuals that can work together in a seamless manner that allows everyone’s strength to rise up, while helping minimize weaknesses. Chelsea is the glue that your team needs to effectively work as one to accomplish the task at hand. I have never met a more dedicated and enthusiastic leader in my career. Without Chelsea during the past three years at Delta Air Lines, I have no doubt that our projects would not have been the high caliber pilot training programs they became.

Chelsea is the rare breed of individual that can be put into any situation, with any group of people, and will find a way to succeed. This level of leadership could never be taught, as it requires personality traits that very few possess. Taking these traits and combining them with a work ethic and desire to always do the absolute best is the formula needed to be successful. There is no project that Chelsea could not complete, on time, and with results that exceed all expectations. I have no doubt that any obstacle in her way will be overcome, and any organization that is lucky enough to have her on their team will be better for it.”

Todd Matson, A320 First Officer Instructor, Delta Air Lines


“Chelsea has all of the intelligence that one would expect of a graduate student at a major research institution, but she has other, arguably more important characteristics as well. She works hard, is timely with her work, and produces work of quality the first time. She is a good colleague and an excellent team member. Most importantly, perhaps, Chelsea has remarkable management skills and leadership potential. Her leadership ability, combined with her intelligence and hard work, make valuable and the primary reasons why she has been effective for us.”

Jeff Grabill, Department Chair, Michigan State University

Over the past four years, as a Delta Air Lines Airbus A220 SME, I’ve had the opportunity and pleasure of working with Chelsea.

From day one, it was clear that Chelsea is a uniquely talented technical writer and exceptional instructional designer. Equally evident are Chelsea’s collaboration, networking, and communication skills, which are truly beyond comparison.

She has the ability to manage multiple cross-functional, large-scale projects in a way that allows the collaborating SMEs to focus on their area of expertise.

Chelsea’s work is consistently ahead of schedule, while encompassing extremely high-quality and bulletproof assurance.

The materials she has produced for our department are often offered as an example for other aircraft fleets to emulate.

Michael Shaw, A220 Captain Instructor, Delta Air Lines


I won't reiterate Chelsea's brilliance and talent, because it's evident in her work and the glowing recommendations here. In fact, I have never worked directly with Chelsea. But that’s what positions me so well to speak on the sheer breadth of her integrity, empathy, and kindness; these qualities were clear to me from the moment we met.

As a not-yet technical writer finding my footing, I sent an email to Chelsea hoping for insights into her profession. She not only responded, but became the guiding light I needed by providing me with encouragement and coaching. I’m a technical writer now, largely due to her rallying support. Chelsea could have so easily deleted the one-off email from an internet stranger, but she chose to share her time, energy, and expertise with me instead. Her ability to lead and empower others is remarkable, but the generosity and authenticity she showed me — that is what makes Chelsea truly a privilege to know.

Rogan Hoefer, Tech Writer, Mutual of Omaha


“Chelsea is an extremely bright self-starter who knew right away how she could help the organization. In a short period of time Chelsea fit right in and was a valuable part of the team. Chelsea was happy to help in areas that were not her primary job function. Beyond her traditional technical documentation duties, she was instrumental in accelerating our product development efforts by leading a major project during its requirements definition phase and providing great ideas to improve the usability of the product. Chelsea also took on responsibilities in vendor selection and vendor management toward a challenging goal. She received a performance incentive for her strong work effort.”

Brian Hipsher, Vice President, HealthSpot

Mentorship is one of the toughest professional ships to captain. I was immensely lucky to have Chelsea as my mentor during my tenure at Delta Air Lines.

She was able to see the light and passion in me that I didn’t even know was there. She helped me become more of who I was meant to be in the Learning Design and Development sphere.

I know I won’t do it justice, but if I had to summarize her mentorship impact it would flow something like this:

  • She always encouraged me to do better and never let me rest on my laurels.

  • She openly shared not only her resources and networks, but her vast experience and wisdom that became my lifeline.

  • She picked me up every time I stumbled and opened my eyes to growth opportunities (versus failures).

  • She listened to my ideas and implemented them with so much excitement, it felt like a personal celebration (parade and fireworks included).

  • She didn’t rely on the strategy of simply giving me answers; she gave me the tools to find the answers and grow from each exploration.

Amna Collins, Learning Designer II, Delta Air Lines


“Chelsea’s energy and intelligence shines through in all her interactions. During an internship with my team the summer of 2010, she demonstrated active listening and quickly picked up on the details of the projects we were working on. The work that she completed was completed with attention to detail, creativity, and more than what was expected. She solicited and accepted feedback and ideas from my team members on the work that she was assigned to.I have been very impressed with the professionalism of Chelsea’s networking abilities and how she stays in touch by taking an interest in the work my team is doing.”

Diana Anderson, Group Manager, Walgreen Co.

 

Ask me a question

Smart, silly, frivolous*, I’d be happy to answer it!

*Is there Even such a thing?