Technical Writer

Role Purpose & Context

Role Summary

The Technical Writer is here to independently author clear, accurate documentation for our R&D projects, from new software tools to experimental procedures. You'll take ownership of entire document sets, making sure our internal users can actually understand and use the cutting-edge work our scientists and engineers are doing. When you do this well, our researchers spend less time explaining things and more time innovating, and new team members get up to speed much faster. If you don't, people get stuck, make mistakes, and our internal support channels get swamped. The tricky part is often getting the right information from busy experts who sometimes struggle to explain their own genius simply. The reward, though, is seeing your documentation genuinely enable breakthroughs and accelerate our research.

Reporting Structure

• Reports to: Senior Technical Writer
• Direct reports: 0
• Matrix relationships: Technical Author, Documentation Specialist, Content Developer (R&D),

Key Stakeholders

Internal:

• Research Scientists (your primary source of information)
• Software Engineers (for internal tools and APIs)
• Product Managers (who define what needs documenting)
• Quality Assurance Testers (who validate our processes)
• Other Technical Writers (for peer reviews and collaboration)

External:

Organisational Impact

Scope: Your work directly impacts the efficiency and effectiveness of our entire R&D department. Clear documentation means fewer errors in experiments, faster adoption of new internal tools, and a smoother onboarding experience for everyone. Honestly, it's about making sure our brilliant minds don't waste time figuring out how to use something, but rather focus on what they do best: research and development.

Performance Metrics

Quantitative Metrics

1. Metric: First Draft Accuracy
2. Desc: The percentage of your content that gets accepted by the Subject Matter Expert (SME) in the first review round, with minimal changes needed.
3. Target: <10% of content requires significant rework after first SME review
4. Freq: Per document/project
5. Example: You submit a draft for a new experimental protocol, and the lead scientist only suggests a few minor wording tweaks, not structural changes or factual corrections. That's a win.
6. Metric: Time-to-Publish (Routine Updates)
7. Desc: How quickly you can get routine documentation updates (e.g., minor changes to an existing guide) published after receiving the request.
8. Target: Routine updates published within 48 hours of request
9. Freq: Weekly/Bi-weekly audit
10. Example: A researcher flags a typo or a small process change in a Confluence page. You fix it, get a quick sign-off, and publish it within a day.
11. Metric: User Feedback Score
12. Desc: The average rating or 'helpful' score your published articles receive from internal users.
13. Target: Achieve an average of 4/5 stars or >80% 'Helpful' rating on published articles
14. Freq: Monthly/Quarterly review of feedback forms
15. Example: Your guide on setting up a new simulation environment consistently gets positive feedback, with comments like 'finally, a guide that actually works!'.
16. Metric: Documentation Completion Rate
17. Desc: The percentage of assigned documentation tasks or projects that you complete and publish by their agreed-upon deadlines.
18. Target: 90% of assigned documentation tasks completed on schedule
19. Freq: Monthly project review
20. Example: You committed to having the API documentation for the new internal data processing library ready by month-end, and it's live by the 28th.

Qualitative Metrics

1. Metric: Clarity and Scannability
2. Desc: How easy your documentation is to read, understand, and navigate, especially for someone new to the topic. Are people finding what they need quickly?
3. Evidence: SMEs comment on how 'easy to follow' your guides are. New joiners mention your docs as a key resource. Low number of follow-up questions to SMEs after they've read your work. Use of clear headings, bullet points, and visuals.
4. Metric: Proactive Information Gathering
5. Desc: Your ability to actively seek out information from busy researchers, anticipating their needs and ensuring you're not just waiting for them to tell you what to write.
6. Evidence: You're attending relevant project meetings even when not explicitly invited. You're asking insightful questions that uncover hidden details. You're building relationships with key SMEs who trust you to come to them early.
7. Metric: Adherence to Style & Standards
8. Desc: How well your documentation follows our internal style guides, templates, and information architecture principles, ensuring consistency across all R&D content.
9. Evidence: Peer reviews consistently show few style guide violations. Your documents fit seamlessly into our existing knowledge base structure. You're using conditional text and variables correctly for reuse.
10. Metric: Problem-Solving & Adaptability
11. Desc: Your knack for figuring things out when information is incomplete or when the underlying technology changes, and your ability to adjust your approach.
12. Evidence: You're not just reporting problems; you're suggesting solutions for missing information. You can quickly adapt a document when a technical spec changes mid-way through writing. You're comfortable documenting a 'moving target' to a reasonable degree.

