Portfolio

The central challenge of a technical blog is not the writing — it is the gap between what the author knows and what the reader can follow. Closing that gap, without softening the technical content or losing the author’s voice, is the work I find most interesting.

The AWS samples below are the most direct evidence of that work. For three years I edited blog posts written by engineers, data scientists, and cloud architects for the Amazon Web Services blog. The authors were practitioners writing for practitioners; my job was to make their arguments clearer, their structure more visible, and their prose more readable — without misrepresenting their claims or inserting a voice that wasn’t theirs. I have done the same thing across emergency management, mathematics education, and federal policy: the domain changes, the editorial problem doesn’t.

I have also built the infrastructure that makes consistent technical writing possible at scale. The two style guides in this portfolio were written from scratch for organizations producing large volumes of technical content across many authors. Both are based on The Chicago Manual of Style and extended to cover domain-specific usage that the base style couldn’t anticipate. Writing guidance that non-editor subject-matter experts can actually follow — without editorial supervision — requires understanding not just what the standard is but why it exists.

The samples are organized around three capabilities: editing technical content for broad audiences, developing editorial standards, and structuring complex multi-author documents. I would welcome the opportunity to discuss any of them.

Section 1: Editing Technical Content for Broad Audiences

The following samples are from my work copyediting technical blog posts for the Amazon Web Services blog, under contract with Steyer Content (2021–2022) and Resources Online (2019). The authors are engineers, data scientists, and cloud architects writing for other practitioners. My job was to make their arguments clearer, their structure more visible, and their prose more readable—without misrepresenting their claims, losing technical precision, or inserting a voice that wasn’t theirs. Each entry includes an edited version with tracked changes alongside a link to the published post.

1a. An AI-Driven Dashboard for Life Sciences Laboratories

Context: AWS Life Sciences Blog, Steyer Content, 2022

Published: aws.amazon.com → Life Sciences Blog

This post describes an AI-driven data visualization system built for laboratory environments, combining AWS services with machine learning pipelines. It demonstrates my comfort editing AI/ML subject matter and producing clear prose from technical authors whose primary expertise is not writing.

File: Edited (tracked changes) ↓

1b. Transforming Site Monitoring in Clinical Trials

Context: AWS Healthcare & Life Sciences Blog, Steyer Content, 2022

Published: aws.amazon.com → Life Sciences Blog

This post makes a technical argument for an AWS-based approach to remote clinical trial monitoring. The editing challenge was helping the author present a clear, evidence-grounded case for their approach while acknowledging its scope and limitations honestly.

File: Edited (tracked changes) ↓

1c. Building STIG-Compliant Amazon Machine Images for EKS

Context: AWS Containers Blog, Steyer Content, 2022

Published: aws.amazon.com → Containers Blog

A technically dense post on security hardening for Kubernetes clusters, this sample demonstrates that I can work fluently with highly specialized infrastructure content, preserving precision while improving structure and readability for a knowledgeable audience. The editing task was largely structural: reorganizing the argument so that the author’s reasoning was visible, not just their conclusions.

File: Edited (tracked changes) ↓

Section 2: Developing Editorial Standards

The two guides below were each built from scratch for organizations producing large volumes of technical content across many authors. Both extend The Chicago Manual of Style to cover domain-specific usage the base style couldn’t anticipate. Together they demonstrate that the same methodology—audit existing inconsistencies, make the judgment calls explicit, write guidance non-editors can actually apply—scales across very different domains. One governed a 158-page department-wide reference for emergency responder training materials; the other governed a large mathematics curriculum produced by dozens of writers working simultaneously.

2a. NCBRT Technical Communications Editorial Style Guide (v1.1)

Context: National Center for Biomedical Research and Training, Louisiana State University, 2010

This 158-page guide was written and compiled for the Technical Communications team at NCBRT. It covers abbreviations, capitalization, citations, grammar, numbers, punctuation, source formatting, and usage specific to emergency management and federal training contexts.

Building it required auditing inconsistencies across years of existing course materials, making judgment calls about contested usage, and writing guidance clearly enough that non-editor subject-matter experts could apply it independently.

File: Style Guide PDF ↓

2b. Great Minds Editorial Style Guidelines

