TCUK25 Programme

Surviving the savanna: adapting to an evolving career landscape

Given by: Rahel Anne Bailie

What lies ahead for technical communication as a profession? This is not the first time we’ve seen a large shift in the industry, though this shift feels more seismic than previous ones. There are no shortage of conflicting predictions. Some are of doom and gloom; others predict business as usual. All of us are keeping a careful watch for the fissures in the business landscape. Rahel Bailie brings her decades of workforce experience to the stage with survival strategies of which even Bear Grylls would approve.

How to train your Dragon (chatbot)

Led by: Warren Singer

In this practical session, Warren will demonstrate and take the audience through the practical steps of how to implement their own AI Chatbot, for use on a website, or as a support for end users of a company’s technical documentation. The workshop will leverage insights and experience his team has gained in implementing their own AI chatbot.

The session will cover:

• Introduction to the use of Generative AI chatbots as part of a content strategy
• Select an AI chatbot tool
• Training the AI chatbot on your content
• Customising the appearance and behaviour of the chatbot
• Rolling out the chatbot/embedding within a website
• Using chatbot analytics as a tool to track user engagement with your content
• Customising your content and the chatbot rules to improve the accuracy and effectiveness of the chatbot
• Using your own chatbot as a tool to support content writing
• Warnings: what can go wrong if the chatbot is not properly set up and configured. Some case study examples for discussion
• Q&A

Requirements

TBC

Let’s Make a Video! – Creating Techcomm Video Content with Google Veo 3

Led by: Ellis Pratt

With YouTube Shorts reaching 2 billion monthly active users and the popularity of TikTok, short-form video is becoming another important channel for effective technical communication. This hands-on workshop will guide participants through the practical process of creating professional video content using the Google Veo 3 AI video generation tool.

We’ll explore how you can use it to create content for elearning, onboarding, and Developer Relations. Participants will leave with actual video content they’ve created during the session and an understanding of the workflow for ongoing video production in their technical communication roles.

Requirements

Delegates will need:

• A laptop that can connect to wifi
• A Google account

Please note: During the workshop, delegates will sign up for a Google Veo 3 account. New users get 100 credits for free, but if they use up the credits and want to generate more videos, they will need to pay to get Google One, which costs around $20. Delegates can cancel their Veo 3 account after the workshop, so they aren’t billed in the following months. 

Are we Webmasters? When Did That Happen?

Presented by: David Bailey

Particularly useful for anyone writing documentation for delivery online. A very basic level of experience of web publishing and management functions will help.

Are we Webmasters?

Publishing to multiple exotic formats like PDF, WinHelp, or physical printing is now consigned to history. Most of us have standardized on Web HTML output, typically published on a website. So, from a user viewpoint, I now create and manage specialised Web content.

This matters because how we transmit and consume content matters – the medium is the message. Usability is key with Web content, more so than other formats. Also, we can do a lot more with Web content to communicate with our users, such as:

• Using Analytics instead of surveys, to identify outliers and guide our work.
• Connecting seamlessly to other resources like our corporate website, our code repos, and other functions.
• Making it easier to get feedback – for example “edit in place” functions like creating a GitHub PR for docs.

None of this is a shock, but it all impacts our roles as tech writers. We stop focusing purely on the content; we start focusing on making the content “rich.” We stop sending out user feedback surveys; we start using real-time analytics. We don’t ask readers to do the training; we embed video snippets in our docs (and track their use).

So our skillset changes. We need to know about SEO, site integrity and security, analytics, accessibility, and user experience standards. We should have at least some knowledge of XML, HTML and JavaScript. We should understand site generators, server-side scripts, and other technologies. And if we Google “Typical webmaster skills”…

So, we’re webmasters. What does this mean?

ASD-S1000D – What is it, how is it managed

Presented by: Terry Howard

Particularly useful for any communicator interested in learning the process to manage an ASD-S1000D project.

ASD-S1000D is an international specification for technical publications. In this presentation, Terry will walk the audience through the seven primary stages, demonstrating each process using live project documentation.

The presentation will culminate in demonstrating a published interactive electronic technical publication, including 3D animations linked directly to the XML procedural schema.

You will get an understanding of the key principles necessary to manage an S1000D project, including:

• analysing the project business rules
• selecting the Information code’s
• designing the data management requirements list
• originating the dataset
• validating the dataset
• publishing and deploying a fully built IETP

Automate All the Things? The Present and Future of Automation in Technical Writing (AI)

Presented by: Ellis Pratt

Particularly useful for anyone interested in the current state of automation or having to make strategic decisions about it.

Many technical communicators use some degree of automation, even if they’re not aware they it. But what are they missing, and what comes next?

We will look at the present: what people are automating today. We’ll look at the current state of automation in technical communication, at different stages of the technical writing process.