Primary Traits

• Trait: Forensic Curiosity
• Manifestation: You're the person who relentlessly asks 'why?' not just 'what?'. You'll deconstruct a researcher's explanation, then reassemble it in your own words to confirm you've truly understood it. Honestly, you'll spend time in the lab (virtually or physically) or digging through source code to see the process firsthand, rather than just taking someone's word for it. You're not afraid to ask 'stupid' questions, because you know they often uncover critical, unspoken assumptions.
• Benefit: Our R&D Subject Matter Experts (SMEs) are often 'unconscious competents' – they're so brilliant and experienced that they struggle to explain foundational concepts to someone new. This trait is absolutely essential to extract that 'tribal knowledge' and document it accurately. Get this wrong, and we'll have critical errors in experimental procedures or misunderstandings of our internal tools, which costs us time and money.
• Trait: Systematic Thinker
• Manifestation: You naturally break down a complex experiment, a new software system, or a research workflow into a logical sequence of inputs, processes, and outputs. Before you even write a sentence, you're sketching flowcharts, outlining sections, and thinking about how someone will navigate the information. You're always structuring documentation for non-linear consumption, knowing people will jump around, not read cover-to-cover.
• Benefit: R&D work is inherently complex and interconnected. If you don't think systematically, you'll just create a 'wall of text' that's impossible to follow. We need documentation that's a structured guide, not just a brain dump. This prevents costly mistakes, accelerates onboarding for new team members, and makes our research more reproducible.
• Trait: Pedagogical Empathy
• Manifestation: You're brilliant at putting yourself in the shoes of a new user. You anticipate where they'll get stuck, what assumptions they might make, or what jargon they won't understand. You'll translate dense academic language into clear, unambiguous instructions, fighting to include a 'Why this matters' section, not just the 'How to do it.' You care deeply about making things easy for others to learn.
• Benefit: Our audience—other scientists and engineers—are brilliant, but they're also time-poor and often new to the specific tool or process you're documenting. Empathetic documentation reduces their cognitive load, minimises support requests to our senior researchers (who are busy innovating!), and increases the adoption of new technologies and methodologies within the department. It's about respecting their time and intelligence.

Supporting Traits

• Trait: Diplomatic Tenacity
• Desc: You'll need the ability to persistently follow up with busy, distracted SMEs for reviews and information without becoming a nuisance. It's a fine line, but you'll walk it well.
• Trait: Resilience to Ambiguity
• Desc: Honestly, the 'final' design or process is often in flux here. You'll need to thrive in an environment where things change, documenting what's known today while planning for future updates.
• Trait: Visual Thinker
• Desc: You instinctively reach for a whiteboard (physical or virtual) or a diagramming tool to clarify a complex workflow, system architecture, or data pipeline. A good diagram is worth a thousand words, especially in R&D.

Primary Motivators

1. Motivator: Solving Puzzles & Clarifying Complexity
2. Daily: You'll spend your days taking incredibly complex, often abstract, R&D concepts and breaking them down into understandable, actionable steps. It's like being a detective, piecing together clues from code, conversations, and experiments to form a coherent narrative. The satisfaction comes from turning chaos into order.
3. Motivator: Enabling Others' Success
4. Daily: Your work directly helps our scientists and engineers be more productive. You'll get a real kick out of knowing your documentation has saved someone hours, prevented a costly error, or helped a new colleague get started quickly. You're an unsung hero, making sure the R&D engine runs smoothly.
5. Motivator: Continuous Learning & Growth
6. Daily: You'll constantly be exposed to new scientific discoveries, engineering methodologies, and internal tools. Every project is a chance to learn something new, diving deep into different domains within R&D. If you love intellectual stimulation and expanding your knowledge base, you'll find plenty of it here.

Potential Demotivators

Let's be real, this job isn't always glamorous. You'll often find yourself documenting a 'moving target' – a process or tool that's still being actively designed, meaning constant rewrites. You might be treated as the 'last mile' checkbox in a project, handed a complex system with an impossible deadline and little prior context. Honestly, you'll sometimes feel like you're fighting for a seat at the table, trying to get included in early design meetings to understand the 'why,' not just the 'what.' And yes, you'll occasionally have to deal with 'stale docs' – existing documentation that's worse than useless because it's so outdated.

