Directory · P
Not sure this is the right entry? Run the check · New here? Start with the premise
Parenting
2 min read · 400 words
Children learn far more from what you actually do than from what you tell them. The templates get taken from your rate, your tone, your handling of stress — not from the instruction.
Is this you?
Check whatever lands. Nothing is sent anywhere.
Parenting is the operation of one control room shaping the construction of another, during the years when the second one is being built.
A new operator arrives in a new machine. The machine comes with hardware — temperament, sensitivities, capacities. The software is mostly unwritten. The early caregivers — the ones operating the machinery in proximity — provide the inputs that the new system will compile into its operating assumptions. What gets modeled becomes default. What gets received becomes expectation. What gets repeated becomes the architecture.
The mechanism most parents misunderstand: the new system does not learn primarily from instruction. It learns from observation. The operator who tells the child how to manage emotion while visibly mismanaging their own is teaching the visible behavior, not the spoken instruction. The system being built absorbs what the surrounding system is actually doing — its rate, its tone, its responses to stress, its handling of conflict, its baseline state — and uses these as templates.
This produces the central paradox: the most powerful parenting input is the parent’s own functioning. The operator who works on their own system produces the conditions a child can develop within. The operator who tries to engineer the child while their own machinery runs in dysfunction often produces a child who absorbs the dysfunction while consciously rejecting the engineering.
From the chair: parenting cannot be performed competently while ignoring the operator’s own state. The interventions that matter most — regulation under stress, repair after rupture, presence over performance, honesty about limits — all require the operator to be working on themselves. The child does not need a perfect operator. The child needs an operator who is visibly attempting their own development, who can acknowledge mistakes without collapse, and who provides reliable presence when the child’s system is overloaded.
The other component: the child is a separate operator. The Identity entry’s distinction applies — the child’s machine is not the parent’s machine, and the child’s operator is not an extension of the parent. The work is to build the conditions for development, not to determine the outcome. What emerges from the system being built is partially given, partially shaped by environment, and ultimately not controllable. The parent’s job is not to produce a particular result. It is to provide the conditions and step back as the new operator takes the controls.
The template is taken from behaviour, not instruction
A new system arrives with hardware — temperament, sensitivities, capacities — and mostly unwritten software. The people operating nearby supply the inputs it compiles into its operating assumptions. What gets modelled becomes default. What gets received becomes expectation. What gets repeated becomes architecture.
The part most people underestimate: it learns far more from observation than from instruction. Telling a child how to manage emotion while visibly mismanaging your own teaches the visible behaviour. The system being built absorbs what the surrounding system actually does — its pace, its tone, its stress responses, its handling of conflict, its baseline state — and uses those as templates.
Which is uncomfortable and also clarifying. The highest-leverage thing available isn't a technique applied to them; it's what you're running yourself, because that's what's being copied regardless of what's being said.
There's a second mechanism worth knowing. Your own installed code fires in these situations faster than deliberation — which is why you can hear your parent come out of your mouth, and why losing it tends to cluster around specific repeating triggers rather than being random.
Find the trigger, not the technique
The repeating blow-up is more informative than any general resolution to be more patient.
Real questions
Why doesn't my child listen to what I tell them?
Because instruction is a weak channel compared with observation. The templates get compiled from what you actually do — your pace, your tone, how you handle stress and conflict, what your baseline state is — and where those conflict with what you say, the behaviour wins. It's why telling a child to stay calm while visibly not staying calm teaches the second thing, reliably, however many times the first is said.
Why do I hear my own parent coming out of my mouth?
Because that code was installed during the maximum-sensitivity period and it fires faster than deliberation — you're in the response before you've registered choosing it. It isn't a sign you've become them, and it is a sign the pattern is running unexamined. Catching the specific trigger is more useful than general resolve, because the entry point is where it can actually be interrupted.
Why do I lose my temper at the same thing every time?
Two things usually stack: the moment is hitting something from your own early code, and you're reliably depleted when it happens. Most parental blow-ups cluster around state rather than around the child's behaviour, which matters because the fix is different — changing the timing, the handover or your own condition going in does more than resolving to respond better once you're already in it.
Am I damaging my child when I get it wrong?
Isolated failures aren't the mechanism — what gets compiled is what's repeated, not what happened once. There's also good reason to think repair matters more than never rupturing: a child who sees things go wrong and then get acknowledged and mended is learning something genuinely useful about how relationships work. Perfection isn't available and isn't the variable.
How much of who they become is down to me?
Less than the guilt implies and more than nothing. They arrive with their own hardware — temperament, sensitivities, capacities — which you didn't supply and can't override. What you supply is the environment that code gets compiled in. That's substantial and it isn't total, and treating it as total tends to produce both excessive credit and excessive blame.
What's the single most useful thing I can do?
Work on what you're actually running, because that's what's being copied. That sounds like a deflection and it's the opposite — it's the highest-leverage thing available, and considerably harder than applying a technique to them. Your regulation, your repair after conflict, how you handle being wrong: those are being learned whether or not they're being taught.