Short answer
#What ownership means here
There is a version of this topic that tells founders to learn enough programming to be dangerous. It is well-meant and it does not solve the problem, because the problem is not comprehension. It is access to answers.
- Technical ownership
- The ability of a company — rather than an individual — to obtain accurate answers about the software it owns: what it consists of, what it depends on, who controls each account, where understanding is concentrated, and what is not known.
- In plain terms Being able to find out what is true about your own system, without needing one particular person to be available and willing.
Framed that way, it stops being about your technical ability and becomes an ordinary question of business continuity, exactly like knowing where the contracts are filed.
#The answers you should be able to get
Twelve questions. None of them requires reading code, and all of them have plain-language answers.
What we own
- Whose name is the domain registered in? The single most damaging thing to get wrong, and one of the easiest to check.
- Whose account is the production infrastructure in?
- Who receives the invoice from each service the product depends on?
- If a person left tomorrow, could we still get into everything?
What the system is
- How many separate parts does our product consist of, and what does each do?
- What outside services does it need in order to work?
- Where is customer data stored, and does any of it leave our systems?
- What runs automatically, on a schedule, without anybody starting it? The category with the highest ratio of “nobody knew that existed” to size.
How exposed we are
- Who is the only person who understands each part?
- Could somebody outside our current team pick this up, and how long would it take?
- When was a backup last actually restored — not configured, restored?
- What does nobody here currently know about our own system? A confident “nothing” is a worse answer than a list.
#How to ask without it becoming a confrontation
The framing that works: "I need to be able to answer this to somebody outside the company." An investor, an acquirer, an insurer, an auditor, a large customer's procurement team. It is true, it is not about the person you are asking, and it converts the request from a loyalty test into a task.
Three practical notes:
- Ask in writing, and keep the answers. Not for evidence — so that the answers exist somewhere other than in a conversation you both half-remember.
- Ask for demonstration on the two that matter. "Can we restore a backup" is answered by restoring one. "Can somebody else deploy" is answered by somebody else deploying.
- Do not ask for a document. You will get one, it will take three weeks, and it will describe what its author remembers.
#What a good answer sounds like
You cannot evaluate the technical content. You can evaluate the shape of the answer, and that is usually enough.
| Question | A good answer | An answer to follow up |
|---|---|---|
| What does the product depend on? | A specific list, with the ones they are unsure about named as unsure | "The usual things" / a confident list with no uncertainty in it |
| Could somebody else take this over? | "Yes, in about X weeks, and the hard part would be Y" | "Of course" / "It would take longer to explain than to do" |
| What do we not know about our own system? | Three or four specific things | "Nothing" |
| Whose name is the cloud account in? | A definite answer, checked | "I'd have to look" — which is fine, as long as they then look |
The pattern: calibrated uncertainty is a good sign and total confidence is not. Nobody knows everything about a real system, so an answer with no gaps in it is an answer that has smoothed them over.
#Counting the concentration
One exercise, twenty minutes, and it is the most useful thing on this page.
List the parts of your product. For each one, write the name of every person who could answer a hard question about it. Then count the parts where that list has exactly one name on it.
Web application 3 people
Billing and payments 1 person ← Anna
Subscription logic 1 person ← Anna
Email and notifications 2 people
Infrastructure / deploys 1 person ← Marek
Nightly export 0 people ← nobody, it just runs
Mobile app 1 person ← an ex-contractorSeven parts. Four with a single point of failure, one with none at all, and one whose only expert has already left. Nothing is wrong with the company or the people — this is what an ordinary, successful, four-year-old product looks like when somebody counts.
You now have a risk register that is specific, honest and actionable, produced without reading a line of code.
#Where 1ADK helps, and where it does not
Where it helps
- Answering "what is it made of" and "what does it depend on" in plain language.
- Producing that answer without you having to trust a single person's account.
- Naming what nobody can confirm, so the gaps are visible to you too.
- Keeping the answers, so you can ask again in six months and see the difference.
Where it does not
- Account ownership. That is a survey and a set of transfers, and it is yours to do.
- Telling you who is good at their job.
- Judging whether the software is well built.
- Replacing a technical adviser you trust.
- Making decisions. It gives you the facts to decide with.
Questions people actually ask
No, and it would not help much. Being able to read a function does not tell you whether the domain is in your name, what your product depends on, or who is the only person who understands the billing system. Those are ownership questions, and they are answerable in plain language.
Framed as "I need to be able to answer this to an investor / an acquirer / an insurer", almost nobody objects, because it is true and it is not about them. A developer who reacts badly to "whose name is the cloud account in?" has told you something you needed to know.
It is enough evidence that they believe it. The useful follow-up is not "are you sure" — it is "can you show me, or can somebody else confirm it?". Anything that only one person can confirm is, by definition, concentrated in one person.
Whether the domain and the production infrastructure are in accounts your company owns. Everything else costs time and money to recover. Those two can leave you unable to operate your own product.