Common Frustrations

1. The 'Knowledge Curse': Trying to extract clear explanations from brilliant SMEs who are so deep in their field they can no longer explain it to a beginner.
2. Documenting a Moving Target: Being asked to document a process or tool while it's still being actively designed, leading to constant rewrites and wasted effort.
3. The Last Mile Problem: Being treated as the final checkbox in a project, handed a complex system with an impossible deadline and no prior context.
4. Fighting for a Seat at the Table: The constant struggle to be included in early design and planning meetings to understand the 'why,' not just the 'what.'
5. Archaeological Digs: Discovering the existing 'documentation' is a wasteland of conflicting wiki pages, outdated Word documents on a shared drive, and cryptic notes in a lab book.
6. The 'Just Write It Down' Fallacy: Stakeholders who believe technical writing is simply typing what an SME says, underestimating the work of structuring, clarifying, and validating information.

What Role Doesn't Offer

1. A perfectly stable, unchanging environment where processes are set in stone.
2. The opportunity to lead a team or manage people (at this level, anyway).
3. A role where you're always the first person consulted on strategic decisions.
4. A quiet, isolated corner where you can just write without interruption (SME wrangling is real!).

ADHD Positives

1. The constant exposure to new R&D projects and technologies means a high degree of novelty, which can be highly engaging and prevent boredom.
2. The need to quickly switch between different topics and tasks (e.g., interviewing an SME, then writing, then diagramming) can suit those who thrive on variety.
3. The 'forensic curiosity' trait, a deep dive into 'why' things work, can be a strength for hyperfocus and detailed analysis.

ADHD Challenges and Accommodations

1. Maintaining focus during lengthy, complex writing tasks can be tough. We can offer noise-cancelling headphones and flexible work arrangements to minimise distractions.
2. Prioritising multiple urgent requests from different SMEs can be overwhelming. We'll help you with structured prioritisation frameworks and regular check-ins to manage your workload.
3. The need for meticulous attention to detail in technical accuracy might be challenging. We use peer reviews and automated checks to catch errors, and encourage breaking down large tasks into smaller, manageable chunks.

Dyslexia Positives

1. Strong verbal communication skills, often found in dyslexic individuals, are incredibly valuable for interviewing SMEs and clarifying complex ideas.
2. The ability to see the 'big picture' and make connections between disparate pieces of information is key for information architecture and structuring complex documentation.
3. Visual thinking is a huge asset here, and many dyslexic individuals excel at it. Diagramming complex systems is a core part of the job.

Dyslexia Challenges and Accommodations

1. Proofreading and catching spelling/grammar errors can be challenging. We use advanced grammar checkers (like Grammarly Business), peer review processes, and dedicated editing tools.
2. Organising and structuring large amounts of text can be difficult. We provide robust templates, outlining tools, and encourage the use of topic-based authoring to break down content.
3. Reading dense technical specifications can be tiring. We support text-to-speech tools and encourage breaking reading tasks into shorter, focused sessions.

Autism Positives

1. A strong preference for logic, order, and precision aligns perfectly with the need for clear, unambiguous technical documentation.
2. The ability to deeply focus on a specific topic and master its intricacies is invaluable for understanding complex R&D domains.
3. A direct communication style, focused on facts and accuracy, is highly valued when interacting with engineers and scientists.

Autism Challenges and Accommodations

1. Navigating unspoken social cues during SME interviews can be tricky. We provide clear interview templates, encourage direct questions, and offer support in interpreting feedback.
2. Unexpected changes in project scope or priorities can be unsettling. We strive for clear communication about changes and provide structured updates to minimise surprise.
3. A preference for routine might clash with the 'moving target' nature of R&D. We offer tools for structured planning and encourage focusing on what can be controlled and documented today.

Key Responsibilities

Experience Levels Responsibilities

