Arriving in the middle of someone else’s plan
What the missing artifacts tell you, why you should not clear a fence you cannot explain, and how to decide what is worth reopening on a project already in flight.
Every lesson so far started from a blank page. A Slack message arrived, and everything after it was yours to write.
That is not how most projects reach you. Far more often you join a team, or take over from someone who left, or get handed something that has been running for two months — and there is a plan. It is partial, its reasoning is not written down, and several people are already building against it.
This is the same sequence run backwards, and it is a different skill from writing one.
Absence is information
Start by inventorying what exists, using the course as a checklist. Is there a problem statement? Success criteria? An alternatives section? A range, or just a date? A risk list with owners?
The instinct is to read what is there. The faster diagnosis is in what is not there, because each absence tells you something specific about what was never settled:
- No problem statement — nobody has agreed what this is for. Expect people on the team to give you materially different answers to “why are we building this?”, and expect that to be news to them.
- No success criteria — there is no defined finish, so the project ends when someone gets tired or a date arrives. This is the most common one and the most expensive.
- No alternatives section — the approach was never chosen against anything. It may still be right; nobody knows, and the first person to propose a different one will restart the whole conversation.
- A date but no range — a forecast was converted into a commitment somewhere, probably in a room, probably without the person who gave it noticing.
Do not clear a fence you cannot explain
Now the danger, which is entirely on your side. Arriving with fresh eyes makes bad decisions extremely visible, and you will be tempted to start fixing them in week one. It is also the fastest way to destroy your credibility with people who have context you do not.
Chesterton put the principle better than software writing has managed since. Imagine a fence across a road with no obvious purpose. The careless reformer says it is useless and should be cleared away; the more thoughtful one replies that until you can say why it was put there, you are not qualified to remove it (Chesterton, The Thing, 1929). Go and find out first; then remove it if it deserves removing.
Inherited plans are full of fences. A strange data model, a vendor nobody rates, a scope decision that looks arbitrary. Some are genuinely mistakes. Some are the visible residue of a constraint that is still true and that nobody wrote down — a contractual commitment, a platform team’s hard no, a regulatory requirement discovered in month one.
The reason this is hard here specifically: the artifact that would have told you is the decision record, and the whole reason the review-thread lesson insists on writing one is this exact moment, arriving for somebody else. When it does not exist, you are doing archaeology.
Archaeology: use the second story
You will have to ask people, and the phrasing decides what you get back. “Why did you do it this way?” reliably produces defensiveness — it parses as an accusation even when it is not meant as one, because the person hears that you have already judged it.
Use the move from the reference-class lesson, pointed at an inherited decision instead of your own estimate. Ask for the second story: what made this look like the right call at the time, given what was known then?
“I’m trying to understand the shape of this before I change anything. When you picked this approach, what were the constraints? Is there anything you considered and ruled out that I should know about?”
That question is answerable without anybody being wrong, so people answer it. And the ruled-out options are the valuable part: they are the alternatives section that never got written, and they are usually still in somebody’s head, intact, waiting for the first person who asks.
What to reopen, and what to inherit
You cannot run eleven lessons on a project already in flight. Trying to would cost more than the problems you would find, and you would spend your first month producing documents while everyone else builds.
So use the test from the questions lesson, unchanged. Reopen only what is load-bearing — where a different answer would produce a different plan. Everything else you inherit, on purpose.
The word doing the work there is deliberately. There is a large difference between “we are keeping this approach; I looked, and changing it would cost more than it saves” and drifting past it without ever forming a view. The first is a decision you can defend in three months. The second is how you end up owning somebody else’s mistake with none of their reasons.
Retrieval check
Without scrolling up: you find a decision in an inherited plan that looks obviously wrong. What do you do before changing it, and what is the specific risk if you skip that step?
Check your answer
Find out why it was made — Chesterton’s fence. Until you can state the reasoning behind it, you are not in a position to judge whether it should go.
The specific risk is not that you look hasty. It is that a decision which looks arbitrary is often the visible remainder of a constraint that is still true and was never written down — a contract, a hard no from another team, something discovered the expensive way. Removing the fence reintroduces the problem it was built for, and now it is yours, with none of the context that would have let you see it coming.
Then write the small missing thing
Once you know what is load-bearing, write the artifact that is missing — and write it small. A one-page framing for a project already underway, stating the problem, what counts as done, and what you have deliberately inherited without reopening.
Circulating it does two jobs. It gives everyone something to correct, which is far easier than getting them to explain a project from scratch. And it is usually how you discover the disagreement — the moment the team sees the problem written in one sentence is very often the first time they notice they were not building the same thing. That discovery is the real return on the exercise, and it arrives in about a day.
Now apply it: inherit the SSO project
Hands on
Take over a plan you did not write
Done when: You have an inventory of what is missing, one fence investigated properly, and a one-page framing that names what you are inheriting deliberately.
- Imagine you have joined this project in week four, and the only artifacts that exist are the design doc and a date. Inventory what is missing against the course: framing, success criteria, alternatives, range, risks, dependencies.
- For each absence, write the one-line consequence — what is now undecided, and who is silently assuming an answer.
- Pick the decision that looks most obviously wrong to you. Write the question you would ask about it, phrased as a second story — no version of “why did you”.
- Sort your inventory into reopen and inherit, using the load-bearing test. Aim to reopen at most two things. If your list is longer, you are planning to spend the quarter on documents.
- Write the one-page framing, including an explicit section for what you are inheriting without reopening and why. That section is the one that protects you later, and the one people skip.
- Bring it into the chat. I’ll play the engineer who has been on the project since week one — helpful, a little wary of the new person rewriting things, and holding at least one reason you could not have guessed.
Where this leaves the course
That is both directions: building a plan from nothing, and picking one up mid-flight. The artifacts are the same either way, and so is the underlying move — make the reasoning visible enough that someone else, including a later version of you, can argue with it.
Keep the playbook open while you do this on something real. It is the whole course on one page, which is the form you actually want it in once you have read the arguments behind it.
Read this next — primary source
Taking a Fence DownThe American Chesterton Society — free, five minutes
The passage from Chesterton’s 1929 book The Thing, in the chapter “The Drift from Domesticity”, where the fence parable comes from. It is short and it is about reform generally rather than software, which is the point — read it and notice how precisely it describes arriving on a project where the reasoning was never written down.
Stuck, curious, or think this lesson is wrong? Ask your teaching agent. The lessons are the scaffold; the conversation is where the learning gets unstuck.