Streamlining Technical Writing For Engineering Teams

The VP of R&D at a Fortune 500 pharma company told me: "I can't make sense of these research reports." Their problem: Brilliant scientists (or other team members) struggling to communicate complex findings clearly. The impact: • Regulatory submissions at risk • 6- to 7-figure losses from documentation delays • Frustrated scientists spending more time rewriting than researching Here’s how they turned things around: 1. Recognized the problem    If you want to fix something, you need to first acknowledge it’s broken. Fortunately, this company was willing to do that. An R&D Associate Scientist admitted, "Without prior scientific technical writing training, clearly communicating experiment details was a challenge." The team was developing innovative cell therapy candidates for diseases like Crohn's and rheumatoid arthritis. Precision in lab work wasn't translating to precision on paper. 2. Sought specialized help   Acknowledging the problem isn’t enough. That’s where agency is important, in the form of seeking a solution. This pharma company knew it needed more than a generic writing course. Pharma’s needs are unique. So they did their research, got a few proposals, and ended up hiring Hurley Write, Inc. 3. Implemented a custom solution    We went on to customize our writing training for them: • Interactive workshops using real work examples • Focus on critical thinking and problem-solving, not just grammar • Emphasis on reader expectations and information organization • Science-based curriculum grounded in readability studies • Group exercises and discussions to enhance learning • Training reviewers so that they wouldn’t depend on us The result: ✅ Immediate improvement in report clarity ✅ More concise and structured writing ✅ Positive feedback from leadership and peers ✅ Faster review processes ✅ Millions and millions (and a lot of frustration) saved in the long term One participant had this to say: "Now I always reread what I write and make sure it's not complicated, vague, or unstructured. I make sure to explain scientific details with clarity and always ensure that the main point and purpose are clearly understood within the first couple lines." Because if you want to change the quality of your organization’s writing, you need to change the way people *think* about writing in the first place. P.S. Question for my pharma friends: What's the biggest writing challenge your technical teams face? Drop it in the comments - I'd love to share some specific strategies that might help.

Just reviewed your procedures, …and – well – they’re not good… ->they’re either too detailed, turning into a novel, or so vague they leave the reader scratching their head. The secret? Tailoring your procedures to your audience and hitting that "just right" level of detail. Here’s how I try to strike the balance… ->Write for the people executing the procedure. Are they experienced engineers, junior analysts, or cross-functional (HR, Accounting, etc.) teams? Use language and concepts they’ll understand. ->Avoid unnecessary theory or deep background and PLEASE assume a baseline of competence. Outline clear, actionable steps someone ->skilled in the art<- can follow without needing extra guidance. ->Include enough detail to prevent confusion or missteps, but not so much that your procedure becomes heavy to follow or maintain. ->Use concise, active language. Focus on tasks, tools, and outcomes. Every word should add clarity & value to execution. ->Have someone unfamiliar with the procedure try to execute it. If they ask for clarification, refine it. If they finish without questions, you’re close to “goldilocks.” When procedures are done right, they empower your team to act confidently and consistently. Start by writing a procedure to make a peanut butter and jelly sandwich, then have someone follow it and provide feedback. Iterate and improve. #ciso #dpo #MSP #compliance #procedures

The shift from traditional DITA/XML #documentation pipelines to a docs-as-code approach represents a significant evolution in technical writing. By treating documentation like code, we can streamline their content development while improving collaboration and quality. Markdown has emerged as the clear winner for modern documentation (this isn't new news, markdown has been the de-facto go-to for years now), offering a clean, readable syntax that's both human and machine-friendly. When combined with Git version control, technical writers gain powerful capabilities like branching, meaningful version history, and the ability to handle concurrent updates seamlessly. Documentation linters add another layer of consistency by automatically checking for style guide violations, broken links, and formatting issues before content goes live. Unlike rigid DITA/XML workflows that often require specialized tools and expertise, docs-as-code leverages the same tools developers use daily. This alignment not only reduces tooling costs but also breaks down silos between technical writers and development teams. Docs-as-code is also just faster and more efficient than DITA, in my experience. It leads to simpler, cleaner docs through and through. The result? Faster documentation cycles, better collaboration, and the ability to maintain documentation at the speed of software development. As someone who's witnessed this transformation firsthand, I can't imagine going back to the complexity and constraints of traditional XML-based workflows. Push for modern documentation practices at your org. The future isn't tomorrow, it's today so modernize your docs workflows and tooling! #TechnicalWriting #DocsAsCode #Documentation #TechComm #DevDocs #Tech #Engineering