1. Level: Mid-Level Technical Writer (2-5 years experience)
2. Responsibilities: Independently author complete documentation sets for new features, internal tools, or experimental procedures, from initial concept to final publication.
3. Conduct thorough interviews with Research Scientists and Engineers to extract complex technical information, asking probing questions to ensure accuracy and completeness.
4. Design and create clear, concise diagrams, flowcharts, and illustrations (using tools like Lucidchart) to explain complex R&D processes and system architectures.
5. Manage and organise documentation projects within Jira, ensuring tasks are tracked, updated, and delivered on schedule, communicating any roadblocks early.
6. Apply existing templates and style guides rigorously across all your content, ensuring consistency and adherence to our internal standards.
7. Use our content management system (typically MadCap Flare or Confluence) to publish and maintain documentation, including applying conditional text for different audiences.
8. Collaborate with other technical writers and R&D teams to ensure documentation aligns with overall project goals and information architecture.
9. Perform basic version control tasks using Git (e.g., cloning repos, committing changes, creating pull requests) for docs-as-code initiatives.
10. Supervision: You'll have weekly check-ins with your Senior Technical Writer for guidance and to discuss progress, but you're expected to manage your day-to-day tasks independently. For routine issues, you'll choose your own approach; for novel or complex problems, you'll escalate and discuss options.
11. Decision: You'll make routine technical decisions within the scope of your documentation projects, like choosing the best way to structure a specific guide or which diagramming approach to use. Any decisions impacting project timelines, budget (even small ones, say above £500), or major changes to content strategy will need to be discussed and approved by your Senior Technical Writer or Lead.
12. Success: You'll know you're succeeding when your documentation consistently receives positive feedback from researchers, reduces their 'time-to-answer' for common questions, and you're able to deliver your projects on time with minimal supervision. Basically, if people are using your docs and thanking you for them, you're doing it right.

Decision-Making Authority

• Type: Content Structure & Organisation (within a document)
• Entry: Follows established templates and outlines; seeks approval for any deviations.
• Mid: Independently designs logical content structures for new documents; consults with Senior Technical Writer on complex information architecture challenges.
• Senior: Defines and evolves content structure standards for entire documentation suites; mentors others on best practices.
• Type: Information Gathering Strategy (SME Interviews)
• Entry: Uses provided interview templates; relies on supervisor to identify key SMEs.
• Mid: Develops tailored interview questions based on project brief; identifies relevant SMEs and schedules meetings independently.
• Senior: Coaches junior writers on effective SME wrangling techniques; designs strategies for capturing 'tribal knowledge' across teams.
• Type: Tool & Software Usage (within established stack)
• Entry: Uses designated tools (e.g., MadCap Flare, Confluence) for specific tasks as instructed.
• Mid: Chooses appropriate tools from the approved stack for a given task (e.g., Flare for manuals, Confluence for internal wikis); explores new features within existing tools.
• Senior: Evaluates new tools for potential adoption; defines best practices for tool usage across the team; troubleshoots complex tool-related issues.
• Type: Project Timelines & Scope
• Entry: Adheres strictly to assigned timelines; escalates any potential delays immediately.
• Mid: Manages own project timelines for assigned documentation tasks; proactively communicates potential delays and proposes solutions to Senior Technical Writer.
• Senior: Negotiates documentation timelines with R&D project leads; identifies and mitigates scope creep; manages multiple concurrent documentation projects.

Competency Requirements

Foundation Skills (Transferable)

These are the bedrock skills that let you do your job well, no matter the specific project. Think of them as your core toolkit for effective communication and problem-solving in a technical environment.

• Category: Communication & Collaboration
• Skills: Active Listening: Genuinely hearing and understanding complex technical explanations from SMEs, even when they're not perfectly articulated.
• Clear & Concise Writing: The ability to distil complex information into simple, unambiguous language that's easy to read and act upon.
• Interviewing Skills: Asking open-ended, probing questions to extract tacit knowledge from busy experts without wasting their time.
• Feedback Incorporation: Taking constructive criticism on your drafts and applying it effectively to improve your work, without ego.
• Peer Review Participation: Providing helpful, specific feedback to other writers on their documentation, and being open to receiving it.
• Category: Problem-Solving & Critical Thinking
• Skills: Information Synthesis: Taking disparate pieces of information (notes, code, diagrams) and combining them into a coherent, logical narrative.
• Audience Analysis: Understanding who will read your documentation and tailoring the content, tone, and level of detail accordingly.
• Troubleshooting Documentation Gaps: Identifying where information is missing or unclear and figuring out how to get it, or how to bridge the gap.
• Logical Structuring: Organising complex technical topics into intuitive, navigable structures (e.g., using headings, lists, and cross-references effectively).
• Root Cause Analysis (for documentation issues): Figuring out *why* a piece of documentation is confusing or incorrect, not just fixing the symptom.
• Category: Adaptability & Learning Agility
• Skills: Rapid Learning: Quickly grasping new scientific concepts, engineering principles, and software functionalities.
• Context Switching: Moving efficiently between different R&D projects and technical domains throughout the day or week.
• Process Adherence: Following established documentation workflows, style guides, and version control procedures consistently.
• Self-Directed Learning: Taking the initiative to learn new tools, technologies, or writing techniques as needed for a project.
• Comfort with Ambiguity: Being able to start documenting something even when all the details aren't 100% finalised, and adapting as they evolve.

