Operations

Getting a process out of one person's head

The process exists. It is in someone's habits and in six months of Slack threads. A worker interviews and reads until it is on a page.

What the worker does

An AI worker in Polaris documents a process by reading the Slack threads where it actually happens, asking the person who owns it a short list of specific questions, and writing a versioned process doc with every unresolved point listed as an open question at the top. The owner reads the draft, answers the open questions, and approves it. What the process should be remains their decision.

Connections: Slack · Google Drive
Source material: Real threads, not a blank template
Every draft opens with: The questions it could not answer

Nobody writes documentation because writing it means admitting you are not sure

Ask the person who owns a process to document it and they will start, get four steps in, hit the part where it depends on what the customer said, and stop. That branch has never been written down because writing it means deciding it, and deciding it is a bigger job than they had time for today.

So the process stays undocumented, and it leaves with them.

A worker gets past this by starting from evidence rather than from a blank page. It reads the last ten times the process ran in Slack, drafts what it observed, and puts the branch it could not resolve at the top as an explicit question. Answering a specific question is a two-minute job. Writing a document is not.

How a documentation run goes

1
Name the process and where it happens
The brief needs one thing to be precise: which Slack channels and which folders is this process visible in. A worker pointed at everything produces a document about nothing.
2
The worker reads the last several real instances
It looks for the actual sequence, the people involved, the decisions taken and the exceptions, and it notes how often each exception occurred rather than treating it as a rule.
3
It asks the owner a short list of specific questions
Posted as a comment on the task. Specific means answerable in a line: does the finance check happen before or after the customer is told, and who does it when the owner is away.
4
It drafts the doc with open questions at the top
Docs in Polaris are a nested tree with markdown shortcuts, to-dos and sub-pages, and they are versioned, so the draft has a history from the first version onward.
5
The owner answers, approves and the doc becomes the reference
The human closes the task. The doc is then the input to SOP maintenance, which is what stops it going stale.

What makes the resulting document actually get used

Frequencies, not just steps
"This exception happened in 3 of the last 10 runs" tells a reader far more than a step listed as if it were routine.
Named people for the branches
Every process has a step that in practice means asking a particular person. Naming them is honest, and it identifies your single points of failure.
The open questions kept visible
Do not delete the question list when the document is approved. Move it to the bottom as the record of what was decided and when.
A link to the real threads
A documented step that cites the conversation where it was decided survives an argument six months later.

Describing versus designing

The worker

Describes what actually happens today
Counts how often exceptions occur
Names who is involved at each step
Asks about the parts it could not resolve
Writes and versions the document

The process owner

Decides what the process should be
Resolves the branches
Approves the document
Decides who is accountable for each step
Closes the task

Questions people ask

+What if the process does not happen in Slack?

Then the worker has less to read and the interview carries more weight. Say so in the brief and expect a longer question list. Processes that leave no trace anywhere are the ones most worth documenting and the slowest to capture.

+Will it invent steps it did not observe?

Brief it to write only what it saw and to list everything else as an open question, and check the first draft against that instruction. A documentation worker whose gaps are invisible is worse than no documentation at all.

+How is this different from SOP maintenance?

This creates the document from evidence for the first time. SOP maintenance keeps an existing document honest as reality drifts away from it. Most teams need this once per process and maintenance forever after.

+Can the document live somewhere else?

It can be exported, but keeping it in Polaris docs means the review task, the process owner and the version history are in the same place. A process doc in a separate wiki is a process doc that will be out of date by the second quarter.

Operations work with an AI worker doing the chasing

Ops is the function that holds the seams together. Most of that work is asking people things and writing down what they said.

Finding where the SOP and the real procedure came apart

Every written procedure starts accurate and drifts. A worker compares the document to how the work actually ran and reports the difference.

Dependencies as dated items, not as things people said in a meeting

Two teams agree something in a call. Neither writes it down. Three weeks later each is waiting for the other. A worker makes the promise a tracked item.

The README describes a version of the code that no longer exists

A monthly list of statements in your docs that the code no longer supports.

Hire an AI technical writer

The documentation debt on your team is not a writing problem, it is a nobody-has-two-free-hours problem, and this is the worker for those two hours.

Connect Slack to Polaris

Six scopes, no access to direct messages, and a bot that only reads the channels somebody invited it into.

Workstream

A strand of work that keeps going, rather than a project that ends.

When the deliverable is a file

A chat reply is not a deliverable if the thing you needed was a document somebody can open.