The Best Test of Your Architecture Is Leaving for Two Weeks

On every team I've worked on there was someone who never took holidays.

Not because they didn't want to. Because they couldn't. If they left for two weeks, something fell over. And everyone knew it, including whichever boss was around, who also mentioned it with pride in their meetings.

For years I thought that person was valuable. Now I think they're a symptom.

The counterpoint to what I've been writing

These past weeks I've insisted on an idea: the one who knows why that odd field is in that table is the only source of something the company has written down nowhere. I still think that's true.

But there's a part I didn't tell, and the missing part changes the conclusion quite a bit, the way I see it. Being the only one who knows something (of value) has 2 problems, and they have to be looked at separately.

For the company it's a single point of failure. That's obvious and everyone accepts it in theory, even though in practice nobody does anything about it until that person resigns.
For you it's something else, and it's the one barely discussed. Being indispensable is a cage with a good salary.

The person who can't leave for 2 weeks also can't change project, or move to another area, or ask for a promotion that takes them out of where they are, or accept something better elsewhere without feeling they're leaving a fire behind. Their value is entirely tied to one place and one moment. That isn't job security. It's a mortgage disguised as recognition.

And the trap is that it feels good for quite a while. That they always call you, that nobody else can solve it, that your name shows up in every escalation. It looks a lot like being important. It even feeds your ego.

The test

There's a fairly brutal way to find out which of the two sides you're on, and it needs no tool and no course to pay for. Go away for two weeks for real. Without checking email. If you come back and everything kept running, you built a system, or your company runs fine on its own.

If they called you on day three, what you built is a dependency with your name on it.

The good thing about this is that it works the same for an architecture, for a team and for a career.

A system that needs you watching it constantly, and where if it blows up you're the only one who fixes it, isn't a system, it's a manual process with extra steps. A team where only one person can solve a certain thing isn't a team, it's that person with companions. And a career that depends on nobody else knowing what you know isn't a career, it's a position.

All three look perfect as long as nothing changes. All three blow up the same way when something does.

The paradox

Here's where it gets spicy, because both are true at the same time and it can give you an anxiety attack on the spot if you're not well prepared.

What makes you hard for a model to replace is exactly the same thing that makes you hard to move: the knowledge in your head and in no document. The why of that exception, the reason that process has run backwards since 2014, the name of the person you have to call before touching that.

As long as that lives only in your head, no AI touches you (for now). And neither does any other opportunity. If you write it down, you gain mobility and lose exclusivity. If you don't write it down, you keep the exclusivity and you stay put.

So: my silly question is this: being indispensable in the age of AI, is it a blessing or a curse?

My answer without thinking about it too much is that it depends entirely on one thing: where the indispensability comes from.

If you're indispensable because nobody else has the information, it's a curse shaped like a compliment. That kind of indispensability has an expiry date and you don't choose it: it ends the day the company decides to document everything to feed the agents, and that day will come almost everywhere.

If you're indispensable because you're the one who decides what gets touched and what doesn't, it's a blessing and on top of that it's portable. You take it with you anywhere. The first one dies in your hands. The second one compounds.

Automating your own work is an act of well-understood selfishness

There's a concrete way to move from the first to the second, and it isn't philosophical but very practical.

Automate your own work. Document your own processes. Write the runbook for the things only you know how to do. Don't frame it as generosity toward the company (you're not some benevolent soul for doing it), because it isn't and besides, framed that way you'll never do it. Frame it as what it really is: leaving everything documented is investing in not being bothered.

Every thing you automate is a call you won't get on a Saturday while you're making pizzas. Every process you write down is one fewer interruption in the middle of something that does matter. Every repetitive task you hand to a script or an agent is time you get back for the part of the job where your judgment actually moves the needle.

People who resist documenting think they're protecting their position. That was the 80s or the 90s. Doing it is actually signing a servitude contract with your own calendar.

And here's the part few tend to do: it isn't about automating just anything. The judgment is in choosing what gets automated. There are tasks that look repetitive and aren't, because every time you do them you're looking at something no script will look at. There, automation doesn't save time, it hides the problem until it blows up in production. That distinction, knowing which is which, is exactly the kind of judgment that doesn't get documented and doesn't get replaced.

Delegating the execution is not the same as delegating the thinking. It's the difference between having a machine that works for you and being the operator of a machine you don't understand.

Why this might matter to you

Now put this next to what's happening at any company this year.

Everyone is trying to document the business context so agents can work with it. Mapping processes, writing rules, making explicit the why of things. And a lot of people with years of trade experience it as a threat, because they feel they're writing the manual for their own replacement.

I understand the feeling and it doesn't strike me as paranoid. But I think it confuses two different things. The one who knows why that field is there and wrote it down is still the one who decides what gets touched and what doesn't, the one who detects when something doesn't add up, the one who says "don't automate this yet". That person is more valuable after documenting, not less, because now they can move and take the judgment with them.

The one who knows why that field is there and never wrote it down is fragile in both ways at once: they can't leave, and the day they're let go anyway, they take nothing demonstrable with them.

Besides, what you don't document doesn't disappear: it becomes somebody else's debt. The Z programs nobody understands today were also, at the time, somebody's job security. That person is gone. The code isn't. Exclusivity is a defense that works until it stops working, and when it stops working it finds you with nothing.

Before you agree with me

I'll list 2 things against all this.

At a badly run company, documenting yourself until you stop being exclusive can indeed make you expendable. Not every place rewards the person who organizes the knowledge. Some simply take advantage and then cut. If you work at one of those, this advice has a real cost and it's worth measuring first.
The anxiety of the person who never takes holidays isn't always about architecture. Sometimes it's pure workload, and no amount of documentation fixes you being two people doing the work of five. There the problem is headcount, not design, and confusing them makes people blame themselves for something that isn't on them.

What I'm going to do

Next week I'm taking holidays. No laptop, for real.

I'm going to run the test, and honestly I don't know how it'll go. You write these things with more confidence than you have on a Tuesday morning. But there's one thing I am sure about, and it's the only thing I want you to take from all this if you haven't started scrolling and you're still here reading:

If your only way of being important at work is that nobody else can do what you do, then you're not the owner of your career. You're the hostage of your position.

And the difference between the two only shows up when you try to leave.

Pablo / En Producción

P.S. This is the last edition for two weeks. Planned "In Production" maintenance window, announced in advance and with the system running on its own. Which is, more or less, what this whole thing was about.

P.S.2 Don't miss me too much... otherwise I'm on IG.