Functional Skills (Role-Specific Technical)

These are the specific methodologies, tools, and knowledge areas that you'll use day-to-day to produce high-quality R&D documentation.

Technical Competencies

• Skill: Information Architecture (IA)
• Desc: Designing scalable and intuitive structures for complex knowledge bases, ensuring scientists and engineers can find information efficiently without 'pogo-sticking' between pages. This means thinking about navigation, search, and content relationships.
• Level: Intermediate: Can design IA for individual document sets or small knowledge base sections; understands principles of topic-based authoring.
• Skill: Docs-as-Code Principles
• Desc: Understanding the methodology of treating documentation with the same rigor as software—using version control (Git), plain text formats (like Markdown), and thinking about automated build/test pipelines to publish. It's about collaboration and consistency.
• Level: Intermediate: Can apply Docs-as-Code principles to their own work, manage content in Git, and understand basic build processes.
• Skill: DITA (Darwin Information Typing Architecture) Concepts
• Desc: Understanding and applying the principles of topic-based, structured authoring (Concept, Task, Reference) to enable content reuse and single-sourcing at scale. This helps us write once and publish everywhere.
• Level: Basic: Understands the core concepts of DITA and can apply topic types (concept, task, reference) in practice; can use existing DITA templates.
• Skill: Minimalism in Technical Writing
• Desc: A writing philosophy focused on providing the absolute minimum information required for a user to succeed, prioritising clarity, accuracy, and scannability over exhaustive detail. It's about getting to the point quickly.
• Level: Intermediate: Can apply minimalist principles to their writing, focusing on user goals and stripping out unnecessary information.
• Skill: API Documentation (Internal R&D APIs)
• Desc: Documenting internal APIs and software libraries used by R&D teams, providing clear endpoints, parameters, and example code so researchers can build on each other's work. This is crucial for internal software development.
• Level: Basic: Can read and understand API specifications; can document simple API endpoints and parameters following existing templates.

Digital Tools

• Tool: MadCap Flare
• Level: Intermediate
• Usage: Creating and publishing topic-based content for user manuals, internal guides, and online help systems. You'll be applying conditional tags and variables for basic single-sourcing.
• Tool: Confluence
• Level: Intermediate
• Usage: Creating, editing, and organising pages within existing R&D knowledge spaces. You'll use macros (like TOCs, info panels) and follow established templates for team wikis and internal process docs.
• Tool: Git (GitHub/GitLab)
• Level: Intermediate
• Usage: Cloning documentation repositories, committing your changes to existing branches, and creating pull requests with clear descriptions. You'll follow our established branching strategies for documentation.
• Tool: Lucidchart / Visio
• Level: Intermediate
• Usage: Creating simple to moderately complex flowcharts, process maps, and system diagrams using standard shape libraries and templates to visually explain R&D workflows or system architectures.
• Tool: Zotero / EndNote
• Level: Intermediate
• Usage: Collecting and organising references for research papers and internal reports. You'll insert formatted citations and bibliographies into your documents using the word processor plugin.
• Tool: LaTeX
• Level: Basic
• Usage: Editing existing `.tex` files to update content for scientific papers or reports. You'll be able to write basic mathematical formulas and create simple tables within LaTeX documents.
• Tool: Jira
• Level: Intermediate
• Usage: Viewing tickets assigned for documentation tasks, updating their status, adding comments, and attaching draft documents. You'll also write effective user stories for your own doc tasks.

Industry Knowledge

