All the things you never chose
They will bite you in the @ss when you find out what you've agreed to.
Recommended Reads
The Fractional Operator by Rini Kothari
Practical systems thinking for founders, operators, and executives. Learn how to diagnose bottlenecks, build companies that scale, and make better decisions.
The operator behind the operator (yours truly) got locked out of his own laptop by a security feature he never turned on. That was two weeks ago, and I’m still deciding whether to invoice myself for the diagnosis. But hey, if you’re going to humiliate yourself professionally, at least let it have a decent punchline.
Your infrastructure will not warn you before it fails. Warning you was never part of the arrangement, and the fact that you assumed otherwise is the actual finding. This is especially true if your brain is one of those on overdrive the whole time, with 266 things going on at the same time while a squirrel rings the church bells and sings XMAS carols. Hi.
I wanted to access a file that was supposed to be on my workhorse machine. It’s an always-on laptop that runs scheduled tasks and hosts some drives for me. But it was not available, which was the first symptom that something was not right.
So I went checking. It was off. Weird. Maybe there was a power outage overnight that I didn’t notice. I turned on my machine and got a full screen demand for a BitLocker recovery key, on a laptop where BitLocker had never been active. Something in there decided that week was the right time to start asking for consent, several years and several thousand unencrypted files too late.
I found a key in my Microsoft account, one created a couple of months ago in the wee hours of a Monday, at a time when the chances I would be doing something on the computer are absolutely zero. Whatever. That key unlocked the system partition and the main disk, and for four minutes I felt like a functioning adult. Then the second disk in that same machine refused to move, locked behind a key that existed nowhere.
Well sh£t.
My external backups covered the data up until a couple of days before the crash, which is the only reason this is an article and not a career change. The drive itself stayed locked inside my own laptop, guarded by a key I never chose and was never offered the chance to refuse.
Somebody designed it that way on purpose. Encryption that activates without asking, a key that can go missing on the vendor’s side, and a user who finds out about the whole arrangement at boot time is a set of decisions made in a room I was not invited to. I have no publishable adjectives to describe that person.
Windows 11 calls this automatic device encryption, and it arms itself the moment you sign in with a Microsoft account, then encrypts every fixed drive in the machine including the ones Windows does not live on. The key is supposed to escrow to that account at the moment encryption arms, and it gets one attempt to do it. Sometimes that sync fails, which means the drive or worse, the whole device, gets encrypted but the key is never delivered to the MS account. And that is why people keep finding their device listed in their account with an empty space where the key should be.
I didn’t know any of that, and I’m clearly not the only one.
Run that through the audit I usually sell to other people and it fails on both axes. I never consented to the encryption, and by the time it surfaced, the exit cost was every file I hadn’t backed up recently enough.
All that to say the following. There are two types of dependencies: the chosen ones, and the ones that sneak in and install themselves unannounced. Everything has dependencies, and it’s on us to choose which type we will be dealing with.
Dependencies stay invisible until the moment they break, which means that, for the sneaky ones, the first time you see the full map is during the emergency. That is a terrible hour to start drawing maps.
The risk of each dependency is also not really connected to how big it is, but to whether something else can take its place. A large dependency with three available fallbacks is safer than a small one with none.
What made it lethal in my case was the delay. That encryption sat there producing no signal whatsoever, right up until the moment it produced all of them at once.
A system that only reports at the point of collapse has been lying by omission the entire time it worked. Reliability and honesty are separate variables, and most operators discover that distinction during an outage.
Risk assessment, with the information available right before the crash, would have shrugged at that second disk. It had never failed, and by every available measure it was behaving perfectly right up until the morning it stopped.
This is why I am a strong proponent of a dependency audit. The audit asks a crucial question, which is whether you ever agreed to each specific arrangement. A dependency that performs well and that you never chose is still a finding you should probably act on, because performing and being chosen are unrelated properties.
Getting locked out made me angry enough to finally open the drawer with eight external drives in it, going back years. Folders labeled things like “old stuff 2”, which implies an original "old stuff” that got demoted, are always good starting points.
Now every one of those drives was locally reasonable when it went in. Nobody decides to accumulate eight unaudited archives, they just add the eighth one on a regular Tuesday and never evaluate the set as a set.
This scales past hardware without changing shape at all. Nobody decides that one client should carry sixty percent of their revenue either, they just say yes to good work eleven times in a row and never once put the eleven yeses side by side. Most people rely solely on public power grids until the day they lose 10 hours of work because a someone tripped a circuit breaker in Spain. Most people rely exclusively on the city’s water supply until they can’t drink or shower for 4 days after a tornado.
Which brings me to the part I’d rather sweep under the rug. My brain gets a huge dopamine hit for building stuff and nothing at all for maintenance, so the return trip never gets scheduled and the drawer fills on its own.
Unconventional brains get no reward signal from going back to check, so the loop never closes and the pile grows without anyone deciding it should.
If that describes you, you have run that experiment enough times to already know it. The loop is missing from our factory settings, and willpower is a poor substitute for a loop. You (and by you I mean myself too) need scaffolding.
As if this wasn’t enough, there is a second problem stacked on top of the first. A new tool delivers the same hit as a new build, so intake never slows down while review never starts. Adding stuff is FUN. Which, in turn, means that dependencies arrive at the speed of light and get audited by our due diligence’s spirit animal: a snail. The gap between those two rates is sitting in a drawer somewhere with your name on it.
A reinforcing loop with the balancing half missing has only one direction available to grow, and it runs that direction until something explodes. Mine got interrupted by a full laptop lock demanding a key I did not have.
But there’s a part of this little pandemonium I like even less about myself than the eight drives. I went looking for a tool to do the consolidation, tried quite a few, and concluded that none of them were built by anyone who had thought about this specific problem properly. I was right about that, which is the detail that makes it unbelievable.
Then I built my own version, and the whole time I was building it I was aware of how much I was enjoying being the person who had to. That reflex has served me well professionally and it is the same reflex that produced the drawer. Being good enough at systems to fix things eventually is exactly what lets you postpone fixing anything now, because you know you’ll figure out a way down the line. Probably.
So I stopped trying to want it and installed the missing sensor instead. The scaffolding. I used a cataloging tool called VVV (virtual volumes view) to index every drive and every file, which was the first time anything in my setup could actually see everything I owned at once.
A system with no sensor runs on vibes. I had been running eight drives on vibes for years, with total confidence throughout.
Then I fed the catalog into Claude Code and built the consolidation strategy from it, working out which drive would serve as the base and how to fold the other seven in without dropping anything that existed in only one place. Deduped and cleaned up the biggest drive, copied it to my local disk, wiped the original back to nothing, then bounced that copy plus the other seven back in one at a time, deduplicating between disks as I went.
Seventy percent size reduction. Eight unaudited archives became one drive with a map. You can guess how much trash was in them. Most of it was old OS installations I no longer needed.
Then I got clever and tried to package the whole thing into a reusable skill, which failed twice in ways I had coming. The first one: I iested against simply asking the model directly, and my skill performed no better significantly, so the layer I had added was doing nothing except being a complexity layer. Trash it is.
The second failure is the one worth your attention. The copy runs came back reported as complete, and on a proper audit it turned out more than forty percent of the files had never made it across.
So Claude Code told me the job was done, then discovered on inspection that it wasn’t. I had built a backup process whose status report was written by the same process doing the work, which is not a sensor again.
Anything grading its own homework is running open loop no matter how confident the output reads. Feedback has to come from outside the thing being measured, which is exactly why the cataloging step worked and my own report did not.
So now every transfer gets verified by FreeFileSync, which had no hand in doing the copying and therefore no stake in telling me it went well. It compares both sides file by file and reports every difference it finds, and nothing gets wiped until that comparison comes back with nothing left to report.
That correction cost me one afternoon and a fair amount of self-respect. I am tired of knowing and preaching that verification has to sit outside the operation being verified, otherwise you are asking a process whether it enjoyed its own work.
None of this is an argument for owning less or depending on nothing. Even because that doesn’t exist. Everybody and everything depends on something. But a dependency you would choose again after looking at it directly and evaluating it is ok. Because the closest we can get to self-sufficiency is choosing dependencies for which we have redundancies.
Both of my failures in this case ran on the same clock. Long delay with no signal, then everything at once. Every unaudited dependency in your operation (and your life) is doing right now while behaving perfectly on the outside. They are timebombs, and the clock is ticking even if you don’t hear it.
Go open the drawer. It might not be a real drawer, but I’m sure you have a few of them. Find everything hiding in plain sight that has gone untouched for months, and get honest about what happens when any of it stops cooperating, because it will.
Every item gets one of three answers, and “fine” is not one of them. The first two are 1. keep it on purpose and eat the maintenance cost, or 2. reduce the exit cost until leaving stops being a threat.
The third answer is deletion, reserved for anything surviving only because nobody looked at it. Inertia is not a decision, though it does a remarkable impression of one. Out the window it goes.
You already have your own metaphorical BitLocker sitting somewhere, waiting for a regular Tuesday exactly like mine. It isn’t personal. It just has better timing than you do.
Happy building,
—R.