Getting up to speed on something nobody is going to explain to you

The situation is normal, not exceptional

You are given responsibility for something that already exists. The person who built it has left, or is too busy to explain, or explained it once in a rushed hour that you have now forgotten. Documentation is absent, out of date or describes an intention rather than the current state. This isn’t a sign of a badly run organisation, though badly run organisations have more of it. It is the ordinary condition of inheriting work of any age.

The instinct is to read everything before touching anything, which feels responsible and is usually a way of postponing the moment of discomfort. Comprehensive reading has poor returns here, because you have no framework yet to attach the details to, and most of what you read won’t stay.

Start from the edges rather than the middle

The faster route is to map the boundaries first: what goes in, what comes out, who supplies the inputs, who consumes the outputs, and what happens when it fails. Those five questions can usually be answered in a day or two by asking the people on either side, and they give you a frame that makes subsequent detail stick.

The people at the edges are also more available than they seem, and they often understand the thing better than its owner did, because they are the ones who deal with the consequences. Whoever complains when it breaks knows exactly what breaks. Whoever supplies the input knows which of the rules are actually enforced.

Trace one real case all the way through

Abstract explanation of how something works is far less useful than following a single genuine instance from beginning to end. Pick one recent case — one order, one report, one request, one document — and track exactly what happened to it, in the actual system, including the manual steps that nobody mentions because they are too obvious to say out loud.

That last category is where the real knowledge lives. Almost every process has undocumented human interventions: a check somebody does by eye, a correction applied every Monday, a message that has to be sent before a step will work. These never appear in the official description and they are usually the parts that fail when the person who does them is on holiday.

Tracing one case also gives you a specific vocabulary for asking questions, which changes the answers you get. "How does this work?" produces a vague tour. "What happens to this one between here and here?" produces a precise answer, because the person can see exactly what you’re asking.

Write the document that did not exist

Write down what you learn as you learn it, in whatever rough form. This isn’t primarily an act of service, though it is that too. It is the mechanism by which you find out what you do not yet understand, because a gap in your knowledge is invisible until you try to describe the thing and cannot.

Keep the notes honest about uncertainty. Marking a step as not fully understood is more useful than a confident description that turns out to be wrong, and it gives you a list to close out. When you eventually find someone who knows, you can resolve five open questions in one conversation instead of asking one at a time over a month.

Changing something is the fastest way to learn it, and the riskiest

At some point reading stops teaching and you have to alter something and observe what happens. That is genuinely the most efficient learning available, and it is also how people break things they did not know were connected. The reasonable compromise is to make the first changes small, reversible and in a place where failure is visible quickly rather than three weeks later in somebody else’s report.

Say what you are about to do, to whoever depends on it, before you do it. Not as a request for permission, necessarily, but because someone will occasionally reply with the sentence that saves you a bad week. And resist rewriting the whole thing in the first month, however tempting. Inherited systems are usually full of decisions that look arbitrary and turn out to encode a constraint, and the standard sequence — new owner declares the thing a mess, replaces it, rediscovers the constraints one at a time — is common enough to be worth avoiding deliberately.