• Area: Scientific Research Methodologies
• Desc: A foundational understanding of how scientific research is conducted, including experimental design, data collection, analysis, and interpretation. This helps you understand the context of what you're documenting.
• Area: Software Development Lifecycle (SDLC)
• Desc: Knowledge of the typical phases of software development (planning, design, implementation, testing, deployment) as it applies to internal R&D tools and software libraries. This helps you time your documentation efforts.
• Area: Intellectual Property Basics
• Desc: A basic awareness of patents, trademarks, and copyright, particularly as it relates to documenting novel inventions or research findings. You won't be writing patents, but you'll understand the context.

Regulatory Compliance Regulations

• Reg: Internal R&D Data Handling Policies
• Usage: Ensuring any documentation you create regarding data collection, storage, or processing adheres to our internal policies for data security and privacy, especially for sensitive research data.
• Reg: Health & Safety Guidelines (Lab Environments)
• Usage: Understanding and accurately documenting safety protocols for any lab-based experimental procedures, making sure warnings and precautions are clear and prominent.

Essential Prerequisites

• A proven track record of 2-5 years in technical writing, preferably within a scientific, engineering, or similarly complex technical domain.
• Demonstrable experience in interviewing Subject Matter Experts and translating complex information into clear, user-friendly documentation.
• Solid understanding of version control concepts (like Git) and experience using at least one modern component content management system (CCMS) or authoring tool (e.g., MadCap Flare, Paligo, Oxygen XML).
• A portfolio of writing samples that showcases your ability to explain complex technical topics clearly and concisely.
• A genuine curiosity for how things work, especially in the realm of science and technology.

Career Pathway Context

These prerequisites aren't just a checklist; they're the foundational skills you'll need to hit the ground running and quickly take ownership of your documentation projects. We're looking for someone who's ready to jump in and start making a real impact from day one, building on their existing experience to tackle new challenges in R&D.

Qualifications & Credentials

Emerging Foundation Skills

• Skill: Prompt Engineering & LLM Integration
• Why: Honestly, competitors are already using large language models (LLMs) to draft reports in minutes that used to take hours. Writers who figure this out will outproduce their peers significantly. It's not about being replaced; it's about being augmented.
• Concepts: [{'concept_name': 'Context Windows & Token Limits', 'description': "Understanding how much information an AI can 'remember' and process at once, and how to manage it effectively for long documents."}, {'concept_name': 'Temperature Settings for Different Tasks', 'description': 'Learning to adjust AI creativity for tasks like brainstorming (higher temperature) versus factual summarisation (lower temperature).'}, {'concept_name': 'RAG (Retrieval Augmented Generation) Architectures', 'description': 'How to connect LLMs to our internal, proprietary R&D data so they can generate accurate content based on our specific knowledge base, not just general internet data.'}, {'concept_name': 'Output Validation & Hallucination Detection', 'description': "Developing a critical eye to verify AI-generated content for factual accuracy and identifying when the AI 'makes things up' (hallucinates)."}, {'concept_name': 'Prompt Chaining for Complex Analysis', 'description': 'Breaking down complex writing tasks into a series of smaller, sequential prompts to guide the AI through multi-step content generation.'}]
• Prepare: This week: Set up and start regularly using a tool like GitHub Copilot or ChatGPT/Claude for drafting emails, summarising meeting notes, and generating code comments.
• This month: Experiment with generating a first draft of a simple internal process document using an LLM. Focus on refining the prompts to get better output.
• Month 2: Research RAG architectures and explore how you might feed an LLM with some of our non-sensitive, public R&D documentation to improve its output.
• Month 3: Share your findings and productivity gains with the team. Start a small internal 'AI for Docs' working group.
• QuickWin: Start using Claude or ChatGPT today to draft email summaries, generate alternative phrasings for complex sentences, or create outlines for your documents. No approval needed, immediate benefit.
• Skill: Interactive & Multimedia Documentation
• Why: Static text documents, while essential, aren't always the most effective way to explain complex R&D processes, especially for visual learners. Interactive guides, short video tutorials, and embedded simulations are becoming more expected.
• Concepts: [{'concept_name': 'Video Scripting & Storyboarding', 'description': 'Planning out short, clear video tutorials for complex lab procedures or software walkthroughs.'}, {'concept_name': 'Basic Screen Recording & Editing', 'description': 'Using tools like Loom or Camtasia to capture software interactions and add simple annotations or voiceovers.'}, {'concept_name': 'Interactive Walkthrough Tools', 'description': 'Exploring tools that allow users to click through simulated software environments or guided tours.'}, {'concept_name': 'Accessibility for Multimedia', 'description': 'Ensuring video content has captions, transcripts, and audio descriptions for all users.'}, {'concept_name': 'Measuring Engagement', 'description': 'Understanding how to track views, completion rates, and feedback on multimedia content.'}]
• Prepare: This week: Watch a few 'how-to' videos on YouTube for a technical topic and critically analyse what makes them effective or ineffective.
• This month: Experiment with creating a 2-minute screen recording tutorial for a simple internal tool using Loom or OBS Studio.
• Month 2: Script and record a short video explaining a common R&D process, focusing on clarity and conciseness.
• Month 3: Get feedback from colleagues on your multimedia content. What worked? What could be better?
• QuickWin: Record a quick, unpolished screen capture to explain a tricky step in a process to a colleague instead of writing a long email. It's often faster and clearer.