We’ll cover some of the tools that can improve efficiency and consistency. This will include ones we use in-house, as well as others that we’ve seen used by other technical writing teams.

We’ll also look at the future: where automation is heading, and where the gaps remain. We’ll unpack emerging trends like Model Context Protocol (MCP) and other AI agents, using APIs, and considering the ways they could help technical communicators.

We’ll also address the important considerations that come with automation: the need for the human-in-the-loop, the impact of technical communicators and the organisation, and the potential pitfalls.

This session balances practical implementation guidance with strategic thinking about the future of our profession.

You will leave with a clear understanding of what’s possible today, what’s on the horizon, and how to make strategic decisions about automation in their own teams.

Content Planning in Action: How Structure Drives Consistency in Multi-Product Documentation

Presented by: Denise Marshall

Particularly useful for anyone who’s faced with a large documentation set that needs to be restructured.

This talk will be a high-level overview of what a content creator needs to know to wrangle a large amount of content. Denise will describe a hypothetical company which is pulling together a collection of documentation from many different teams covering multiple products and in many different formats to create a unified help centre.

The presentation will be a guide to how documentation might be overhauled to ensure consistency across the unified doc set. The talk will be delivered in two parts: Content planning, and the restructuring process.

Crowdsourcing insights into complex documentation: Highly useful and productive documentation feedback from Slack

Presented by: Beth Morgan

Particularly useful for anyone who writes documentation with internal users.

CICS Transaction Server is a major mainframe product for IBM with a rich 55-year history, and, as it is today, over 100,000 pages of documentation.

Working on the documentation for CICS TS means maintaining widely used documentation that is not only, in some places, several decades old but also continues to grow with each release cycle. With its ever-increasing size and complexity, it can be easy as writers to miss items that need updating, correcting, or transforming to provide better value.

Our approach was simple. Host an internal documentation feedback channel in the main messaging tool, Slack, where colleagues in support and development can share issues, corrects, and suggestions for the CICS TS documentation. The issues raised are then examined in Jupyter notebooks, where we can examine the bigger picture and determine any patterns for the types of issues coming through – highlighting possible problem areas in the documentation, as well as revealing future focus areas or educational opportunities.

By crowdsourcing feedback from those either directly working with the documentation or resolving client problems, we can continue to improve the content we provide, and in the process, not only strengthen our skills as individuals but ultimately build trust with our customers.

In this presentation, we will discuss how this is achieved, the data we gather from it and what that can tell us about our documentation, where we can plan to take it next and how you can utilise a similar approach for your own benefit.

Docs-as-Code in a Small Team: Practical Lessons from the Trenches

Presented by: David Jones

Particularly useful for anybody thinking of implementing docs-as-code in a small organisation.

For good reasons, Docs-as-code has been “the next big thing” for over a decade. It integrates documentation into engineering workflows, improves efficiency, and maintains quality. But how easy is it to implement, especially as a small team?

When tasked with documenting new SaaS products, I set out to adopt a docs-as-code approach. I trialled static site generators and initiated a book club with the dev team to read Docs Like Code by Anne Gentle, thus ensuring we shared a common language. The engineers, already building CI/CD pipelines, were eager to integrate documentation into their workflows and contribute alongside the code. Eventually we settled on using Docusaurus as our platform of choice.

With Git and Azure DevOps already in place, we were well-positioned to begin. In this talk, I’ll share what additional tools and processes we needed, including how we incorporated Mermaid diagrams and OpenAPI specs to enhance clarity and usability.

Was it the seamless solution that blog posts often promise? Not entirely, but it was transformative. This session will explore the practicalities, pitfalls, and payoffs of implementing docs-as-code in a small team and also offer insights for others considering the same path.

Driving documentation as an engineering practice

Presented by: Daniele Procida

Particularly useful for people who need or want to influence the practices of an organisation.

I joined a large software engineering company in 2021, when documentation had dropped very low in its engineering priorities.

I was asked to transform every aspect of its documentation: output and efforts, what it aims for, what it considers good, how it delivers it, how the organisation thinks about documentation’s purpose and value.

To do that, I needed hundreds of people to accept and internalise the values, standards and priorities that I saw. I needed documentation to be accepted, across the organisation, as a first-class engineering discipline.

Four years later, documentation is firmly established as an engineering priority and practice.

This isn’t the story of “How I…”. Rather, I want to offer the methods and approaches I used to make my problems everyone else’s problems, and drive documentation up the company’s agenda.

I think they will be useful for anyone – working at any scale – who needs some help in shifting the documentation priorities of a reluctant organisation that also has plenty of other competing priorities on its mind.

Fostering compliance in a regulated environment

Presented by: Joaquim Baptista

