Our Onboarding Took 6 Weeks Because Nobody Wrote Anything Down — the 7-Step Technical Writer Hire That Cut It to 9 Days

For three years I treated documentation as something we would fix when things calmed down. The signal that it had become expensive was not a complaint. It was noticing that our two most senior engineers each lost roughly a day a week to questions they had answered before, and that a competent mid-level hire took about six weeks to merge anything meaningful. We had been paying for bad documentation the entire time, in the most expensive currency available. Here is the seven-step process I used to hire the person who fixed it, and the two steps I would not skip again.

Step 1: Measure What Bad Documentation Is Costing You

Do this before you write a job description, because without it you will be arguing for a headcount on the basis of a feeling, and you will lose that argument to a feature engineer.

Two measurements are enough:

• Median time from joining to first merged pull request, across your last five to ten engineering hires. Pull it from Git history. It takes an hour and it is uncomfortable reading.
• Repeated questions. For two weeks, tag every question in your engineering channels that has been asked before. Do not automate this; the crudeness is fine. The count and, more persuasively, the seniority of the people answering is your business case.

Ours came out at six weeks and roughly eleven recurring questions a week, with senior engineers answering most of them. Once those two numbers existed, the headcount conversation took ten minutes.

Step 2: Choose Which Documentation Job You Are Hiring For

“Technical writer” covers at least three jobs that require different people. Picking one is the difference between a hire that works and a hire that produces a beautiful documentation site nobody needed.

We needed the first one and very nearly hired for the fourth, because the strongest candidate early on was a superb product-documentation writer. The writing skill transfers between these; the code-reading skill does not.

Step 3: Write a Specification That Names the Systems

Most technical writer job adverts in Singapore are interchangeable: “excellent written English, attention to detail, experience with documentation tools, ability to work with engineering teams.” Every candidate matches, so you learn nothing, and good candidates cannot tell whether they would enjoy the job.

Name the specifics instead. The stack. The audience. The tooling you actually use, including whether documentation lives in the repository. And critically, the first three documents you expect to exist — for example, a local environment setup guide, a walkthrough of how a request travels through your services, and a reference for your two most-used internal APIs.

Naming the first three deliverables does two useful things. Serious candidates ask sharp questions about them, which is your first signal. And it prevents the most common failure mode of a documentation hire, which is six months spent on tooling migration and information architecture while the onboarding problem stays exactly where it was.

Step 4: Source Across Three Pools

Singapore has a smaller dedicated technical writing pool than its engineering pool, which means posting a job advert and waiting works poorly. Three pools are worth working deliberately:

• Developers who moved into writing. The strongest pool for internal documentation and API reference. Usually self-taught as writers, and usually better than they think. Look for people who maintained a well-documented open-source project or ran an engineering blog.
• Writers from regulated industries. Finance, medtech, aviation and government work in Singapore produces writers who are rigorous about accuracy and version control. They may need six weeks to get comfortable with a modern developer toolchain, and in my experience they get there.
• Developer advocates. Right pool only if adoption is the bottleneck. They typically want a public-facing remit, and hiring one into a purely internal documentation role usually ends in an early resignation.

On location: this role works well as a distributed hire, better than most. The work is asynchronous by nature and the deliverables are inspectable. If you are considering that, our guide to building a remote dev team in Singapore covers the coordination model, and our UAE colleagues’ remote onboarding process is the best companion piece, since onboarding is the problem you are solving.

Step 5: The Paid Exercise on Your Real Codebase

This is the step that decided our hire, and I would not run the process without it again.

Take one genuinely undocumented thing — an endpoint, a deployment process, a flow that only one person understands. Give the shortlisted candidate repository access under NDA, four hours, and a clear brief: document this well enough that a new engineer could use it unaided. Pay them a fair rate for the four hours. In Singapore this typically costs a few hundred dollars per candidate and it is the best-spent money in the entire process.

Then grade two things, weighted roughly equally:

• The output. Is it accurate? Could someone follow it? Did they distinguish between what the system does and what it is supposed to do?
• The questions they asked. This matters as much as the document. Strong candidates come back with a small number of precise questions that reveal they have read the code and found the genuinely ambiguous parts. Weak candidates either ask nothing, which means they transcribed, or ask everything, which means they did not read.

Our eventual hire asked three questions in four hours. The third one identified a bug in the endpoint she was documenting, which none of us had noticed. That was the moment the decision was made.

Step 6: Test the Interview-an-Engineer Skill

Here is the thing I did not understand before this hire: a technical writer’s job is mostly interviewing, not writing. The information lives in engineers’ heads, and those engineers are busy, sometimes impatient, and frequently unable to tell what is obvious to them and not obvious to anyone else.

