Every bucket has a bottom: How to shrink your queue and manage what's left

No one knows how big anyone else's bucket is. Your job is to show them and then build a system that does it for you.

This post is part of the Per the docs article series. Links to the rest of the series are at the end of this piece.

Stakeholders just see the docs you ship. They don't see the fourteen other things competing for the same week, the scope negotiation you silently absorbed, or the three requests you're holding because someone hasn't reviewed your draft yet.

Invisibility is the structural problem. It's not the workload, and not even the under-staffing. The problem is that everyone around you is making decisions based on incomplete information, and you're the one paying for it.

There's alchemy at work that nobody sees. Transforming chaos into useful documentation is one trick. But the harder magic is transforming a system where everyone assumes that they're your only priority into one where the work is manageable.

The problem

At AWS, I was writing and managing documentation for the Amazon EMR service with a team running well below capacity. Four writers, budgeted for six, supporting more than ten service teams. Each team operated as if they had a dedicated resource. Nobody was being unreasonable, they just couldn't see what they couldn't see.

When the team of should-be-six writers dropped from four to just me, that's when the invisibility became hard to ignore.

The raw material included incomplete specs and late SME reviews (the visible friction). Underneath it was the invisible labor: every triage decision I made alone, every priority conflict I absorbed so stakeholders didn't have to, every time I said "I'll fit this in" without anyone understanding what that cost.

This invisible workload accumulates quietly until something breaks.

My first intervention: radical transparency

The scrappy version of the fix was to herd everyone into a single Slack channel.

I moved all my stakeholders out of their separate project channels and into one shared space called the Doc Talk channel. Then I started posting daily: what's in flight, what's on deck, what's waiting on a response from someone else. Just the queue, visible to everyone in the room.

But most importantly, a note at the end: if your thing isn't on this list, it's not on my radar.

That one line made the bucket visible. Stakeholders could see their request sitting in queue with seven others. They could see what was blocking something else. When two teams both wanted to be first, I didn't just absorb that conflict silently. I put it in the channel: These two things are competing for the same slot this week. Can you two figure out the priority? I don't have the business visibility to make that call.

They could, and they did! Here's how to set it up.

How to start a Doc Talk channel

The setup takes all of ten minutes (the habit takes longer).

Create a dedicated channel and add all your stakeholders together. Call it something literal. #doc-talk works or in special cases where you need separate channels for different writing teams, pre-pend the channel names like so: #doc-talk-infrastructure and #doc-talk-interface. The name matters less than the fact that everyone is in the same room.

Then post a list every Monday or more frequently as needed. Here's a template:

📋 Docs queue — [date]

**In progress**
- [Feature name] — [product/team] — draft in review
- [Feature name] — [product/team] — writing

**Waiting for feedback**
- [Feature name] — [product/team] — waiting on @username review since [date]
- [Feature name] — [product/team] — waiting on @username sign-off

**On deck**
- [Feature name] — [product/team]
- [Feature name] — [product/team]

If your request isn't on this list, it's not on my radar. Reply here with a link to your request to get it added.

Stakeholders who don't see their thing will speak up. Stakeholders who do see their thing will see it next to everyone else's.

When two requests compete for the same slot, put it in the channel: These two things are both targeting the same week. Can the owners sort out the priority? I don't have the business visibility to make that call.

A few things that make Doc Talk work better:

• Post consistently, which will train people to look for it.
• Keep the list short and factual without narrative or explanations. The format is the signal.
• When something completes, edit the latest list to have a Complete section and move that item down. Closure matters.
• If something has been in "waiting for feedback" for more than a week, use it as a conversation starter rather than absorbing it silently.
• When someone DMs you a request or a status question, don't answer in the DM. Forward the message to Doc Talk and answer there. This does two things: it keeps the channel as the single source of truth, and it trains people to bring requests to the channel instead of your inbox.

When you eventually build the front door (more on that below), keep Doc Talk running. When a DM comes in, forward it to the channel with your answer and a link to the intake page:

Hi @username! You can use [link] to check the status or submit new requests.

Doc Talk is a manual system and it works exactly as well as you maintain it. When you're ready to make the visibility automatic, that's when you build the front door.

What came next: a simple but sophisticated front door

On my next team, 13 writers served four services with no shared process. Some worked from ticket queues; others monitored launch calendars. I unified both systems with a wiki intake page as the single front door. Every request came through one place, scoped by service and content type so submitters only saw relevant fields. Submissions routed automatically to writers by topic area. Pattern-based requests got deflected to AI tools before they hit anyone's queue.

The visibility worked differently than Doc Talk but accomplished the same thing. Instead of me posting a daily list, we published topic-based boards directly on the Confluence page. Stakeholders could see work in flight and on deck in real time, on demand. Raising priority concerns, communicating date changes, and identifying gaps were on them now, not the writers.

The system also trained people without me saying a word. When someone came in last-minute, I'd send them a link to the intake page. They'd see the lead times, the submission requirements, the current queue. If they'd missed the window, that was the conversation: not me explaining capacity, just the system showing them what they'd walked into. That person rarely made the same mistake twice.

How to level up: building a front door

The front door is a single landing page in your wiki that functions like a website: it tells people where they are, what their options are, and where to go next. Every doc request starts here, and the page is always current.

Step 1: Build the landing page

Structure the page around the types of requests you receive. For most teams, three categories cover the majority of incoming work:

• New content for a feature, product, or service that isn't documented yet
• Updates and bug reports for changes to existing content or corrections
• Customer-facing messages including UI text, error messages, constraints, and notifications

Make each category a prominent button or link. Behind each one is a set of dropdown options that narrows the request before it reaches a writer.

