A note on the rhythm beneath the rule, and why the gap between them is what experienced operators learn quietly, late.
There is a clock the IRS works to that isn’t the one written down.
The written one says three years. That’s the assessment statute of limitations: the window during which the IRS can reach back into a tax return and say, “actually, more is owed.” Three years from the filing date. That number has been three years for as long as I’ve been a CPA, and longer than I’ve been alive.
The other one, the one I learned slowly by watching senior practitioners who didn’t quite say it out loud, is twenty-eight months. The IRS internally targets closing audits inside twenty-eight months, not thirty-six. The last eight months are reserved for what comes after the audit closes: the formal notice, the petition window, the appeals dance, the Tax Court route. If a conversation needs to happen before the IRS has decided whether your return is a problem, it has to happen in the first twenty-eight months. Not in the thirty-six the statute promises.
Two clocks. Same system. Same return. The first one is what the law says. The second one is what the desk runs on. Practitioners who design their advisory work to the first clock get caught by the second. The window closed three months ago. The conversation that should have happened didn’t.
I keep finding this in places that aren’t about taxes.
Every operating system has an architecture. Boxes and arrows, an org chart, a written rule, a stated process. We talk about systems mostly at this layer, because the architecture is the part that’s documented. The Slack channels are named. The recurring meeting is on the calendar. The performance review is the second Friday of the quarter. The contract has a thirty-day notice provision. The decision rights are clear, on the page.
What’s missing in almost every description is the frequency the system actually runs at. Not the architecture. The rhythm beneath it. The cadence the people inside it have collectively agreed to operate at, often without anyone naming the agreement.
The Slack channel is named, but messages go quiet for ten days at a time, and three days is the threshold past which a question becomes a meeting. The recurring meeting is on the calendar Wednesday morning, but the actual cadence at which a decision can be made and acted on is two weeks, because the proposal lands Wednesday, the pushback lands the next Wednesday, and only by the third Wednesday does a thing get unblocked. The performance review is quarterly on the page, but compensation actually moves on an eighteen-month cycle because that’s how long it takes for a manager to gather enough evidence to defend a non-cost-of-living change. The contract says thirty days. The relationship says you raised it once, six months ago, and didn’t follow through, so the live frequency for a renegotiation is more like ninety.
In each of those, there’s a written architecture and a lived frequency, and the gap between the two is the under-named layer.
People who are good at operating inside systems learn the frequency early, often without being able to articulate it. They know when to send the Slack message. They know how many Wednesdays the proposal needs. They know when the comp conversation can actually move. People who are new to a system, or who design from outside it, work to the architecture. They write the well-formed Slack message on the wrong day. They expect the proposal to clear on the architecture’s Wednesday, not on the lived three-Wednesdays. They schedule the comp conversation at the quarterly review and wonder why nothing changes for a year and a half.
This is not a complaint about systems being slower than they look. It is an observation about a layer that is almost never written down.
The reason it isn’t written down, I think, is that the architecture is the part you can defend. The architecture is what you point to when someone asks “is this fair? is this legal? is this how it’s supposed to work?” The architecture exists in the form of documents: the policy, the statute, the org chart, the contract. The frequency exists nowhere except in the heads of the people who’ve operated the system long enough to feel it. There is no document for it because it isn’t the kind of thing you put in a document.
That’s why advisory work that operates only at the architectural layer feels thin to me, and increasingly does as I do more of it. Anyone can read the architecture. The advisor’s job, the work that’s worth being paid for, is to operate at the frequency layer. The client can’t see it from inside.
A founder running a company at the wrong frequency for two years is going to lose more than the founder who made one bad decision. The bad decision is recoverable. The wrong frequency compounds, quietly, in every direction at once. Hires move too fast for the operating tempo, financial close lags it, and customer conversations get scheduled to the calendar instead of the relationship. Partner alignment drifts to the quarterly review. Each one looks like a small architectural choice. Together they’re a frequency mismatch with the actual operating tempo of the business at its current size, and that mismatch is what eats the company before any single decision does.
I think about this with my own work, too. The architecture of running an advisory firm is well-documented: the agreements, the deliverables, the cadence on the calendar. The frequency at which a firm can actually take on a new engagement, ship a piece of original thinking, deepen a client relationship, recover from a setback. That isn’t in any book. I’m learning it month by month, and I’m not sure it’s the same frequency I was running at when I was inside an operator role. It probably isn’t.
I notice my own frequency shifts depending on what I’m building. A clean week of writing has a different rhythm than a clean week of client work. A week with two new prospects in it has a different rhythm than a week with three live engagements in motion. The architecture (calendar, deliverables, scopes) doesn’t change much from one to the next. The frequency does, and the frequency is what determines whether the week ships anything.
The IRS clock is a clean example because the gap between the two layers is so visible if you know to look for it. Three years on the page. Twenty-eight months at the desk. The advisor who confuses them gets the timing wrong on a conversation that has to happen, and then doesn’t.
The principle, though, is bigger than tax procedure. Most systems have a rule layer and a rhythm layer, and most descriptions stop at the rule layer. The rhythm layer is what determines what’s actually possible inside the system. It’s the thing experienced operators feel without naming.
I want to spend more time naming it.