I met CT Smith while looking for guests for Coffee and Content, the talk show I co-host with Patrick Bosek of Heretto. Partway through our conversation, she mentioned a book she had written: WTFM: A practical guide for standing up docs at a startup.
WTFM is written for the people who end up owning documentation without choosing the job: founders, support leads, and the engineer who keeps answering the same question in Slack.
Smith has built documentation programs at companies ranging from a seed-stage fintech to a recently public analytics company, and she watched an acquired startup’s docs grow into a content team of hundreds of writers and tens of thousands of pages. She wrote this book for the moment before that kind of growth, and she kept it short enough to read in one sitting.
What A First-Time Documentation Manager Gets From The Book
Most of Smith’s recommendations arrive with stories from her own career, which is what makes them stick. Her case for funding documentation opens with a contract stalled in redlines until the customer’s legal team saw a specific feature publicly documented. She then hands readers a worksheet that turns support tickets and engineering escalations into a monthly dollar figure leadership can find value in.
Her argument for writing decisions down rests on a rule in her own style guide that nobody could explain. She traced it to a year-old Slack message and learned it existed to work around a bug that had since been fixed. Her AI chapter, “AI Doesn’t Care About Your Customers,” recommends using AI to build ordinary tools such as link checkers and validators, so routine checks don’t need AI, and treats every AI draft as unpublishable until a subject matter expert signs off.
She also tests her own writing advice against AI systems and publishes the results.
When the docs outgrow volunteers, Smith makes the case for hiring a writer to own the whole program, with a headcount pitch that frames the hire as making documentation “someone’s job instead of everyone’s problem.”
Why Experienced Documentation Leaders Should Read This Book
Experienced pros will find value in two places. Smith’s stories and the included worksheet give them language to speak to colleagues who haven’t run a tech docs program before.
In Chapter 5, Smith describes documenting version 2 of an API whose supporting service had no version 2. The note saying so was accurate, but it sat deep in the guide, and customers started the task before they reached it. Her fix was to move the condition to the top. Her own testing found that vague scope language such as “where applicable” dropped AI accuracy from 97 percent to as low as 48 percent.
That fix works on a page a person reads from the top. AI retrieval systems pull chunks out of pages, and a condition placed at the top can be separated from the step it governs. As products and versions multiply, keeping applicability attached to each instruction becomes one of the harder technical documentation problems. Smith’s small story is a good way to explain it to colleagues who assume AI accuracy depends only on whether the docs are correct.
Who Should Read WTFM?
Anyone who has inherited a documentation site, or is about to fund one, should read this freely available online book. Smith says plainly that it isn’t a definitive guide to writing for AI, information architecture, or doc testing; she includes a reading list for those subjects. What the book does is show new documentation owners what to build first and explains why.
Smith ends the book with a Tom Waits line about not letting the weeds grow taller than the garden. In a startup’s docs, the weeds are usually outdated pages and decisions nobody wrote down. As the company grows, a hardier weed shows up: instructions that are correct, but reach customers whose product version or setup they don’t apply to. Smith’s advice gives doc teams a good place to start to tackle both.
Read the full text at wtfmbook.com, or buy a copy through the link on the site. 🤠