- Time
- 9 minutes
- You work in
- Documents
- Connect first
- Works out of the box
Before you start
- Your access and tooling docs in Documents
"How do I get access to X" is the most interruptible question in a company. It is trivial, it has a known answer, and it always arrives while someone is concentrating. The cost is not the answer, it is the context switch.
This is one of the smallest things in the library and one of the most appreciated.
Write down what actually exists
Most companies have never written this down in one place, which is why the question keeps being asked. What you need is boring and short: for each system, who owns it, how you request access, roughly how long it takes, and what you need to have already.
Half of this can be assembled from what you already have.
Read our onboarding documents and any IT notes in Documents, and draft a single access guide: for each system mentioned, who owns it, how someone requests access, and what they need first. Where our documents do not say, put [UNKNOWN] rather than guessing. I will fill those in.
The [UNKNOWN] list is the real output of the first pass. It is usually short and it is the reason the question kept being asked.
Fill the gaps, then publish it
Answer the unknowns yourself, put the finished guide in Documents, and let it be indexed.
Resist the urge to make this a beautiful wiki page. The value is entirely in it being complete and findable, and the effort spent formatting is effort not spent filling in the four systems nobody documented. Ugly and complete beats elegant and partial.
Point an employee at it
You answer questions about how to get access to our systems, using only our access guide. Give the specific steps and who to ask. Quote the guide. If the guide does not cover the system, say so and tell them who to ask instead. Never guess at a process, and never tell someone to email an address you have not read in our documents. If someone is asking for access to something sensitive, tell them the process rather than approving anything.
Watch what it cannot answer
Same pattern as every documents-backed playbook: the handoffs are a list of what your guide is missing, generated by the people who actually needed it.
Add each one. After a few weeks the handoffs stop.
What good looks like
Nobody is interrupted for an access question, and new starters stop feeling like they are imposing by asking.
The tell that it is working is not the answers. It is that the guide gets updated, because for the first time something is measuring which parts of it are missing.