Advancing Technical Skills

• Skill: Advanced MadCap Flare/CCMS Usage
• Why: As our R&D projects grow in complexity, so does the need for sophisticated content reuse and multi-channel publishing. You'll need to go beyond basic templates.
• Concepts: [{'concept_name': 'Advanced Single-Sourcing Strategies', 'description': 'Designing complex content reuse models, including nested snippets, variables, and conditional text for multiple outputs (e.g., web, PDF, mobile).'}, {'concept_name': 'Skins & Master Pages Customisation', 'description': 'Developing and maintaining custom output skins and master pages to ensure consistent branding and user experience across all documentation.'}, {'concept_name': 'Troubleshooting Build Errors', 'description': 'Diagnosing and resolving complex build issues, including broken links, missing files, and formatting inconsistencies.'}, {'concept_name': 'Integrating with External Systems', 'description': 'Exploring how Flare can integrate with other R&D tools or content repositories for seamless information flow.'}, {'concept_name': 'Optimising for Search & SEO', 'description': 'Applying best practices within Flare to ensure our online documentation is easily discoverable by internal users through search.'}]
• Prepare: This week: Explore the advanced features in Flare's online help or community forums. Pick one feature you haven't used and try it out.
• This month: Take on a project that requires more complex conditional text or variable usage than you're used to.
• Month 2: Shadow a Senior Technical Writer on a project involving custom skin development or advanced single-sourcing.
• Month 3: Propose an improvement to our current Flare project setup that uses a more advanced feature.
• QuickWin: Experiment with creating a new variable or conditional tag in a test project to see how it works. It's a small step, but it builds confidence.
• Skill: Documentation CI/CD (Continuous Integration/Continuous Deployment)
• Why: Just like software, documentation needs to be updated and deployed rapidly. Automating our documentation builds and releases ensures consistency and speed, reducing 'doc debt'.
• Concepts: [{'concept_name': 'Git Hooks & Workflows', 'description': 'Understanding how automated actions can be triggered in Git (e.g., running a linter or build script on commit).'}, {'concept_name': 'Basic Scripting (e.g., Python, Bash)', 'description': 'Writing simple scripts to automate tasks like converting formats, validating links, or triggering builds.'}, {'concept_name': 'Build Tools & Static Site Generators', 'description': 'Familiarity with tools like MkDocs, Sphinx, or Jekyll, which can automatically generate documentation websites from plain text files.'}, {'concept_name': 'Deployment Pipelines (e.g., GitHub Actions, GitLab CI)', 'description': 'Understanding the basics of how automated pipelines can take documentation source files and publish them to a web server or knowledge base.'}, {'concept_name': 'Automated Testing for Docs', 'description': 'Concepts like link validation, spell checking, and style guide enforcement as part of an automated build process.'}]
• Prepare: This week: Read an introductory article on 'Docs-as-Code CI/CD' to get a general understanding of the concepts.
• This month: Find a simple open-source documentation project on GitHub that uses a static site generator and try to build it locally.
• Month 2: Experiment with a simple GitHub Action to run a spell check on a Markdown file in a test repository.
• Month 3: Discuss with a Senior Technical Writer or Engineer how we could automate a small part of our current documentation build process.
• QuickWin: Set up a local Markdown linter (e.g., markdownlint) and integrate it into your text editor. It's a tiny step towards automated quality checks.

Education Requirements

