From Chaos to Clarity: How I Streamlined Documentation Requests Across Teams

Context

When I joined the team, documentation requests came from everywhere—Slack messages, Chime chats, hallway conversations, and unexpected “quick asks” dropped right before launch. Each service team had its own way of working, and priorities shifted faster than we could track them.

As a technical writer supporting multiple AWS services, I noticed that more of our time went into sorting and following up on requests than actually writing. Product and UX partners often didn’t know how to engage with us or what level of detail to provide, which led to unclear scope and last-minute content scrambles.

The lack of structure didn’t just slow us down—it blurred ownership and made it hard to plan or advocate for realistic timelines. I wanted to fix that by designing a process that made documentation work visible, predictable, and scalable across teams.

Challenge

Our biggest challenge was visibility. Without a defined intake or tracking system, there was no reliable way to measure capacity, balance workloads, or even see what was in flight.

Writers were fielding fragmented requests across services with no shared understanding of scope or priority. PMs and UX designers often had no insight into documentation timelines, and leadership couldn’t easily see how much work the writing team was already supporting.

We needed a single, structured workflow that captured requests consistently, clarified ownership, and gave everyone—from writers to product managers—a shared view of what was being worked on.

Approach

I led the design and rollout of a centralized documentation intake and tracking system in Asana.

• Standardized intake form: I built an Asana form that required key context for every request—service name, audience, deliverable type, and desired launch date. This ensured that writers had complete context up front.
• Effort sizing: Introduced T-shirt sizing (S, M, L, XL) to help estimate writing effort and manage expectations.
• Capacity dashboard: Configured Asana dashboards to visualize each writer’s workload, helping leadership balance priorities across multiple services.
• Process training: Hosted quick walkthroughs and recorded demos to help the team adopt the workflow confidently and build habits around using the new system.
• Stakeholder communication: Regularly met with PMs, UX leads, and engineering partners to share updates, gather feedback, and reinforce how the new workflow improved visibility for everyone involved.

The workflow was intentionally lightweight—structured enough to create clarity and accountability, but flexible enough to fit the rapid release cadence of AWS services.

Results

Within the first quarter after launch:

• Unplanned or “drive-by” requests dropped significantly as stakeholders began using the intake form.
• The writing team reported clearer priorities and fewer context gaps.
• PMs and UX leads gained visibility into workloads, which helped them plan documentation tasks earlier in their release cycles.
• Cross-team collaboration improved—writers could now hand off or reassign work with full context instead of scattered Slack threads.

The new workflow quickly became the default way to request documentation support, and it gave leadership a scalable model for forecasting and planning future headcount.

Takeaways

This project reinforced a simple idea: clarity is a form of respect.
By building a transparent system, we reduced friction, set clearer expectations, and created space for deeper writing work.

I learned that successful process design depends as much on empathy as structure—listening to how people actually work, then shaping tools that fit those realities.

Reflection

Good documentation systems aren’t just about words—they’re about trust, predictability, and shared ownership.
Turning chaos into clarity starts long before a writer opens the doc—it begins with how teams ask for help.