It was around early 2016 when I saw the call for proposals (CFP) for Write the Docs Prague, and I wondered what I could possibly have to share that folks won’t know about. I persisted, and submitted (rather meekly) an idea about an issue I was facing at work at that moment – bad screenshots that got given to me from engineers, and how amusing I found these while using them in the documentation I was working on.

My very first CFP got me 15 minutes of stage-time in Prague, of all places!

There’s a particular kind of dread that comes with the words “call for papers.” You’ve seen the CFP email land in your inbox, you’ve thought “I could probably talk about that,” and then you’ve closed the tab and gone back to editing someone else’s API reference instead.

You’re not alone, and it’s not really about confidence. Public speaking anxiety is consistently ranked among the most common fears people report, with roughly three-quarters of the general population experiencing some level of fear about speaking in front of a group. It’s not a fringe reaction; it’s the default one. Here in Australia, a Newspoll survey found much the same pattern locally: 23% of respondents named public speaking as their single greatest fear, trailing only the fear of death itself at 27%. So if the thought of a CFP makes your stomach drop, you’re in the company of roughly a quarter of the country, not some rare species of coward.

Some of that’s just nerves. Some of it’s a very Australian discomfort with anything that looks like standing up and saying “look at me”, you know, the Tall Poppy thing, alive and well in conference CFPs as much as anywhere else. But underneath the nerves, there are usually three specific excuses doing the talking.

What can I possibly talk about?

Here’s an honest answer, pulled from looking back at twelve-odd years of my own talk titles: your ideas don’t come from nowhere, and they don’t stay still. They evolve alongside what you’re actually wrestling with at work, which means the question isn’t “what can I talk about,” it’s “what have I been quietly obsessing over lately.”

I look at my own list and a few patterns jump straight out:

• Some topics I circle back to again and again: README documentation, of all things, shows up in 2018, then twice more in 2025 and 2026, nearly a full decade apart. Not because I ran out of new ideas, but because the README problem itself kept changing shape: what “good documentation basics” means in 2018 looks nothing like what it means once AI is in the mix. Same core obsession, new angle every few years as the industry moved underneath it, and the same struggles folks who are not writers run into.

• I took my “how to build an online technical writing portfolio” workshop went to STC Summit (where it failed absolutely miserably), then a STC Chicago meetup, then TechCommNZ, all within about eighteen months. I didn’t set out to build a signature talk: I gave it once because portfolios were a problem I kept hearing about from junior writers, it clearly struck a nerve, and organisers were seeing these same trends. Sometimes your “what can I talk about” answer isn’t a new idea at all, it’s noticing that a talk you’ve already given still has an audience.

• Then there’s the bigger pivot: everything up to about 202 was fairly squarely about API docs and craft (because I was working in that space) documenting developer portals, release notes, screenshots. From 2021 onward the topics shift toward advocacy, sustainability, portfolios, and now AI. That wasn’t a plan. It’s just what happens when you stay in an industry long enough: the questions you’re personally chewing on stop being “how do I document this thing correctly” and start being “how does this profession survive, and where is it heading.”

If you’re newer to tech writing, your version of that pivot hasn’t happened yet, and that’s fine.

The point is: don’t try to guess a topic in the abstract. Look at what you’ve actually been annoyed by, excited by, or stuck on in the last six months. That’s the talk. It’ll change again in a few years anyway.

Why would anyone want to listen to this?

This is the big one, and it’s almost always backwards.

You’re not boring because your topic is small, you’re boring if you talk about it in the abstract. Nobody wants a talk about “documentation strategy.” Plenty of people want to hear about the specific week your documentation strategy fell apart and what you did about it. The thing you’ve been quietly solving at your desk for months, the one that feels too ordinary to mention, that’s usually exactly what a room full of other tech writers hasn’t heard solved before.

You’re not fighting for attention against keynote speakers. You’re the only person in the building who’s lived your specific version of this problem.

This will take forever to prepare

