Sorting is a practice, not an audit

The audit is the version everyone tries first, because it feels like the responsible thing to do.

You block out a week. Maybe you bring someone in. You go through the system top to bottom and produce a document, and the document is genuinely good. It names the dead weight. It finds two things nobody had looked at in three years. Everyone reads it, everyone agrees, and a few of the easy cuts actually happen.

Then it goes in a drive folder and the company gets on with its year.

Eighteen months later somebody proposes an audit. It is a good idea, it is the same idea, and the document it produces will name several of the same things. Nobody notices, because the person who ran the first one has moved teams.

The audit fails for the same reason a purge fails. Drift is not an event, it is a constant force. Something is quietly leaving the room every week and the label is staying behind every week, and a one-time inspection is a snapshot of a river. You do not counter a constant force with an occasional heroic act. You counter it with another constant force, smaller and duller and always running.

That is the difference between an audit and a practice. An audit is a thing you do. A practice is a thing you have.

Before the procedure, one piece of vocabulary, because it has been implicit and should not be.

Core, Platform, Bloat and No-Go are categories. They describe what a thing is. Core Drift, Load-Bearing Fear and Platform Mismatch are shapes. They describe how a thing gets misfiled over time. You sort into the categories. You use the shapes to understand why a sort is fighting you.

Now, the sort.

Who is in the room. Small. Five or six, not the whole department. You need the people who know the system, the ones who can say what a service does without opening it, because a sort run by people who have to go and check is not a sort, it is a research project.

And you need at least one person who can ask "why do we still have this" without paying for it. That is the seat most companies get wrong. It cannot be only leadership, because a room of leadership will politely route around the thing leadership built. It cannot be only the team, because the team will not say the quiet thing in front of the person who signed off on it. What you want is someone senior enough to be safe and detached enough to be rude. A staff engineer from another area. A newer principal. Sometimes someone from outside the company.

How long, how often. Ninety minutes, once a quarter.

The time box is the mechanism, not a nicety. A sort that takes a day gets scheduled, then moved, then quietly abandoned when the quarter gets ugly. A sort that takes ninety minutes survives contact with a bad quarter, and surviving a bad quarter is the point, because a bad quarter is when drift accelerates and review stops.

Quarterly is chosen against the welding problem. A cut is cheap right up until other work has welded itself to the thing you were going to cut, and that takes months rather than weeks. Quarterly catches most things while they are still a sentence and not yet a foundation. Twice a year does not.

Running it. Item by item. A service, a feature, a process, a standing meeting, a tool, a contract. Each one gets a category.

Most go fast. That is not a sign the sort is shallow, it is a sign the team knows its system, and the speed is what buys time for the two or three items that matter.

When the room cannot agree, stop. Do not vote. Do not split the difference. That is the tell, and it is the most valuable thing the meeting will produce. Write the item down, write what each side thinks it is, and move on. You are not there to resolve it. You are there to find it.

The output is three lists. Keep. Cut. Tells.

What happens to the output, which is where most sorts die.

Every cut gets a name and a date. Not a team, a person, and not "next quarter," an actual date. A cut without an owner is a wish.

Every keep gets a present-tense reason. One sentence about what it does for you now, not what it did when you built it. This is the cheapest part of the exercise and the most protective, because a keep with no present-tense sentence behind it is Core Drift caught in the act, found in ninety minutes instead of in a rewrite two years out.

Every tell gets an experiment. Not a follow-up meeting, an experiment. Remove the thing behind a flag for four weeks and see what screams, with a window and a rollback and a name attached.

Three lists, three fates. Cuts get done. Keeps get justified. Tells get tested. Nothing gets filed.

And when you skip a quarter, which happens, because something will be on fire.

The cost is not linear. Skipping one sort does not cost you one sort. Drift ran for six months instead of three, so two of the items you would have cut in April now have work built on top of them, and the cheap cut has become a migration.

So keep it small enough that you rarely have to skip it. Ninety minutes is defensible when the quarter is on fire. A full day is not, and that is the whole reason for the number.

You can run this. It is not complicated and nothing in it requires permission. Two notes below on what it looks like in the wild: one on the document where sorting pays best, and one on the quarter it does not survive.

There is one thing, though, that no amount of procedure fixes, and it is not in the method. It is in the room. The person who knows the system best is the worst placed to see it, and the further up that scale you go the worse it gets, until you arrive at the founder.

That is where I go after these.

Cases in this series are composites. The patterns are real, the companies are not.

The full Core and Bloat™ method, four boxes and all, sits at dirkbauer.com/core-and-bloat.html.

A roadmap arrives on the table. Everything is on it. Eleven initiatives, and the argument in the room is about which three to do first.

Nobody has proposed removing anything. That is not an oversight, it is the shape of most roadmaps, because a roadmap is an addition-only object. Things get added in planning, moved down when priorities shift, and carried forward. They rarely come off. The removal muscle has never been used on this document, and it shows.

Which makes the roadmap a sort waiting to happen, and nobody has run it.

So run it. Not on the system. On the roadmap itself, item by item.

What is genuinely Core to the next two quarters? Not "important." Core. If you did this and nothing else, would the company be materially better off.

What is on here because it was Core eighteen months ago? That is Core Drift sitting on a planning document instead of in a codebase, and it is harder to see because a roadmap item has no running cost you can point at. It just absorbs arguments and headcount and attention, quarter after quarter, never quite dying.

And what is on here that the company already decided against? That happens more than you would think. A No-Go nobody wrote down does not stay off the roadmap. It comes back as an initiative, with a slide.

The roadmap is where drift is most expensive and least visible, and the reason is specific. Everything on a roadmap was, at the moment it was added, obviously worth doing. That is the entry criterion. So the document is made entirely of things that once looked essential, which is exactly the material bloat is made of, and it is the one document nobody thinks to sort.

The team had the practice. Ninety minutes, in the calendar, quarterly. It had run three times and it was working. Then a big customer went sideways, the whole quarter turned into a rescue, and somebody moved the sort.

Reasonable. Obviously reasonable. There was a fire.

It moved again in May, and by June nobody moved it, because by June it was not really a thing they did any more. It lasted three quarters and died in one, and nobody made a decision to kill it.

That is the part worth sitting with, because it is not a discipline problem.

The quarter that cancels the sort tends to be the quarter that most needed it, and the two share a cause. A quarter under pressure is a quarter where you add without removing, take the shortcut and mean to come back, say yes to the thing that keeps the deal alive. That quarter manufactures more drift than the four calm ones around it, and it is the one quarter in which nobody can find ninety minutes.

So the practice is weakest exactly where the load is heaviest. That is a design flaw, and you do not fix a design flaw with resolve.

Design for the bad quarter instead, because the bad quarter is the test that counts.

Make it small enough to be undeniable. Nobody can argue that ninety minutes sank the rescue. Half a day they can, and a team that scheduled half a day has already decided which quarters it will skip, whether or not they know it yet.

Give it an owner who is not the person running the rescue. If the same person is accountable for both, the sort loses, and it should.

And when it does get cancelled, schedule the next one before you leave the room. Not "we will pick it back up." A date. The practice does not die from one cancellation. It dies from the silence afterwards, where nobody quite decides anything.

A method with no cadence is an essay you agreed with.