English
Build your map

Free tool

How much of this system lives in one person?

Fifteen questions about where the understanding, the access and the ownership actually sit. The result is three named groups, not a risk score.

Build your map

of answered

Where this leaves you

Covered

The company holds this, not one person.

Concentrated

A real single point of failure. The guidance beside each names the first move.

Needs checking

Never established. Every item here is checkable this week, and several without asking anybody.

Knowledge concentration

How much of the understanding lives in one head. This is the dimension that decides how long a departure costs you.

Could somebody other than this person explain what the system is made of?

Explain, not "look it up". A second person who could answer a hard question in a meeting.

If covered Verify it rather than assume it: ask that second person to describe the riskiest part, and see whether the description matches.

If concentrated This is the core exposure. Everything else on this page is a consequence of it.

If needs checking Ask somebody else to describe the system for ten minutes. You will know within two.

Does anybody else understand the part that handles money, orders or customer data?

The riskiest subsystem is usually the one with the fewest people in it.

If covered Good. Check the same is true of the unglamorous parts — the scheduled jobs and the integrations.

If concentrated Start here. A second person on the money path is worth more than a second person anywhere else.

If needs checking Name the person who would be called at 3am if it broke. If there is exactly one name, that is your answer.

Is there a written account of the system that is current?

Current means it describes the system as it is now, not as somebody remembers it.

If covered Check when it was last verified against the system rather than last edited.

If concentrated This is derivable in hours rather than weeks, and it converts an unbounded worry into a bounded task.

If needs checking If you cannot name the document and its date, the answer is no.

Is there any record of why things were built the way they were?

The one category nothing can derive from code. It exists only while the person is reachable.

If covered Unusual and valuable. Keep adding to it — a paragraph per significant decision is enough.

If concentrated Get it while you can, as answers to specific questions rather than as a document.

If needs checking Look for design notes, decision records or long pull request descriptions. If there are none, treat the answer as no.

Is there a written list of what nobody currently knows about the system?

A team that can produce this list is in far better shape than one that says there is nothing.

If covered Rank it and work it down. It is the most useful backlog you have.

If concentrated Start it today. Every time somebody says "actually nobody knows how that works", that is an entry.

If needs checking A confident "we know everything" about a real system is itself the finding.

Access concentration

Whether a departure is a knowledge problem only, or also a lockout problem.

Has anybody else deployed to production in the last three months?

Having the credentials is different from having done it.

If covered Good. Make sure the process is written down as it was performed.

If concentrated Arrange a supervised release now. It usually finds two or three steps that live in one person's habit.

If needs checking Look at the deployment log. It answers this in a minute.

Are production credentials in a store the company controls?

A company-controlled vault; not a personal password manager and not a file on one machine.

If covered Confirm at least two people can reach it, and that there is a departure procedure.

If concentrated Move them, then rotate. In that order.

If needs checking Ask where the production database password is. The answer describes the whole arrangement.

Are all the service accounts in company names rather than this person's?

Domain, cloud, payment provider, email, monitoring, app stores.

If covered Check the recovery addresses too. A company account with a personal recovery mailbox is not a company account.

If concentrated These are transfers with a process, not permission changes. Start with the domain and the cloud organisation.

If needs checking Follow the invoices. Whoever is billed usually owns the account.

Is there anything that only runs from this person's machine?

A script, a scheduled task, a deployment step, a report they send every month.

If covered Answer yes here if the answer is "no, nothing does".

If concentrated Find them and move them onto infrastructure the company controls. This is the classic silent single point of failure.

If needs checking Ask them directly, in those words. People remember immediately when asked.

Infrastructure ownership

Is the domain in a company-owned account with a company recovery address?

The single most damaging thing on this page to get wrong.

If covered Good. Check it again after any change of registrar or of the person who manages it.

If concentrated Fix this before anything else here.

If needs checking Ten minutes with the registrar settles it.

Is the cloud account owned by the company, with the root credentials held by it?

Access granted by somebody else is not ownership.

If covered Confirm billing goes to a company payment method as well.

If concentrated Transfer it. This has a process and it takes days rather than minutes.

If needs checking Look at who the account root user is.

Has somebody other than this person restored a backup?

Restoring is a different operation from backing up, and it is the one that fails.

If covered Note how long it took. That is your real recovery time.