It doesn’t, if you stop trying to write an essay and start trying to tell a story you already know. A 20-minute conference talk is roughly 2,500–3,000 words, much shorter than the blog post you’re reading right now, stretched out. And unlike a blog post, you already have the ending: you lived it.

The prep that actually eats time is agonising over slide design and rewriting your opening line eleven times.

Skip both early. Get the story down in plain language first: beginning, mess, resolution, and then worry about polish.

---

The best talks come from the worst projects

There’s a reason for that “annoyed by” instinct: bad projects make better talks than good ones, every time. Nobody wants to watch you present the project that went smoothly, on schedule, with a cooperative engineering team and a tidy handover. There’s no story in “it worked.”

The project that went sideways, the migration that broke twice, the stakeholder who wouldn’t sign off, the tool that quietly ate three weeks of your life, those are the ones with an actual arc: a problem, a struggle, a resolution (or an honest admission that it’s still not resolved). Audiences don’t remember your best day at work. They remember your worst week, and how you got out of it.

Many years back, I worked on documenting energy software. Going in, almost nothing was pinned down, what “done” actually meant, what quality bar we were writing to, when any of it was actually due. Nobody had agreed on the basics, and the documentation suffered for it: we messed it up.

That’s not a fun thing to admit in a retro, but it’s a genuinely useful talk. “What happens when nobody defines the deliverable” is a problem most tech writers have lived through in some form, and the honest version of that story, including the part where it went wrong is far more useful to a room full of writers than a polished account of a project that happened to have clear requirements from day one.

The bonus is that this stuff is easier to talk about than you’d think, precisely because it already has tension built in. You don’t need to manufacture drama for a slide deck, you just need to tell the truth about how bad it actually got, which is usually a relief to say out loud after months of pretending it was fine during the stand-up. The odds of getting in are better than they feel, once you do have an idea.

One long-running open-source conference, SeaGL, tracks this every year. In 2018, only 6.4% of all submitted proposals came from people who identified as first-time speakers, yet those first-timers ended up making up 13% of the accepted program.

In other words: organisers actively want new voices, and first-timers who do submit get accepted at roughly double the rate you’d expect from their share of the submission pile.

The bottleneck isn’t the selection panel. It’s people talking themselves out of hitting submit.

“But everyone’s already talking about this”

This is a fair objection, and worth sitting with rather than waving away. Let’s talk about AI and documentation. Right now that’s every second CFP submission at every conference on the planet, and you know it. So why bother, if the odds are you’ll be one of fifteen near-identical pitches about AI-assisted docs? Two honest answers.

First: a crowded topic isn’t a reason to stay silent, it’s a reason to get sharper about your specific angle. Organisers aren’t necessarily rejecting “AI and documentation” as a category, but they’re rejecting the tenth generic version of it. If your take is genuinely different (you disagree with the popular take, you tried the popular approach and it backfired, you have data nobody else has bothered to collect), that’s not competing in a crowded field, that’s standing out inside one, which is arguably an easier position than pitching an obscure topic nobody’s primed to care about yet.

Second: sometimes the honest answer is that it won’t get picked this round, and that’s fine. Not every talk idea needs to become a conference submission immediately. It can become a blog post first which is exactly what you’re building right now. A well-argued blog post on a saturated topic can outlast a dozen talks on the same subject, because it doesn’t need a conference committee’s permission to exist. Write it anyway, let it find its own audience, and if a conference angle emerges later because your post got some traction, you’ll have a much stronger pitch than “I also have thoughts on AI and docs.”

The move isn’t to avoid crowded topics. It’s to know when you’re bringing something the pile doesn’t already have.

What makes a pitch land: sell the sizzle, not the steak

The pitches that get accepted aren’t the ones promising a tools tutorial. Organisers see a dozen “how to use tool X” submissions every cycle but what stands out is a story. Something specific: a decision you made, a mistake you fixed, a fight you had with an engineering team and how you won it (or didn’t).