So test it directly. Put the candidate in a thirty-minute session with one of your busiest engineers and ask them to extract a process they can then write up. Brief your engineer to behave exactly as they normally would, including being a little short on time.

Watch for whether the candidate can interrupt politely to slow someone down, whether they notice when an explanation skipped a step, and whether they ask “what would happen if I did not do that?” — the question that surfaces undocumented assumptions faster than any other. Afterwards, ask your engineer whether they would be willing to do that session again next week. That answer predicts a great deal about whether the documentation will actually get written.

Step 7: Set 90-Day Targets on the Step 1 Metric

Do not set the probation goal as a documentation site, a page count, or a migration to a new tool. Every one of those can be completed brilliantly while your onboarding stays at six weeks.

Set it against what you measured: median time to first merged pull request and repeated questions per week. Both numbers are noisy and move for reasons unrelated to documentation, so judge direction over a quarter rather than precision over a month. But they are the numbers that justified the hire, so they are the numbers that should judge it.

On compensation, so you can plan: a technical writer in Singapore typically sits at 4,500 to 6,500 SGD per month at junior to mid level, and 7,000 to 11,000 SGD per month for a senior writer who reads code and works unsupervised with engineers. Developer experience roles that add code samples and community work run higher, often 10,000 to 15,000 SGD. Add employer CPF for citizens and permanent residents. The salary calculator gives current bands, and if this role sits inside a larger build, our enterprise software development in Singapore breakdown shows where it fits.

A contract or fractional arrangement is a perfectly respectable first move here, and often the right one. It lets you test whether the onboarding number moves before you commit a permanent headcount, which is exactly the discipline you would apply to any other bet of this size.

Three Mistakes I Made

I hired for tooling instead of comprehension. My first shortlist over-weighted experience with specific documentation platforms. Tooling is learnable in a fortnight. Reading an unfamiliar codebase and knowing which part will confuse a newcomer is not.

I did not pay for the exercise at first. I asked two candidates for unpaid sample work and both declined, correctly. The people confident enough to decline unpaid work are disproportionately the people you want.

I pointed the first month at the wrong audience. We had our writer start on customer-facing material because a stakeholder asked loudly. That work was fine and it moved neither of our two numbers. When we redirected to internal documentation, the onboarding figure moved within one intake.

If you are also rebuilding how new engineers land, it is worth reading alongside our Singapore guide to screening developers in seven steps, and the UAE team’s first 90 days onboarding framework, which pairs naturally with the targets in step 7.

Frequently Asked Questions

What does a technical writer cost in Singapore in 2026?

A technical writer in Singapore typically sits between 4,500 and 6,500 SGD per month at junior to mid level, and between 7,000 and 11,000 SGD per month for a senior writer who can read code and work unsupervised with engineers. Developer experience and developer advocacy roles that combine writing with code samples and community work run higher, often 10,000 to 15,000 SGD per month. Add employer CPF contributions for Singaporeans and permanent residents. Contract and fractional arrangements are common and often sensible for a first hire, because they let you test the impact on onboarding time before committing to a permanent headcount.

Should I hire a technical writer or ask my engineers to document more?

Asking engineers to document more has been tried at nearly every company that ends up hiring a writer, and it fails for a structural reason rather than a motivational one. Documentation quality depends on knowing what a reader does not know, and an engineer who has just built a system is the worst-placed person to judge that. They have lost access to their own confusion. A technical writer is valuable precisely because they arrive ignorant and have to ask. That said, a writer does not replace engineers writing anything at all. The working split is that engineers own inline comments, commit messages and architecture decision records, and the writer owns everything a newcomer or an external developer reads first.

Do technical writers need to be able to code?

For internal engineering documentation and API reference work, yes, to the level of reading code confidently, running your project locally, and using a terminal and Git without assistance. They do not need to ship features. For product-facing or end-user documentation the requirement is much lower. The mistake is hiring an excellent product-documentation writer for a job that is really API reference work, because the writing skill transfers and the code-reading skill does not. The paid exercise in step 5 settles this question in four hours and is worth every dollar.

How do I measure whether the hire worked?

Use the same two measurements you took before hiring. First, time from a new engineer joining to their first merged pull request, measured as a median over your last several hires. Second, the count of repeated questions in your engineering channels, which you can approximate by tagging recurring questions over a fortnight. Both are imperfect and both move for reasons other than documentation, so look at direction over a quarter rather than precision. If neither has moved after ninety days, the problem is usually that the writer was pointed at the wrong documentation type in step 2, not that the person is weak.

Sebastian

Mobile App & Hiring Expert at HireDeveloper.sg. Works with Singapore product teams on engineering recruitment processes and on the first ninety days after a hire.