Professional Development for Technical Writers: What to invest in as your career evolves

Technical writing isn’t one thing. It’s a field with a wide range, from instructional design and UX writing to API documentation and developer-facing content, and careers within it don’t always travel in straight lines.

Mine didn’t. Over time, the work pulled toward the more technical end: APIs, developer tools, AI platforms, documentation infrastructure. The skills that got me in the door were still in the room with me, but they weren’t the ones doing the most work anymore.

The work evolved

When I was starting out in technical writing, the work looked a lot more like design than it does now. I was deep in Adobe Creative Suite — InDesign, Illustrator, the whole stack. I learned how to think about layout, visual hierarchy, content structure, and how a reader moves through a document. It wasn’t incidental work. It was real, and I was good at it.

That foundation matters more than I sometimes give it credit for. Understanding how content is organized, how it serves a reader, how structure shapes comprehension — those aren’t creative-side skills that stop applying when you move into more technical work. They’re just the same principles in a different context. The InDesign knowledge itself isn’t what I use every day anymore, but the thinking behind it is baked into everything I do.

Early-career professional development tends to match the work in front of you. Mine matched a version of technical writing that was heavily visual, tool-driven, and output-focused in a tangible way. That made sense. I developed toward what the role required, and it served me well.

Part of that was following Tom Johnson’s blog, where he kept a running list of tools every technical writer should know. I copied the list into a notebook and worked through it deliberately, crossing items off as I learned them. I still have a photo of that page.

What started to matter more:

Understanding the technology, not just documenting it. Writing about APIs or cloud infrastructure without understanding how they work produces documentation that technically exists but doesn’t actually help anyone. I started pursuing technical depth deliberately. I worked through CS50 and earned my AWS Cloud Practitioner certification — not to become an engineer, but to become a better peer to the engineers I work with. When you understand the system, you catch gaps, ask better questions, and earn the kind of trust that makes collaboration easier.

Building processes, not just documents. Documentation debt doesn’t accumulate because writers are bad at writing. It accumulates because the systems around writing are broken — unclear intake, no review process, inconsistent handoffs from engineering. Learning to think in workflows and systems became as important as learning to write well. Maybe more so. If you’ve never thought about how to manage a writing project end to end (scoping, stakeholder alignment, review cycles, publishing), that’s a skill worth developing deliberately, not picking up by accident.

Working across functions, not just within one. Technical writing at the more technical end of the field is translation work. You’re sitting at the intersection of engineering, product, and the end user, and none of those groups speak exactly the same language or prioritize the same things. Getting better at navigating those dynamics — building credibility with engineers, framing documentation as a product concern — is development that compounds across every role.

Knowing the tools of the role. You don’t need to become an engineer. But you do need to be able to work in the same environment as one. Learning Git and version control, getting comfortable with Markdown, understanding how a docs-as-code workflow operates, being able to read an API spec — these aren’t advanced skills anymore. They’re table stakes for a growing portion of TW roles.

And then AI changed everything — including what “early skills” are worth

Here’s where the story gets interesting.

AI tools are reshaping what technical writers do at a practical level. They can generate drafts, summarize content, suggest structure, and produce serviceable documentation at a speed no human writer can match. For writers who haven’t developed technical depth, that’s genuinely threatening. For writers who have, it’s a force multiplier.

When AWS opened the AI Practitioner certification for early adopters, I signed up without waiting for the dust to settle. The credential was brand new and still taking shape. But that was the point. Getting ahead of a shift while it’s still forming is a different kind of investment than catching up after the fact.

But here’s what I didn’t expect: the shift toward AI has made the content design instincts I built in those Adobe Creative Suite years matter again in a new way.

AI can produce a lot of words. It cannot reliably produce well-structured, reader-centered documentation. It doesn’t inherently know when a topic is organized wrong, when a concept needs a better entry point, when a section is technically accurate but practically useless. Those judgments require the kind of deep content intuition that comes from years of thinking about how readers process information — the same intuition I was building when I was learning InDesign and studying document design in grad school.

Working effectively alongside AI now requires two things working together: the technical savvy to direct, prompt, and verify outputs, and the content instincts to know when something is off even if you can’t immediately articulate why. Neither leg of that is sufficient on its own. The technical depth helps you catch factual errors, evaluate accuracy, and work within the systems where AI-assisted documentation lives. The content instincts help you evaluate structure, flow, and whether the documentation will actually serve the reader.

The whole winding path turns out to have been preparation for exactly this moment. The creative foundation built the instincts. The technical development built the domain knowledge and fluency. AI is the context where both of those things have to show up at once.

What this means if you’re earlier in your career

The professional development that makes sense for you right now probably looks different from what will make sense in five or ten years, and that’s exactly how it should be.

Invest in what your current work requires. If you’re in a visually-oriented TW role, learn the tools deeply and understand the principles behind them, not just the mechanics. A foundational understanding of content design (how structure, hierarchy, and flow shape how readers process information) will serve you regardless of where your career goes. It travels further than any specific tool, and in an AI-assisted future, it may be one of the most valuable things you have.

But also pay attention to where the field is moving, and where you want to move within it. Technical writing is expanding toward more technical territory — developer documentation, AI products, docs-as-code workflows. If that direction interests you, start building toward it early, even if it’s not what your current job requires. The gap between “creative TW” and “technical TW” is crossable, and easier to cross gradually than to leap later.