If concentrated Do it into a scratch environment. This exercise finds more real problems than any audit.

If needs checking Nobody forgets restoring a backup. If it is uncertain, it did not happen.

If they left tomorrow

The questions people only ask afterwards.

Could the rest of the team ship a small change next week?

A real change, through the real process, without them.

If covered Then the exposure is knowledge rather than operations, which is the better of the two problems.

If concentrated This is an operational dependency as well as a knowledge one, and the operational half is faster to fix.

If needs checking Try it this week while they are still here to unblock it.

Could somebody else handle an incident at 3am?

Not perfectly. Well enough to keep the product running until morning.

If covered Check they have the access as well as the knowledge, and that they know they are the one who would be called.

If concentrated Write down what this person checks after a deploy, which alerts matter, and what breaks regularly. That is the 3am knowledge and it transfers in an afternoon.

If needs checking Ask what happened the last time something broke out of hours.

Do you have a written list of the questions only this person can answer?

The single highest-value artefact in a departure, and it takes an hour to produce.

If covered Get the answers in writing before the notice period, not during it.

If concentrated Build it from the gaps in your technical picture. Those gaps are exactly the list.

If needs checking If it is not written down, it does not exist.

Your answers stay in this browser. There is no server behind this page: nothing is submitted, no account is needed, and no email address is asked for. Clearing the page or pressing “Start again” removes them.

  • 15 questions
  • about 8 minutes
  • no account
  • nothing is submitted
Free tool Reviewed

Short answer

Dependency on one developer is measurable in four dimensions: how concentrated the understanding is, how concentrated the access is, who owns the infrastructure, and what would actually happen if they left tomorrow. Each has a factual answer. The two highest-value fixes — moving account ownership into company identities and having somebody else deploy once — take about a day between them and remove most of the operational half of the problem.

#Why concentration happens

It is not a management failure. It is what small teams produce by default.

One person builds the payment integration because they were free that week. They become the person who knows it. The next question about payments goes to them because that is faster. Six months later they are the only person who has opened that code, and nothing anywhere recorded the moment it became true.

The same process runs independently in every part of a system, and the result is an organisation where four subsystems have exactly one expert each, nobody planned it, and it does not appear on any risk register — because it is not on a list anybody keeps.

Which is why counting is most of the value. Take twenty minutes, list the parts of the system, and write down who could answer a hard question about each. The parts with exactly one name are your register.

#What actually reduces it

In order of value per hour spent.

  1. Move account ownership into company identities

    Domain, cloud, registrar, provider dashboards, and the recovery addresses on all of them. An afternoon, and it removes the category that can leave you unable to operate.

  2. Have somebody else deploy, once

    A supervised real release. It converts “they have the credentials” into a fact and reliably finds undocumented steps.

  3. Restore a backup

    Into a scratch environment, performed by somebody who is not the usual person. Also produces your real recovery time.

  4. Derive a technical picture

    Hours rather than weeks, and it does not consume the time of the person you are worried about losing.

  5. Write down the questions only they can answer

    Then get the answers, in writing, before there is a notice period. This is the part that cannot be recovered later.

  6. Put a second person on the money path

    Slower and more expensive than the others, and the only one that genuinely reduces the knowledge concentration rather than working around it.

#What this does not do

What this does not do

  • It does not look at your system. Every answer is yours; the tool has no access to anything.
  • It is not a score or a benchmark.
  • It says nothing about the person — their competence, their intentions or their value.
  • It does not cover employment, contracts or retention, which is where several real answers live.
  • A “covered” answer given from memory is not the same fact as one given from having done it.

Questions people actually ask

No, and framing it that way is how the conversation goes wrong. Concentration of knowledge is a structural property of small teams, it is nobody's fault, and the person it is concentrated in usually carries the most stress from it. Most developers welcome the fix.

That is an ordinary result for a successful four-year-old product with a small team. The list is finite, and the two highest-value moves — moving account ownership and having somebody else deploy once — take a day between them.

Not to answer it. Several items are faster to check yourself: registrar records, cloud billing, deployment history. Involving them makes the follow-up faster, and the framing that works is continuity rather than audit.

Get a picture that does not depend on one person.

One read-only instruction, run by anyone with the code, produces the map, the dependencies and a prioritised list of what nobody can currently confirm. The first one is free.

Build your project map — free If they have already left