Particularly useful for anyone facing users that avoid following instructions, especially in a regulated environment. You will learn to motivate users by articulating the purpose of those instructions.

Working at a regulated environment such as a bank, even in software, requires satisfying different areas of compliance. Different organisational structures ensure compliance with different areas of regulation, by mandating the existence of evidence, imposing checkpoints, and auditing projects and teams.

Coming from non-regulated software companies, my first realisation was that almost all “procedures” were in fact processes, which benefited from clear timelines that clarifiy the interactions and responsibilities of all the actors involved.

Some developers perceive these processes as overly bureaucratic and as barriers to real work being done. Therefore, they may explore loopholes and take shortcuts when possible. This is surprising in a regulated environment, where non-compliance may expose the bank to fines from the regulators and may result in swift disciplinary action against employees.

Developers that avoid official processes fail to make the connection between the bureaucratic steps they are required to follow and the hight-level regulations and guidelines they were taught to follow.

To make that connection explicit, I wrote two sections for each compliance area:

• Expected outcomes of that compliance area, as perceived by the bank and the regulators. This specifies the ultimate purpose of the bureaucratic processes.
• Principles that the bank wants to observe while pursuing the outcomes. These principles may prohibit some ways of working, or they may describe desirable ways of working.

The principles justify the existence of the bureaucratic processes as a way to achieve the desired outcomes.

For a certain area of the bank, reports feed auditing by describing how that area caters to a specific area of compliance. These reports now start with the expected outcomes and guidelines, followed by the processes in place. Some reports may also offer proof that the processes were performed successfully.

Gathering information for transformative content design

Presented by: Beth Morgan

Particularly useful for anyone looking to create fresh content or improve existing content.

Whether improving existing documentation or creating anything new, it’s beneficial to plan beforehand, understand what’s missing, and gather all the information required while considering the user experience at every opportunity.

An As-is provides a visual way of examining the content’s current state as it currently is and early in the content development process, spot where the gaps are. With an Information Needs approach, we can capture broader considerations from users from multiple perspectives as we collaborate with subject matter experts to take note of what these users need to do and what they need to know.

With a more thorough investigation into what is required to satisfy the user journey, we can make more informed decisions for the design and development of new or to-be-improved content.

The presentation will be in two parts. To start with, we will go through these two key content design methods, thinking further about what they are, how they are run, and where to get started. In the second part, we will demonstrate the process and collaboration of an information needs through a workshop activity.

Identify and control the risks of GenAI in your content ecosystem

Presented by: Frances Gordon

Particularly useful for any team now using LLM tools who need a way of clearly communicating risks internally and to their leadership teams.

Generative AI promises efficiency gains, yet a single hallucinated fact or leaked prompt can trigger legal, reputational or security fallout. Many teams rush to publish “AI usage guidelines” first and patch risk treatment later. Or worse, risks are never properly identified or communicated at all. This talk gives a simple risk-management process to help you build a consensus within your team, and clearly communicate risks to leadership.

Drawing on ISO 31000 and other established risk management standards, the session walks through six practical steps with time for discussion in groups:

1. Establish the context: define corporate risk appetite, map laws and regulations such as privacy and accessibility requirements, capture where GenAI touches existing content workflows, and build a shared glossary so Legal, IT and tech writers have a common understanding.
2. Identify the risks: use cross-functional workshops and real use cases to identify risks in categories such as operational, compliance, security, reputational and strategic.
3. Analyse the risks: score each hazard for likelihood and impact in a simple matrix; highlight the threats worth major investment.
4. Evaluate the risks: decide whether to accept, mitigate or avoid.
5. Treat the risks: select proportionate controls (such as RAG models, workflow gates, prompt-hygiene checklists, human-in-the-loop reviews, vendor assessments); link each control back to the risk register.
6. Monitor and review: track error rates, re-work hours and team confidence, then iterate the framework as tools and regulations evolve.

You will receive two take-home files: a GenAI risk-register template and a brief guide for turning that register into a phased, evidence-based AI content policy.

You can then return to your team equipped to run calm conversations about GenAI content risks, and give leadership the information they need to align content risks with other organisational risks.

Leading and managing a cross organisation, cross-location content team

Presented by: Bethany Simpson

Particularly useful for leaders of technical writing teams, and those who work in them.

Leading and managing a technical writing team can be difficult, but imagine a team that is across different organisations and stretched across the globe with differing content standards, procedures, and different timezones.

This session covers setting ways of working, the challenges faced and how to overcome them. Bethany will talk about using the differences of a technical writing team to create hybrid processes and ways of working, while creating a brand new technical content documentation collection.

Meta Design Systems: Standardizing and communicating product decisions to generate alignment and improve product consistency

Presented by: Ed Orozco

Particularly useful for UX writers needing to make sure product documentation, marketing content and product copy are consistent, as well as anyone affected by shared product decisions.

