When you join a running project — as a lead, an architect, or part-time — your hands itch to start fixing things right away. There it is, the crooked deploy; the database without indexes; the service nobody has touched since last year. Stop. For the first week you fix nothing at all.
This article covers "Track 0" from the project order map: how to take an honest snapshot of a project's state in one week. I'll show it on a real example — a growing gamedev project I joined to bring order to.
Why a snapshot first, not a fix
Three reasons:
- You don't yet know what matters. The first "obvious" problem almost never turns out to be the main one. Fixing it means spending your credit of trust on something secondary.
- Any fix without the full picture is a gamble. The system lived for years before you; what looks like a bug may be the prop holding everything up.
- The snapshot is a result in itself. A week later you hold something the project has never had: a complete picture. Often it's the first document of its kind in the company's history.
Step 1. Talk to everyone
The first thing I did on the gamedev project was a one-on-one call with every single person: developers, DevOps, support, product. Not a meeting — one-on-one, 30–45 minutes each.
The questions are simple:
- What annoys you most about the project?
- What's scary to touch, and why?
- What would you fix first if it were up to you?
- What do you alone know? What happens if you leave for a month?
The discovery that repeats on every project: everybody already knows everything. People carry precise lists of problems in their heads for years — where it hurts, what will fall apart next, why Friday deploys are forbidden. Nobody has ever collected that knowledge in one place. You don't discover problems — you collect them.
The side effect is as valuable as the main one: the team sees that the new person listens first and breaks nothing. It's the cheapest way to earn trust — and it works exactly once, in your first week.
Step 2. The service map
In parallel with the calls — a table. Boring, but honest:
| Service | Purpose | Where it lives | Who knows it | How it deploys |
|---|---|---|---|---|
| … | … | … | … | … |
The rule: don't trust the documentation — trust reality. Look at the servers, the cron jobs, what is actually running. On my project a couple of services from the "architecture diagram" turned out to be long dead, while two live ones the diagram knew nothing about surfaced: a script on a host and a bot deployed "just for a minute" a year ago.
In the "who knows it" column you'll keep seeing the same name. That's not a column — that's an alarm.
Step 3. The scary places
The calls and the map produce a special list — the things people describe as "better not touch it." For every item, ask "why" until you hit the bottom:
- sometimes the fear hides a real landmine (no tests, no rollback, the only person who knew it has left);
- sometimes it's just a legend: it crashed once, scared everyone, and has been avoided ever since.
Separating landmines from legends is half the risk work done. Legends dissolve with a single experiment on staging; landmines go into the top risks.
Step 4. Top 5 risks on one page
The week's finale is one page, written in plain language, no jargon:
If server X dies, the game won't start for anyone, and recovery will take an unknown amount of time, because the backup has never been tested.
Five items like that, sorted by pain. Not fifty — five. Keep the rest in your working notes.
I showed that page to the team before showing it to management. First, they fixed my factual mistakes. Second, the document reached management as "ours," not as "the new guy reporting on everyone." That matters: the snapshot is a tool for working together, not an audit denunciation.
What you have a week later
- A service map that matches reality
- The scary places list, split into landmines and legends
- Top 5 risks the team has signed off on
- People's trust — you listened, wrote things down, and broke nothing
- Most importantly: a basis for ordering the steps. From here on you fix what actually fires most often, not what caught your eye first
Every other track starts from this snapshot: observability turns the lights on where the map showed darkness, and the infrastructure steps follow the risk list instead of gut feeling.
The week's checklist
⬜ One-on-one calls with everyone — 4 questions, your own notes
⬜ Service map: what / why / where / who knows it / how it deploys
⬜ Verify the map against reality (servers, crons, processes)
⬜ The "scary places" list → split into landmines and legends
⬜ Top 5 risks on one page → show the team → then upward
⬜ Fix nothing. At all. For a week.
Originally published at mind.mansur.expert.
Top comments (0)