Short answer
#The principle
There is a version of this advice that tells founders to learn enough programming to be dangerous. It is well-meant and it solves the wrong problem: the difficulty 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, like knowing where the contracts are filed.
#The twelve
What we own — four
The only group where a wrong answer can leave you unable to operate. All four are checkable by you, personally, this afternoon.
- Whose name is the domain registered in, and where does its recovery email go?
- Whose account are the production servers in, and who is billed for them?
- If your most senior technical person left tomorrow, could you still get into everything?
- Which outside services does the product pay for? Your bank statement is a rough map of what the software depends on, from a completely independent direction.
What the system is — four
- What are the main parts, and what does each do? Five to fifteen things, one sentence each. Not a technical description.
- 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, without anybody starting it?
How exposed we are — four
- Which parts can only one person explain?
- How long would it take another team to take this over, and why that long?
- When was a backup last actually restored — not configured, restored?
- What does nobody here currently know about our own system?
#When each one becomes urgent
The reason to establish them now is that every one of these arrives as somebody else's deadline.
| Moment | What gets asked |
|---|---|
| A key person resigns | Ownership, concentration, and what nobody else can explain — all in the same week |
| Investment or acquisition diligence | Everything on the list, in writing, with a deadline you did not set |
| A large customer's procurement | Where data lives, what leaves, who has access, what the recovery position is |
| An insurer or an auditor | Backups, recovery, access control, dependencies |
| An outage | What depends on what, and who can be called |
| Changing supplier | All of it, and now it is a negotiation |
None of these is avoidable, and all of them are cheaper to answer on an ordinary Tuesday than on the day they are asked.
#How to get them
-
Check the ownership four yourself
Registrar records, cloud billing, and your own bank statements. None of this requires asking anybody, and it is the group where a wrong answer is most expensive.
-
Ask for the system four to be derived, not written
Components, dependencies, data, scheduled work. Asking for a document produces a document written from memory; asking for it to be derived produces something checkable in hours.
-
Do the concentration count yourself
List the parts of the product. Write who could answer a hard question about each. Count the parts with exactly one name. Twenty minutes, and it is always revealing.
-
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. Neither is answered by a yes.
-
Write the answers down somewhere that is not a conversation
The point is that the company holds them, not that you personally remember them.
#What you do not need to know
Worth being explicit, because founder-education advice tends to expand indefinitely.
- How the code works. Not at any level of detail. It will not help you make a single decision you would otherwise get wrong.
- Which framework or language was used, beyond knowing whether it is one people can be hired for.
- Architecture opinions. Whether services should be split, whether the database schema is elegant. These are engineering judgements and having a founder's opinion on them is usually a cost.
- How to read a pull request.
The distinction is consistent: you need the answers a company should be able to produce about an asset it owns. You do not need the skills of the people who maintain it.
#What goes wrong
Learning to code in order to supervise.
Instead Learn to ask twelve questions and to recognise a good answer. It takes an afternoon and it works better.
Accepting “it is all under control” as an answer.
Instead That is evidence somebody believes it. Ask to be shown, or ask whether anybody else can confirm it.
Asking as an audit.
Instead Ask as continuity: you need to be able to answer this to somebody outside the company. True, and not about the person you are asking.
Getting the answers once.
Instead The system changes. Answers from eighteen months ago describe a different product.
Keeping the answers in your own head.
Instead The whole point is that the company holds them. A founder who is the only person who knows has recreated the problem one level up.
#What this does not cover
What this does not do
- Whether your team is any good. Not a question a list answers.
- Technical strategy — what to build, what to rewrite, what to buy.
- Security posture beyond the recovery and access questions above.
- Hiring a first technical leader, which is its own problem.
- Anything specific to a regulated industry.