Field Notes.
Five things I've come to believe about why decisions, delivery, and organizations actually break down — formed by years of doing the work, and sharpened against a lot of reading. Not book reports. Arguments.
← Back to the home pageFive notes.
Jump to any of them, or just read straight through.
Prioritization Is a Math Problem Wearing a Politics Costume
Most organizations prioritize by volume, not value — because nobody put a number on what waiting actually costs.
Your Best Leader Makes Different Decisions Depending on the Day
Bias is predictable. Noise — the same person deciding differently on the same case — is usually the bigger, invisible cost.
The System That Improves Is the One That Stops Looking for Someone to Blame
Aviation treats failure as data. Most organizations treat it as a story about who's at fault. The outcomes prove which approach wins.
Nobody Designs a Broken Organization on Purpose
Structure accumulates the way technical debt does — one reasonable decision at a time, never revisited once the constraints change.
Most Disagreements Aren't About Facts
Two people can watch the same meeting and walk away with different accounts, and neither one is lying.
Prioritization is a math problem wearing a politics costume.
Most organizations prioritize by volume, not value. The loudest voice in the room, the most recent fire, the executive who asked twice — these win over quieter, more valuable work every time, because nobody put a number on what "waiting" actually costs.
Every delayed initiative has a cost of delay: real, calculable, and different for every piece of work. A feature that captures revenue on a fixed launch date is not the same shape of problem as a fix that quietly compounds risk the longer it waits. Treat them the same and you'll consistently protect the wrong queue.
Once cost of delay is visible, prioritization stops being a debate about whose project matters more and starts being an argument about numbers everyone can see. That doesn't remove politics. It does make politics have to argue with math, which is a fight politics usually loses.
The harder discipline underneath this: queues are not neutral. A system running near full capacity doesn't degrade a little — it degrades sharply, the way a highway doesn't get "a bit" slower at 95% capacity, it stops. Most execution problems that get blamed on the team are actually a queue that was allowed to fill past the point where anything could move quickly through it.
"If you can't say what waiting costs, you don't actually have a priority — you have a preference."
Your best leader makes different decisions depending on the day.
Ask five people to evaluate the same case and you'll get five different answers. That's expected — that's bias, and everyone plans for it. What's stranger, and mostly invisible, is that the same person, looking at the same case twice, will often give two different answers depending on nothing more meaningful than mood, time of day, or what they judged right before it.
That's noise, not bias. Bias points errors in a consistent direction, so it's at least predictable. Noise is random scatter, and it's usually the bigger cost, because nobody's looking for it. Organizations audit for bias constantly. Almost none audit for the plain inconsistency of their own decision-making.
This is where a lot of "leadership alignment" problems actually live. It's not that priorities are wrong; it's that the same request gets a different answer depending on who reviews it, or when. Teams learn to route around this by shopping the decision to whoever's more likely to say yes today, which quietly destroys the legitimacy of the process itself.
The fix isn't more meetings. It's decision hygiene: separating people's judgments before they discuss them, breaking a decision into its component parts instead of asking for one holistic verdict, and building simple structure around decisions that get made often enough to warrant it. None of that requires more authority. It requires admitting that unmanaged judgment is noisier than anyone wants to believe.
"Teams don't lose faith in a process because it says no. They lose faith when it says something different every time."
The system that improves is the one that stops looking for someone to blame.
Aviation and healthcare have handled failure differently for decades, and the outcomes prove it. Aviation treats a crash as data: every incident gets a no-blame investigation, the findings get distributed industry-wide, and the same failure becomes structurally difficult to repeat. That's why flying got dramatically safer over the last sixty years, even as the systems got more complex.
Plenty of other institutions do the opposite. A failure becomes a story about who's at fault, the story gets defended instead of examined, and the actual mechanism of failure never gets named clearly enough to fix. The failure doesn't disappear — it just gets better at hiding, and it comes back.
I see the second version constantly in delivery organizations. A postmortem gets held. It's polite. Nobody's actually at fault, on the record, and nobody is structurally prevented from causing the same failure next quarter, either. The document gets filed. The pattern repeats in four months wearing a different name.
The difference isn't intelligence or effort. It's whether the organization has a real mechanism for turning failure into a structural change, versus a mechanism for making the discomfort of failure go away as fast as possible. You can tell which one you're in by asking a simple question: can you name the last time a failure actually changed how something works, not just how it's reported?
"A postmortem that doesn't change a structure was never really a postmortem. It was a eulogy."
Nobody designs a broken organization on purpose.
Every meeting that recurs, every approval layer, every policy that exists "because of what happened a few years back" was a reasonable decision once. Someone made a sensible call under the constraints they had at the time. The constraints changed. The decision didn't get revisited. Multiply that by a decade and you get an organization nobody designed, built entirely out of decisions that made sense individually and stopped making sense collectively.
That's organizational debt, and it behaves exactly like technical debt: invisible on any given day, and brutally expensive in aggregate. It doesn't show up as one dramatic failure. It shows up as friction everyone's used to — the extra approval nobody remembers the reason for, the standing meeting that outlived its purpose, the process built for a team of five now straining a team of fifty.
The reason this is hard to fix isn't that nobody notices. It's that no single piece of it is bad enough to justify the fight required to remove it. Killing one redundant approval step saves an afternoon. It's the compounding of hundreds of those steps that costs the organization its speed, and nobody owns the whole shape of it, so nobody's positioned to make that argument.
The move isn't a redesign. It's a standing practice — something has to be responsible for questioning the accumulated structure on a real cadence, or the debt only ever moves in one direction.
"Structure accumulates as sediment. Nobody sets out to bury the org in it — it just never gets swept."
Most disagreements aren't about facts.
Two people can watch the exact same meeting and walk away with completely different accounts of what happened, and neither one is lying. Between an observed fact and a stated conclusion, there are several invisible steps: which details you noticed, what you assumed those details meant, what you concluded from that meaning, and what you now believe as a result. Everyone climbs that ladder in a fraction of a second, and everyone climbs it a little differently, based on role, history, and whatever they were already worried about walking in.
The argument that follows isn't actually about the meeting. It's two people defending the top of their own ladder without either one realizing they've climbed one. That's why "let's just look at the facts" almost never resolves a real disagreement — both people think they already are.
The useful move is making the climb visible instead of arguing from the top of it: stating the specific thing you observed, saying plainly what you concluded from it and why, and then actually inviting the other person to test that reasoning rather than just restating their own conclusion louder. It's a small shift in how a sentence is built, and it changes a debate into a comparison of reasoning instead of a standoff between two people who are both certain they're simply describing reality.
"Nobody disagrees about what happened. They disagree about the six invisible steps between what happened and what they believe."
If this is the kind of thinking you want on your team, let's talk.
Hiring for a role, bringing in outside help, or just comparing notes — one direct conversation is where it starts.