• Level: Minimum
• Req: A Bachelor's degree in a relevant field such as Technical Communication, English, Journalism, Computer Science, Engineering, or a Scientific discipline.
• Alts: We're pragmatic here. If you don't have a degree but have 4+ years of demonstrable, high-quality technical writing experience in a complex R&D or engineering environment, coupled with a strong portfolio, we'd still love to hear from you. Equivalent practical experience really does count.
• Level: Preferred
• Req: A Master's degree in a technical or scientific field, or in Technical Communication.
• Alts: While not essential, a Master's can give you a deeper understanding of the scientific context you'll be writing about, which is always a bonus.

Experience Requirements

You'll need roughly 2-5 years of dedicated experience as a Technical Writer or Technical Author. This isn't just about writing; it's about having a proven track record of independently owning documentation projects from start to finish. We're talking about experience in interviewing Subject Matter Experts, structuring complex technical information, and using modern authoring tools. Ideally, some of this experience will have been in a research, engineering, or software development context where you've had to grapple with genuinely complex subject matter.

Preferred Certifications

• Cert: Certified Professional Technical Communicator (CPTC)
• Prod: Society for Technical Communication (STC)
• Usage: Demonstrates a foundational understanding of technical communication best practices and principles.
• Cert: MadCap Flare Certified Developer
• Prod: MadCap Software
• Usage: Shows a deeper proficiency in our primary authoring tool, meaning you'll hit the ground running more quickly.
• Cert: DITA Fundamentals Certification
• Prod: Various (e.g., LearningDITA, CIDM)
• Usage: Confirms your understanding of structured authoring principles, which are key to our content strategy.

Recommended Activities

• Regularly reading industry blogs and publications (e.g., STC Intercom, Write the Docs community) to stay on top of trends.
• Attending webinars or online courses on new authoring tools, AI in documentation, or specific R&D domains (e.g., a 'crash course' in bioinformatics if you're documenting a related project).
• Participating in internal 'lunch and learn' sessions where R&D teams present their work, helping you broaden your knowledge base.
• Contributing to open-source documentation projects to hone your Docs-as-Code skills and collaborate with a wider community.

Career Progression Pathways

Entry Paths to This Role

• Path: Associate Technical Writer (L1) at Zavmo
• Time: 1-2 years
• Path: Technical Writer from a related industry (e.g., Software, Manufacturing)
• Time: Direct entry (0-6 months ramp-up)
• Path: Researcher/Engineer with strong writing skills
• Time: Direct entry (0-9 months ramp-up)

Career Progression From This Role

• Pathway: Senior Technical Writer (L3)
• Time: 3-5 years in current role

Long Term Vision Potential Roles

• Title: Staff Technical Writer (L4)
• Time: 5-8 years from current role
• Title: Principal Technical Writer / Documentation Manager (L5)
• Time: 8-12 years from current role
• Title: Director, Technical Communications & Knowledge Management (L6)
• Time: 12-16 years from current role

How Zavmo Delivers This Role's Development

DISCOVER Phase: Skills Gap Analysis

Zavmo maps your current competencies against all requirements in this job description through conversational assessment. We evaluate your foundation skills (communication, strategic thinking), functional skills (CRM expertise, negotiation), and readiness for career progression.

Output: Personalised skills gap heat map showing strengths and priorities, estimated time to competency, neurodiversity accommodations.

DISCUSS Phase: Personalised Learning Pathway

Based on your DISCOVER results, Zavmo creates a personalised learning plan prioritised by impact: foundation skills first, then functional skills. We adapt to your learning style, pace, and neurodiversity needs (ADHD, dyslexia, autism).

Output: Week-by-week schedule, each module linked to specific job responsibilities, checkpoints and milestones.

DELIVER Phase: Conversational Learning

Learn through conversation, not boring modules. Zavmo uses 10 conversation types (Socratic dialogue, role-play, coaching, case studies) to build competence. Practice difficult QBR presentations, negotiate tough renewals, and handle churn conversations in a safe AI environment before facing real clients.

Example: "For 'Stakeholder Mapping', Zavmo will guide you through analysing a complex enterprise account, identifying key decision-makers, and building an engagement strategy."

DEMONSTRATE Phase: Competency Assessment

Zavmo automatically builds your evidence portfolio as you learn. Every conversation, practice scenario, and application example is captured and mapped to NOS performance criteria. When ready, your portfolio supports OFQUAL qualification claims and demonstrates competence to employers.

Output: Competency matrix, evidence portfolio (downloadable), qualification readiness, career progression score.