A senior operator will spend six months redesigning the company’s quarterly review cadence and arguing over which metrics belong in which deck. They’ll build it, defend it, iterate on it, and train the rest of the company into it. Then they’ll sit down to their own Monday and decide what to work on by feel.
The asymmetry is almost never noticed by the operator themselves. They experience the systematic part of their job as the responsible adult work, which it is, and they experience the improvised part of their own week as latitude they’ve earned. The two modes feel like they belong to different categories, as though the discipline that’s load-bearing for the business would be a strange thing to apply to a Monday morning.
The test for whether this asymmetry is real is an uncomfortable one. Imagine a peer CEO, someone you respect, telling you that they run their week by reading email for an hour in the morning and deciding what to do with the rest of the day based on what feels most pressing. You would quietly update your opinion of that person. You would decide they were running on improvisation, and you’d be a little surprised, because they’d seemed more rigorous than that. And yet that description is almost exactly how most senior operators, including you, run their own week.
The improvisation is working, which is the reason it persists. The operator is in the role because they’re good at reading what matters in the moment and acting on it, and that skill is what lets them improvise at a level that looks responsible from the outside. They finish the week with the urgent stuff handled and a reasonable claim to have made progress on the important stuff, and the question of whether they’d have finished with more of the important stuff under a designed week never gets asked, because the counterfactual doesn’t show up in any week they actually ran.
The cost of the asymmetry is invisible day-to-day, and it’s real. The clearest way to see it is at the moment of transition. A new person is stepping into the role. The operator is doing handover. The first thing the new person asks is how the operator manages their week, and the answer is that the operator manages their week by being good at their job. That’s not an answer the new person can use. It’s also not an answer the operator can defend in the same terms they’d defend the company’s operating system, which they’d never let a successor inherit without documentation.
What gets inherited, in practice, is the business’s operating system and nothing else. The meeting cadence, the review rhythms, the decision logs, the reporting structure. What gets lost is everything the outgoing operator was doing in the white space between those structures, which is usually where the actual running of the role was happening. The new person spends their first six months rebuilding a personal operating system from scratch, under the pressure of doing the job at the same time, and either they figure it out or they don’t.
The second place the cost shows up is in the operator’s own growth. A senior operator running their week on improvisation gets better at improvising, which is a skill with diminishing returns. The skill that rewards practice at the senior level is deciding what to batch, when to defer, what to leave on a monthly review instead of touching weekly, what to delegate in a way that actually holds. None of those skills develop when the week is run on instinct, because instinct doesn’t keep records, and the feedback loop on whether a given week worked requires records of what the week was meant to do.
Most senior operators, when this is pointed out to them, have two reactions. The first is that a designed personal system would turn them into a different kind of operator, one who can’t respond to the moment, and the flexibility is what makes them good. The second is that they’ve tried it and it felt like a straitjacket. Both reactions are worth taking seriously, and both are partially right and partially wrong.
The first reaction is wrong because a designed personal system separates the improvised parts of the week from the parts that shouldn’t be improvised. The weekly review, the monthly cadence for pattern-level inputs, the time blocked for thinking that can’t happen in reactive mode, and the default behavior for everything that falls outside those: these are the parts that have to exist before improvisation becomes useful. The operator who designs those parts and then improvises inside them is doing a different thing from the operator who improvises the whole week.
The second reaction is worth taking more seriously. Most of the off-the-shelf personal productivity systems feel like a straitjacket because they were designed for a person whose job is mostly doing tasks, not deciding what the tasks should be. A senior operator has a different problem: the volume of possible work is infinite, the correct choice of what to do next is non-obvious, and the feedback on whether the choice was right comes weeks later if at all. A personal system that fits that shape is closer to a policy document than a to-do list, and most operators have never tried building one because the templates available don’t look like anything they’d want.
Build the personal system the way you’d build the company’s. Start from the outcome you want the week to produce. Write down the cadence for each kind of work. Design the defaults for everything you’re not making active decisions about. Review it at the same interval you review the company’s, against the same standard of whether it’s doing the job it was built to do.
The asymmetry between how you run the company and how you run yourself is a kind of unfairness, and it’s unfair in the direction that costs you the most. The company gets your best work at the system level, and you get the version of yourself that nobody would have let run a twenty-person team. The fix is to stop exempting yourself from your own standards.
Pillar III
**Management Infrastructure**
> *Four memos on the coordination layer of a company: review rhythms, > side conversations, the tax of informal coordination, and where > execution slows down.*