Context: Common Core, Inc. (now Great Minds), 2014

This 32-page guide was written for writers and editors working on the prekindergarten through fifth-grade Eureka Math curriculum—a large, multi-author document production effort with tight consistency requirements across hundreds of lessons and problem sets. Based on The Chicago Manual of Style, it extends that base to address the specific demands of mathematics curriculum: notation conventions, number treatment in mathematical prose, capitalization of curriculum-specific terms, typesetting of problem types, and a glossary of preferred forms for language that recurred throughout the project.

The editorial challenge was precision at scale: many authors writing to the same standard, in a domain where a misplaced hyphen or an inconsistently named problem type produces real errors for teachers and students. Writing guidance that non-editor writers could follow without editorial supervision was the primary design constraint.

File: Style Guide PDF ↓

Section 3: Structuring Complex Multi-Author Technical Documents

The samples below are federal and federally regulated documents produced through IEM, where I have worked as a technical editor since 2020. Each involves assembling contributions from many authors into a single internally consistent document—maintaining consistent terminology, resolving contradictions across sections, and ensuring that the document reads as one coherent whole rather than a collection of parts. The editorial challenges here are structural as much as stylistic: the kind of work that doesn’t show up in a single polished sentence but in whether the document holds together under pressure.

3a. FEMA Region 10 Cascadia Subduction Zone Earthquake and Tsunami Plan (January 2023)

Context: IEM, FEMA contractor, 2023

Published: Washington State Military Department → Website

This regional emergency operations plan was produced for FEMA Region 10 in preparation for a Cascadia Subduction Zone seismic event, one of the highest-consequence natural disaster scenarios in North America. The document is multi-agency, multi-author, and structured to be used operationally under crisis conditions, where clarity and precision are not abstract virtues but practical requirements.

The editing challenges were structural as much as stylistic: ensuring consistent terminology across authors who wrote independently, maintaining logical flow across sections with different owners, verifying that cross-references and role assignments were internally coherent, and catching claims that subtly contradicted each other across sections. The document had to read as one coherent plan, not a collection of contributions.

3b. Orange County, New York Multi-Jurisdictional Multi-Hazard Mitigation Plan (2025)

Context: IEM Technical Communications Team, contractor to Orange County, NY, 2025

Published: townofnewburghny.gov/ → Hazard Mitigation Plan (PDF)

At 2,557 pages covering more than twenty participating jurisdictions, this plan represents the largest class of document in my regular editorial practice. Hazard mitigation plans of this scale are produced by assembling dozens of individually authored Word files—written by planners, subject-matter experts, and jurisdiction representatives across the county—into a single unified document, which is then edited for consistency, coherence, and compliance with FEMA formatting and content standards before submission.

The editorial process is genuinely collaborative: the IEM Technical Communications Team contributes at multiple stages, with different editors taking ownership of different sections and phases. Final quality review of the combined document—checking for terminology drift, broken cross-references, inconsistent role assignments, and formatting compliance—requires one editor to hold the whole in view at once.

The document goes through multiple submission cycles: to the client for review, back to IEM for revisions, to the state for approval, back again, and ultimately to FEMA. FEMA approval is required for jurisdictions to remain eligible for federal hazard mitigation planning grants, which means the accuracy and internal consistency of the document is not an editorial nicety but a condition of federal funding.

Section 4: Editorial Workflow Development

Good editing at scale requires more than good editors—it requires systems. At IEM, I have consistently pushed for process improvements, contributed ideas for workflow refinement, and advised leadership on how the team’s editorial operations could be made more efficient and consistent.

One example: I designed and built the team’s Power BI reporting dashboard, which tracks editing requests and surfaces workflow patterns for leadership. The work had been on my manager’s task list; I took it on, built it, and now own it. Another example is the AI tools evaluation currently underway: rather than testing tools in isolation, the evaluation assesses each one against IEM’s actual editorial workflow—tracked-changes-based document review, multi-thousand-page deliverables, Section 508 compliance, and federal submission requirements. The question was never “what can these tools do” but “what do we actually need, and which of these tools, if any, can do it.” That is a workflow question before it is a technology question.

The Power BI dashboard and AI evaluation report are internal work products and are not posted publicly.

June 2026