For content requests, the first option narrows by service or product area. This routes the request to the right writer automatically and surfaces service-specific forms with relevant fields. Different teams have different documentation requirements, and one form trying to serve all of them produces noise.

For customer-facing messages, skip the service filter. Narrow by content type instead: UI text, error messages, constraint copy, empty states, notifications. Each content type gets its own form or tool scoped to that deliverable.

Step 2: Build scenario-specific intake forms

Generic intake forms produce generic requests. A form that asks "what do you need documented?" produces a paragraph. A form that asks specific questions produces a ticket you can act on.

Build one form per scenario. Each form should capture:

• What exists today (nothing, an outdated page)
• Links to resources: a draft, design doc, Figma, related tickets
• What the deliverable is (new page, updated section, error message)
• Who the audience is (developer, admin, end user)
• What the audience can do now that they couldn't do before
• Why they would want to do it; the impact
• What the deadline is and whether it's hard or soft (BY a date vs. ON a date vs. soon but not urgent). Include helper text that states required lead time so there are no surprises
• Who the SME is for follow-ups and reviews

The form fields are also training. Submitters start to learn what information they need to provide with every request.

Step 3: Add automation rules

Once requests flow through forms, automate the routing. Most wiki and project management tools support basic rules:

• If the product field or URL matches a writer's area, assign to that writer automatically
• If the content type is "error message," route to the error message workflow
• If the submission date falls within two weeks of the GA date, flag as late and trigger the late-request process

Automation removes the logistics so that judgment is all that's left.

Step 4: Deflect pattern requests to single-job tools

Some requests follow such a predictable pattern that a writer shouldn't touch them at all. These are deflection candidates.

Error messages and constraints are a good example. Instead of routing to a writer, it routes to a self-service tool: a small app that takes an error code, a plain-language description of what went wrong, and a suggested resolution, and outputs a formatted error message that meets your style standards. Ask the requester to run the output by a writer for final signoff. The writer's queue just got lighter!

Other good deflection candidates:

• Release notes for minor updates. A structured form outputs a draft the team reviews without writer involvement.
• Boilerplate API parameter descriptions. Type, format, required or optional, and default value generates a draft reference entry.
• Standard callouts. Safety warnings, deprecation notices, and preview feature disclaimers that follow a fixed template.
• FAQ entries. A question, an answer, and a related docs link generates a formatted entry ready for review.

The rule of thumb: if you have written the same thing more than three times and the pattern is stable, it is a deflection candidate.

Step 5: Keep the landing page current

The landing page is only useful if it's accurate. Include the things people should check before they submit:

• Live project board links. Direct links to filtered views showing work in flight for each service, so stakeholders can check status without asking.
• Current SLAs. How long standard requests take, how long fast-track requests take, and what qualifies for fast-track.
• Late request guidance. What to do when a request comes in inside the submission window, what the escalation path is, and what "late" means for your team's SLAs.
• Tool links. Direct links to single-job tools so people find the self-service options before they submit a request.

Update the SLAs whenever your capacity changes. A landing page with outdated lead times trains people to ignore it.

Doc Talk and the front door are the same system at different scales. One runs on habit; the other runs by design. You don't have to build both at once. Start with the channel, learn what your most common request types are, and let that inform what you build next.

What this transforms

The docs got better, it's true. When you stop absorbing invisible conflicts and start surfacing them, you make better decisions about scope. MVP docs ship on time. Advanced scenarios become planned fast follows instead of perpetual backlog. You have data to negotiate with instead of just goodwill.

But the bigger transformation is the shared understanding. Stakeholders who can see the queue have no reason to assume. They negotiate with each other instead of lobbying you. They bring you information instead of just requests. The relationship changes because the system changed.

The system makes the bucket visible. The visible bucket makes everything else possible.

Next: agentic AI

The intake system I built was a good start. But I could see where it was going, and the direction was more ambitious than what I had time to finish before layoffs hit.

The logical next layer was agentic: AI that doesn't just deflect pattern requests but actively manages the logistics of the queue. A form submission triggers an agent that checks whether the doc already exists, diffs the request against current content, and either opens a net-new Jira ticket with a pre-populated scope statement or links to the existing page and queues an update without a human touching it. Net-new work gets a branch in the doc repo automatically, pre-populated with the right template. The agent even does a first-pass draft from the ticket context, the existing docs, and any linked specs.

The more interesting piece is what can happen upstream. An agent that watches the engineering roadmap, identifies undocumented features approaching GA, and opens tickets proactively before anyone asks. The queue anticipates instead of reacts, and so do you.

But the writer is still the alchemist.

AI is good at logistics. It can classify, route, create tickets, open branches, chase down quiet reviews, and flag capacity conflicts before they become your problem. What it can't do is recognize that a "simple update" is actually a documentation architecture problem. It can't negotiate scope with a PM who's never shipped a feature before. It can't read a spec and know that the engineering team got it wrong. It can't decide what gold looks like.

The real promise of an agentic intake system is that AI handles the invisible logistics so completely that the writer's queue contains only the work that requires human judgment. No more absorbing priority conflicts. No more chasing reviews. No more posting daily flight lists by hand.

The crucible runs itself. The alchemist focuses on the gold.

This post is part of the Per the docs article series, a monthly collaborative series where technical writers explore different aspects of our craft.

• Previous article: James Beach — Turning Constraints Into Structure
• Next article: Brandi Hopkins — When the source of truth isn't true

See the full list of participants and articles →

Disclaimer: Each article in this series is written and owned by its respective author. The views, opinions, and experiences shared belong solely to the individual writer and do not represent the perspectives of other participants or their employers (past or present).