Engineering & IT

Answer "how do I get access to X"

The access questions that interrupt your engineers, answered from your own docs.

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.

Prompt
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

Prompt
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.