Open the documentation of a software company you'd like to work for and look for three things: a "last updated" date more than a year old, a getting-started page that stops working at step four, and a community forum where the same question has been asked nine times. Any one of those is a reason for an engineering manager to hire a technical writer, and you can see all of them from the outside.

That visibility is the entire method. Instead of sending a portfolio to a hiring portal, you find one specific page that is hurting the product, rewrite it, and send the clearer version to the person who owns it. You are not asking for work. You are showing the work.

Who hires technical writers

In a company without a documentation team, the buyer is an engineering manager, a head of developer experience, a product manager, or the founder at a small startup. Support leaders sometimes sponsor docs too, because every unclear page is a ticket. Companies with 15 to 200 employees that ship an API or a developer product are the best fit: big enough to have users who need documentation, small enough that nobody owns it. Also look at hardware and medical device firms, which need manuals and instructions for use, and at companies preparing an enterprise sale, where customers ask for security and integration documentation.

Triggers you can see from outside

A release is the most reliable trigger. Read a product's changelog or release notes and compare them to the docs. If a feature shipped last month and the reference page doesn't mention it, someone is about to get support tickets. Other signals: a GitHub repository with many issues labeled "documentation"; a sample code snippet that no longer runs against the current API; a job post for a technical writer that has been open for two months; a forum thread titled "how do I authenticate" with no accepted answer. Write down the exact page and the exact problem. Specifics are the whole pitch. See getting customers for a dev tool startup for what the buyer is up against on their side.

The one-page rewrite

Pick one page, preferably a task page with a clear beginning and end: authentication, installation, a first API call, a webhook setup. Rewrite it so a developer new to the product can finish the task in one sitting. That usually means fewer steps, a working code sample that you have actually run, one sentence of purpose at the top, and a line about what goes wrong and how to fix it. Don't change facts you can't verify; mark anything you're unsure of for the engineer to check. Keep the rewrite to the length of the original or shorter.

For example: a payments API has a page titled "Authenticate with API keys." It is 14 numbered steps and mixes test keys with live keys. Your version cuts it to six steps, puts the key types in a small table, adds a working curl request with a placeholder key, and adds a short "if you get a 401" section. You time yourself: two hours. The engineering manager reads it in three minutes.

Treat the rewrite as your own work product. Don't publish the company's content or post it anywhere public, and don't paste in proprietary material that isn't already on their public docs. Send it privately as a Google Doc or a pull request if they accept contributions.

A first email to an engineering manager

Subject: A clearer version of your API authentication page

Hi Jonas, I'm a technical writer who works with API products. I was setting up Tessera's SDK last week and the authentication page lost me at step 7 (test and live keys appear in the same list). I rewrote it as six steps with a working curl example and a short section on 401 errors. It's attached. Please check the facts, since I only know what your public docs say. If it's useful, I'd be glad to talk about a small docs project, such as the reference pages for the new webhooks.

Mira Delacroix, Delacroix Docs, 9 Cannon Row

Add your address and an opt-out line, as CAN-SPAM requires for commercial email. And do not claim a specific page is broken unless you tested it. Accuracy is your profession, so the first claim you make has to be right. Related reading on similar writing work: how to get clients as a copywriter covers the marketing side, and freelance developer clients shows how a technical contractor approaches the same engineering teams.

Following up with a short outline

If there's no reply after a week, send a different message: a one-page outline for the next project. Name three pages, say what is wrong with each, and say how long each would take. "Authentication, webhooks and the error reference: roughly 12 hours." That turns a nice gesture into a scoped project. Engineering managers can approve a small project without a budget meeting. For low-volume outreach that still feels personal, startup personalisation at low volume has a useful method.

Moving to a monthly retainer

After the first project, propose a retainer tied to the release schedule. Documentation is never finished; every release leaves something stale. A common structure is a fixed number of hours a month. At 20 hours a month and $150 an hour, that is $3,000 a month, or $36,000 a year from one client, and you need three to four of them to replace a full-time salary. Say what the hours cover: new release docs within a few days of shipping, a monthly review of support tickets for doc gaps, and a quarterly cleanup of old pages. Put a notice period in writing.

Spotting stale docs takes patience, and finding the right engineering manager takes more. Rocketship can find those managers by name, send your rewrite email from your own Gmail, and follow up; see the AI workers. The sample-first idea also works for 3D printing, where a sample part does what your rewritten page does.

Rocketship finds the buyers, emails them from your own Gmail, follows up, and books the meeting on its own. Plans that get you customers start at $24.99 a month (Launch), and both Launch and Frontier start with a 7-day free trial, card required.