Here’s a trap worth naming explicitly: writers tend to pitch the problem, not the payoff. You know the mess intimately, so that’s what ends up in the abstract: three paragraphs on how broken your docs process was, one throwaway line at the end about how you fixed it. That’s selling the steak: raw, technically accurate, not actually what makes anyone hungry. A review panel skimming eighty submissions doesn’t get hooked by your problem. They get hooked by the promise of what they’ll walk away knowing.

A few years back, I walked into a room full of product folks at a popular one-day Product event in Melbourne full of false hope that they would find my pitch worth listening to, and selecting it for the day. The very essence of this one day event is that you pitch an idea of a talk in the morning, folks vote it if they want to hear it, and you end up getting a small space on the floor sometime during the day to expand on the idea. I got up on the stage and told the room that they had problems with their products and I had a possible solution. A quick 2 minute pitch which I thought I was good enough. I didn’t make the cut.

I had an ex-Manager sitting at the back of the room who came up to me during the morning break and told me “Good pitch, but you only spoke about the problem. You should have led with the solution and let them figure out the problem”. Worthy advice as any!

Flip the ratio. Lead your pitch with the payoff: the specific, useful thing the audience leaves with, and use the problem as just enough setup to make that payoff land.

• Steak: “Our documentation process was a mess: no ownership, no review cycle, engineers writing docs nobody read. I’ll cover the history of how it got that bad.”
• Sizzle: “I’ll show you the three-step review process that cut our doc bugs by half, and the ugly, embarrassing reason we had to build it in the first place.”

Same story, but completely different pitch. One reads like a confession. The other reads like something the audience can walk out and use on Monday morning, which is, ultimately, what a review panel is trying to buy on behalf of their attendees.

What speaking actually buys you

It’s worth being honest about why this is worth the discomfort in the first place, beyond “conquering a fear.” Public speaking is one of the few things in this profession that pays off in currency you can’t get just by writing good docs quietly in the background.

The first is professional equity. Writing is invisible by design, good documentation disappears into the product, and nobody claps for a well-structured troubleshooting guide. A talk is the opposite: it’s a public, attributable record that you understand your craft well enough to explain it to strangers. It is evidence that will probably earn you more kudos than anything else. When a hiring manager or a client is trying to work out whether you’re any good, a talk does work that a resume line never will.

The second is the network. Every conference room is full of other tech writers, engineers, and product people who are quietly solving the same problems you are, but you don’t actually meet most of them by sitting in the audience. You meet them because you spoke, and now three people are waiting to talk to you afterwards about the thing you just presented. That’s a faster way to build a genuine professional network than years of LinkedIn connection requests, because it starts from “I already know what you think” rather than a cold introduction.

The third is less obvious: speaking makes you bolder at work. Once you’ve stood in front of a room and defended an opinion about documentation strategy in front of strangers, pushing back on a product manager in a Tuesday standup starts to feel a lot smaller by comparison. The confidence doesn’t just stay on the conference stage, instead it follows you back to your desk, into the meetings where you used to stay quiet, into the moments where you’d normally let a bad decision slide because arguing felt like too much. Speaking is practice for having opinions in public. Work is full of moments that require exactly that.

Where on, from here?

If you’ve got an idea rattling around, write it down and keep an eye out for CFPs. Every time I feel tension, whether at work, or while watching a webinar, or at a meetup, I write it down (old style pen and paper ftw!), and revisit it when time comes to submit ideas for meetups or conferences.

Nobody’s expecting a TED talk. They’re expecting someone with something real to say, which, if you’ve been doing this job for more than a fortnight, is you. And whatever you pitch this time won’t be the last idea you have. Look back in five years and your own talk topics will probably have drifted somewhere you can’t predict from here: that’s not a failure of imagination, it’s just what happens when you keep showing up to the work.

The point isn’t to find the perfect talk. It’s to give the one you’ve got right now, and let the next one find you later.