Start building AI literacy now. Not just as a user of AI tools, but as someone who understands what they’re good at, where they fall short, and how to work alongside them without outsourcing your judgment. The writers who will thrive in this environment aren’t the ones who hand off work to AI — they’re the ones who know how to direct it, verify it, and improve it. That requires both the technical depth to work in the systems where AI lives and the content instincts to know when the output isn’t good enough.

The skills that matter now aren’t replacements for the ones that mattered then. They’re what the earlier ones grew into — and AI is exactly the place where all of it comes together.

Find your people

The field is moving fast enough that no one navigates it well alone. My earliest sense of professional community came from two directions at once: fellow TW grad students working through the same questions I was, and tech meetups in New Orleans where I was usually the only technical writer in the room. Both mattered. The grad cohort gave me peers who understood the work; the meetups kept me connected to where technology was heading, even when my day job didn’t.

STC was where I went for more structured development — webinars, events, a framework for thinking about the profession. LavaCon was a different kind of community: more strategically minded, sitting at the intersection of content and technology. My first session was in New Orleans, and it stuck. STC closed its doors in 2024, and that’s a real loss. But what it reinforced is something I’d already learned from those early meetups and grad school hallways: the habit of finding and investing in professional community matters more than any single organization that hosts it. The learning, the relationships, the sense of where the field is headed — that’s what community gives you. Seek it out wherever it lives.

Resources worth your time

Some of what follows I’ve read and returned to more than once. Some was surfaced by writers whose work I follow and trust. It’s not exhaustive. It’s what I’d actually recommend.

Even further along in my career, I still seek out foundational material. The field keeps changing, which means the basics keep getting rewritten too. There’s always a newer treatment of something you thought you already knew. But there’s another reason: the further along you get, the easier it is to operate on instinct without being able to explain the reasoning behind it. Reading the fundamentals gives you the vocabulary to articulate what you already know — so you can tell a coworker why something is the right approach, not just that it is.

Books

For understanding content and design fundamentals:

• Don’t Make Me Think – Steve Krug. Ostensibly about web usability, but the underlying principles about how people read and process information apply to any documentation context.
• The Non-Designer’s Design Book – Robin Williams. Technical writers benefit from a basic understanding of visual design. This is the most accessible entry point.
• Developing Quality Technical Information – Hargis et al. One of the closest things the field has to a canon text. Rigorous, practical, and still relevant.

For thinking about the modern TW role:

• Every Page is Page One – Mark Baker. Essential reading for anyone working in web-first, modular documentation environments.
• The Insider’s Guide to Technical Writing – Krista Van Laan. Practical and career-focused, especially useful early on.
• Making Things Happen – Scott Berkun. Project management written for people who aren’t PMs. If managing documentation projects feels like something you’re figuring out as you go, this helps.

People to follow

• Tom Johnson (idratherbewriting.com) – One of the most thoughtful voices in the field. His site includes a regularly updated resource on what skills technical writers should be developing — worth bookmarking and revisiting. His ongoing writing about AI and technical writing is especially worth following right now.
• Amruta Ranade – YouTube and LinkedIn. Accessible, practical content for technical writers navigating more technical roles.
• Fabrizio Ferri-Benedetti – Writes thoughtfully about docs craft and the evolving TW role.
• Bob Watson – Focus on docs usability and accessibility.

Certifications and courses

• Google Technical Writing Courses (free) – A solid foundational option, especially early in your career.
• API Documentation course (idratherbewriting.com) – Tom Johnson’s course is widely respected and directly applicable if you’re moving toward developer-facing documentation.
• AWS Cloud Practitioner – If you’re working in or moving toward technical roles, a foundational cloud certification gives you both credibility and genuine comprehension of the infrastructure you’re likely documenting.
• CS50x (Harvard/edX, free) – Computer science fundamentals. Not a TW-specific resource, but if you want to close the gap between yourself and the engineers you work with, this is one of the best places to start.
• AWS AI Practitioner – A foundational certification for understanding AI/ML concepts in a cloud context. Worth pursuing if you’re working in or adjacent to AI products. Complement it with hands-on use of AI tools and following practitioners who are writing seriously about AI and docs. The learning is happening in real time.

Hard skills worth building

• Git and GitHub – Version control is increasingly non-negotiable in technical documentation roles.
• Markdown – The lingua franca of docs-as-code workflows.
• Static site generators – Familiarity with tools like Docusaurus, Jekyll, or Hugo opens doors in developer-facing documentation environments.
• API literacy – Being able to read an OpenAPI spec and use tools like Swagger UI or Postman is a meaningful differentiator.
• XML/DITA – Still relevant in enterprise TW environments; worth understanding even if you’re not actively using it.
• AI prompting and output evaluation – Learning to prompt effectively for documentation tasks and, critically, to evaluate and improve AI-generated content is quickly becoming a core TW skill.

Communities and organizations

• Write the Docs (writethedocs.org) – The most active modern technical writing community. The Slack group in particular is useful for real-time questions, job leads, and staying current on how the field is moving.
• LavaCon – A conference and community at the intersection of content strategy and technical communication. Worth attending if you can; worth following if you can’t.
• The Good Docs Project – Open source templates and documentation standards. Useful for writers moving into more technical environments who want to build on established best practices.