Define the problem

First month: map product areas, audiences, source repositories, build, reviewers and release flow. The first ninety days should build product understanding, relationships and a map of how documentation actually reaches users before a new writer redesigns the system.

Choose a useful model

Read support and recent change history to find where reality is harder than the intended documentation model. In the first month, follow existing publishing paths end to end, reproduce common user tasks and learn who can verify each product area.

Build the workflow

Ship one bounded improvement to learn the real branch, preview, approval and deployment workflow. In the second month, own a bounded change from discovery through release and note every point where context, tooling or ownership is unclear.

Check the result

Second month: own a coherent domain and build relationships with its experts and terminology. In the third month, propose one or two improvements backed by observed friction rather than a wholesale process replacement imported from a previous company.

Keep it maintainable

Third month: propose system changes only after observing failures and understanding the existing workflow. A good onboarding outcome is not just shipped pages; it is a writer who knows how to verify a claim, find an owner and change the system safely.

Applied example

Turn “The first 90 days in a documentation team” into a short practice assignment with an observable result. Choose a small artifact that can be finished in one or two sessions: a one-page procedure, an API example, a before/after edit, a terminology cleanup or a miniature portfolio case. Define what “better” means before you start, then compare the first version with the revised one.

Keep evidence of the work, not only the final page:

  • the original problem and audience;
  • the decisions you made and alternatives you rejected;
  • feedback from a reader, reviewer or subject-matter expert;
  • one thing you would change on the next attempt.

This is more useful than passively collecting articles and courses. Technical writing is a craft of repeated decisions under constraints. A small finished exercise with a clear review teaches more than a large theoretical project that never reaches a reader.

Quick editorial checklist

  • Define the problem. First month: map product areas, audiences, source repositories, build, reviewers and release flow.
  • Choose a useful model. Read support and recent change history to find where reality is harder than the intended documentation model.
  • Build the workflow. Ship one bounded improvement to learn the real branch, preview, approval and deployment workflow.
  • Check the result. Second month: own a coherent domain and build relationships with its experts and terminology.