Design systems are great for maintaining consistency in products. The same principles can apply to how companies share information among teams.

One of the most common pain points startups face as they scale is the fragmentation of communication. Information becomes siloed, and the systems meant to keep things under control are insufficient at best and non-existent at worst.

In this session, we’ll look at simple examples of how to create systems that organise and share product decisions across teams. These examples will use tools commonly adopted by tech startups and scale-ups, but the underlying principles are tool-agnostic.

This talk will be especially useful for PMs, engineers, and designers at startups and scale-ups who have experienced firsthand the chaos companies face as they grow.

Takeaways:

• A tool-agnostic framework for tracking and sharing product decisions across teams
• Examples of practical design artifacts to inspire and enhance the framework’s impact

“Plough, through, rough, cough?” Why English spelling doesn’t play fair

Presented by: Jo Stichbury

Particularly useful for anyone who loves the English language, enjoys crosswords or obscure facts about language, or has ever taught anyone how to read and spell!

Have you ever looked at a word written down and thought, ‘Isn’t that a weird spelling? Is it right? Why does it look so odd?'”

In this presentation, I will take us on a journey through some of the quirks of the English language, and why it’s sometimes hard to spell words according to their sounds. I’ll give some reasons why it is the way it is, and explain the strategies needed to decode and encode correctly.

I will begin with some puzzling examples of English words and inconsistencies (hence the “plough, through, rough, cough” in the title).

I will then share data on how long it typically takes native English-speaking children to learn to read and write compared to children learning languages with shallow orthographic spelling systems.

I’ll then cover the Great Vowel Shift (GVS). I will explain the historical phenomenon that reshaped English pronunciation but left spelling behind. You’ll learn how the GVS contributed to mismatched spellings, homophones, and some of the irregularities that persist today.

Finally, I will explore a methodology for mastering English spelling by focusing on phoneme combinations, decoding patterns, and the exceptions.

By the end of this presentation, you’ll gain a fresh perspective on why English spelling is so inconsistent and hard to learn, uncover the fascinating historical quirks that shaped the language, and walk away with an appreciation for primary school teachers everywhere. Join me for an engaging and enlightening session!

The philosophy of technical communication: how does your worldview frame your practice?

Presented by: Malcolm Cawood

Particularly useful for anyone who is curious about philosophy, critical thinking, and different theories of communication.

Do you ever think about the philosophy of technical communication? When I did a Google search on this subject, its AI overview said: “The philosophy of technical communication centres on the effective and efficient transfer of specialized information to a specific audience to achieve a practical purpose”. This is similar to the ISTC’s statement about the “purpose of our profession”. But “purpose” is not really about the underlying philosophy. It may well be a useful guiding principle but it does not engage with the ways of thinking that frame technical communication.

In this presentation, I want to explore the theories of knowledge (epistemology) that underpin the discipline. These theories are perhaps not always explicit. For example, is technical communication a neutral conduit for transferring facts to users (a view rooted in the Shannon and Weaver transmission model and philosophical realism). Or should we be thinking more in terms of rhetoric and reception theory, which sees meaning as socially constructed and makes any kind of communication more problematic? As a provocation perhaps, I suggest that John Carroll’s Minimalism sits more in the constructivist\rhetorical space than realist\transmission perspective.

There are no specific recommendations in this presentation. Rather, using a mix of theory and real-world examples, I hope to foster reflection, critical thinking, and philosophical exploration in a way that may well impact directly on your own practice. It might also provide pointers for future career development.

The Technical Writer’s Skill Tree

Presented by: Vladimir Izmalkov

Particularly useful for Technical writers and those willing to become one.

I want to explore the role of a technical writer – and how different it can be from one person or company to another. Having met many technical writers and worked as one for years, I’ve seen just how diverse the profession is.

I believe a technical writer’s skills can be visualised as a ‘skill tree’, much like in an RPG (Role Playing Game: a video game genre, often characterised by character development). Progression in one branch is often independent of the others, meaning each writer can shape their own path to success and even the goal. Some might focus on advancing linguistic skills, perfecting wordcraft. Others gravitate toward technical challenges – mastering documentation tools, automation, or deepening their subject-matter expertise. And some prefer to become well-rounded generalists, slowly developing skills across many areas.

To be most effective, I recommend building your own skill tree: assess your current strengths, decide what you want to “level up,” and chart your growth. This approach helps you understand what kind of technical writer you are, where you excel, and what you want to achieve next.

Armed with this clarity, you can work with greater confidence and apply your skills more effectively. It also shows how technical writers can remain competitive in the age of AI and LLMs – by cultivating a unique blend of skills across branches, combining responsibility, deep expertise, synergy, and autonomous decision-making in ways that machines can’t replicate (yet?).