Your week, in double-stack proportions

The wrongly framed question

"Will AI replace me?" is the question almost everyone asks and almost no one can answer, because it's built on a false premise: that a job is a single unit, a solid block that survives whole or disappears whole. Under that premise, the question only admits two answers — yes or no — and neither is useful for deciding anything, because no real job is homogeneous. A financial analyst doesn't do one single thing for eight hours. They reformat reports, reconcile figures against a checklist, but they also decide which anomaly deserves a call to the director and which is noise. A project manager doesn't just update a board: they also decide which risk to escalate and which to absorb in silence. The right question isn't whether the entire job survives, but in what proportion it's made of tasks a cheap model already executes today, and in what proportion it's made of tasks no model can execute because the success criterion isn't written down anywhere yet.

That proportion is what this framework calls the double stack applied to a career: an execution layer — how the work gets done, following an already specified process, producing an output whose quality standard someone already defined — and a decision layer — which problem is worth tackling, how to judge an ambiguous result, who takes responsibility when the decision can't be undone. This essay's lede states it plainly: if someone's work disappears the moment a cheap model shows up, it was execution. If it doesn't disappear, it was decision. Most jobs are not purely one or the other — they're a mix, and that mix has a measurable proportion, not a binary label stuck to the job title.

The error of treating a job as a monolithic block has a practical consequence: it points the anxiety at the wrong object. Someone can spend an entire year worrying about whether "project managers are going to disappear" while ignoring that half of their own week is already trivially automatable and the other half isn't at all. The right question doesn't point at an entire professional category. It points at a specific calendar agenda, this week's, the one anyone can open right now and audit.

Audit the week, not the job title

The exercise is simple to describe and somewhat uncomfortable to do honestly: take a typical work week, list every significant block of time, and classify each one into one of two columns. In the execution column go the tasks where the process is written down or can be written down unambiguously, and where the criterion for "done well" already exists before starting. In the decision column go the tasks where no one — not even the person doing them — could write down in advance the complete rule that determines the correct outcome.

Take a generic hypothetical example, not attributed to any real person: someone in a project coordination role at a mid-sized company. Monday is spent updating the status board with the progress each team reported by email — that's reformatting information according to an already defined format: pure execution. Tuesday morning they draft the weekly summary for leadership following the company's standard template — also execution, even though it requires competent writing. Tuesday afternoon, however, they decide which of the three reported delays deserves escalation to a committee and which can be absorbed by adjusting the schedule without telling anyone further up — that's not in any manual, because it depends on reading the political context of the moment, the client's risk tolerance, and the credibility the coordinator has accumulated with the committee. That's decision. Wednesday they reconcile billed hours against the approved budget — mechanical execution. Thursday they negotiate with an external vendor who missed a delivery, deciding whether to push for a contractual penalty or preserve the relationship at the cost of absorbing the delay — that requires judgment on a trade-off no one can resolve with a formula. Friday they prepare the slides for the monthly report using the usual format — execution — and close the week by deciding, without anyone explicitly asking, that the entire project needs a scope change they haven't yet proposed to anyone. That last decision, identifying a problem no one else had named yet, is the purest form of the decision layer: not evaluating a given option, but deciding that the question itself was wrongly framed.

Counting the hours, this hypothetical coordinator might discover they spent close to two-thirds of their week in the execution column. That's not a diagnosis of imminent obsolescence — it's a data point. The data point matters because a reasonably good language model can already reformat a status board, draft a summary following a template, and reconcile figures against a budget with minimal supervision. It cannot — not yet, and maybe never reliably — decide which delay deserves political escalation, take responsibility for a negotiation with a vendor, or notice that a project's scope is poorly defined before someone tells it so.

What to do with the result

The result of this audit is not a verdict, nor is it an instruction to abandon every execution task. That would be a reading error as serious as treating the job as a monolithic block. Some execution is always necessary: someone has to reformat the report, update the board, reconcile the figures, and doing it well is a condition for the organization to function. No professional — not even the most senior — ever reaches a hundred percent decision proportion. The question was never to eliminate execution. It was to notice the current proportion and decide, with the same lack of drama with which one reviews a budget, whether that proportion is moving in the right direction over time.

Moving the proportion doesn't require a career reinvention or an artificial deadline. It requires choosing, week after week, to delegate the execution that can already be delegated — to a tool, a model, a junior colleague — and using the freed-up time to exercise more judgment, not to accumulate more executable tasks of a different kind. The coordinator in the example could automate the board update and the template-based summary, and use those recovered hours to anticipate risks before they become reportable delays, or to redesign how project scope gets defined from the start. That doesn't reduce their workload — it changes its composition. The proportion shifts toward the decision layer not by decree but by the accumulation of small choices, each defensible on its own.

There's no false urgency in this, no date after which it's too late. The proportion of any work week can be audited today, next month, or a year from now, and the exercise gives the same useful information every time: how much of the current work depends on no one else having yet automated an already-written process, and how much depends on a judgment that still can't be written down. The first part is going to shrink, with this model or the next one. The second is, literally, the only thing left when you subtract from a job everything that can already be executed without it.