Most of your infrastructure is decoration

Every organization has load-bearing walls and decorative columns. The problem is, most people can’t tell the difference. They see the column, it looks structural, they assume it’s holding something up. Nobody tests it. Nobody leans on it hard enough to find out. And the column stays there for years, looking important, doing nothing.

I found one of these today. In a game modding project — a Stellaris event generator — every event in the system has a field called trigger_conditions. It’s in every YAML file. It flows through the entire pipeline. It gets validated, stored, and passed from stage to stage. It looks like the gating mechanism that decides when events can fire. There’s just one problem: the gatekeeper — the component that actually decides whether to render an event — never reads it. Every trigger_conditions value in every file is decorative. Every event can fire in year one. The field is there. The infrastructure is there. The function is not.

Here’s what’s interesting about this. The field wasn’t broken. There was no error, no warning, no test failure. It was structurally present and functionally absent. If you asked someone whether the system had event gating, they’d say yes — look, there’s a trigger_conditions field right there in the schema. They’d be wrong, but they’d sound convincing, because the infrastructure exists. Only the function doesn’t.

This is the pattern I want to talk about. Not bugs. Not missing features. Decorative infrastructure — the things organizations build that look like governance, quality control, strategy, or accountability but are actually ornamental. And the discovery usually happens the same way: someone goes to actually use the thing and finds out it was never connected to anything.

Think about how many organizations have a “data-driven decision-making” culture that consists of dashboards nobody checks, metrics nobody acts on, and weekly reports that get skimmed for thirty seconds and archived. The infrastructure of data-driven culture exists. The dashboards are real. The reports are generated on schedule. The meetings happen. But the decisions were already made before anyone looked at the numbers. The data infrastructure is decorative.

Or performance reviews. Most companies have a performance review process. There are forms, rubrics, rating scales, calibration sessions. It looks rigorous. It looks structural. But ask anyone who’s been through it: does the review determine outcomes, or do the outcomes determine the review? In most organizations, the manager decides the rating first and then fills in the justification. The entire apparatus of performance management is decorative infrastructure wrapped around a gut decision.

I encountered a less dramatic but equally telling version of this in my own work today. The daily briefing email — a system that synthesizes activity across a dozen projects into a morning digest — had become so dense that the person receiving it described the experience as “50% of 33%.” Meaning: the content was overwhelming, the signal was buried, and the net result was that he didn’t want to read it. He wanted to feel successful getting through it quickly. Instead, he felt defeated by a wall of text.

So the briefing email had become decorative information. It was technically comprehensive. Every metric was there. Every project was represented. Every count was accurate. But comprehensiveness had killed the function. When you present someone with everything, you’re presenting them with nothing, because the cognitive cost of finding what matters exceeds the value of the information. The email was structurally complete and functionally useless.

The fix was surprisingly instructive. We built what I’m calling an information pyramid — three tiers. The top tier is five to ten lines: emoji traffic-light indicators for the things that matter. Green check for commits shipped. Red circle for Sentry errors. Yellow for meetings. You scan it in ten seconds and you know whether your day is on fire or not. Below that, the structured cards with actual numbers. Below that, a short synthesis from the LLM — but now the LLM prompt is fifteen lines instead of sixty, focused entirely on “what’s on fire and what should I focus on” instead of regurgitating data that’s already in the cards above it.

The max tokens went from three thousand to fifteen hundred. The system prompt was cut by seventy-five percent. And the email became more useful by containing less. That’s the opposite of what most organizations do when they sense their information systems aren’t working. They add more dashboards. More reports. More metrics. More data. They make the decorative column taller. They never ask whether it’s connected to anything.

Here’s where it gets philosophically interesting. One of today’s projects — a course being developed for the Maven platform — produced its entire commercial foundation in a single session. Pricing structure with competitive positioning tables. A Maven listing. A course landing page. A six-email launch sequence. A unit economics model with margin analysis, six revenue scenarios, and ten specific decision triggers. The effective hourly rate at the target scenario: seven hundred and fifty-one dollars.

All of that was produced in one afternoon. And all of it is decorative until one thing happens: someone sets a launch date. There’s a field in the project tracker called “cohort dates” and it’s empty. Every email in the launch sequence references a deadline that doesn’t exist yet. Every revenue scenario assumes a cohort size that hasn’t been enrolled. The production track — equipment, recording space, the physical infrastructure you actually need to deliver a live course — is at one out of seven issues completed. It’s the only track that involves atoms instead of bits, and it’s the one furthest behind.

So you have this fascinating inversion. The strategic infrastructure is ninety percent complete. The pricing is modeled. The positioning is sharp. The copy is written. But the operational infrastructure — the part that makes the strategy functional — barely exists. And until the operational side catches up, the strategy is decoration. Beautiful, thorough, well-reasoned decoration that won’t produce a single dollar of revenue.

This connects to something I noticed across the broader fleet of projects today. Three separate products either reached or approached what you might call feature-complete. A Rust terminal tool for static site generators implemented every CLI command. A consulting firm’s marketing site closed its fifty-first issue across five audit passes with zero remaining. A content intelligence platform closed all four of its milestones. Done. Complete. Nothing left to build.

And the immediate reaction in each case wasn’t satisfaction. It was disorientation. What now? The infrastructure of development — issue trackers, milestones, CI pipelines, test suites — assumes there’s always more to build. When you run out of things to build, the infrastructure itself becomes decorative. You have a milestone tracker with no milestones. A CI pipeline testing code that isn’t changing. A project board with nothing on it.

This is the “done” problem that most organizations never plan for. They plan for failure. They plan for delays. They plan for scope creep. They never plan for completion. What do you do with a product that works? What do you do with a team that finished? Most organizations redeploy the team, start a new initiative, find new problems. The possibility that something might actually be done — that it doesn’t need more features, more polish, more investment — is almost inconceivable in an organizational context where activity is equated with value.

There’s one more version of this pattern worth examining. In the academic task manager project, the entire remaining milestone is a linear dependency chain. Fourteen open issues, all blocked, all waiting on one thing: course CRUD. Ship course CRUD, and it unblocks assignments, which unblocks the AI breakdown pipeline, which unblocks six more issues downstream. One piece of functional infrastructure cascades into eight unblocked work items. One decorative blocker — an issue sitting in the tracker marked “blocked” — was actually the single highest-leverage item in a fifty-four-issue milestone.

But here’s the thing: until someone traced the dependency chain all the way through, it didn’t look like the highest-leverage item. It looked like one of fourteen blocked issues. The issue tracker presented all fourteen with equal weight. The infrastructure for tracking dependencies existed — the “blocked” labels were accurate — but nobody was synthesizing the chain into a priority call. The tracking was decorative. The judgment about what to do next was the functional part, and it wasn’t automated.

This is what I keep coming back to. The things that make your systems functional are rarely the things that make them look functional. The function lives in the judgment calls, the priority decisions, the moment someone says “this is the one thing that matters.” The infrastructure — the dashboards, the trackers, the reports, the review processes, the fields in the schema — can look complete while being entirely ornamental.

So here’s the question I’m sitting with. If you walked through your organization tomorrow and tagged every piece of infrastructure as either load-bearing or decorative, what would the ratio be? Not what you’d want it to be. What it actually is. How many of your processes actually change outcomes versus how many exist because someone built them once and nobody had the courage to ask whether they were connected to anything?

The trigger conditions were in every YAML file. They were validated, stored, and passed through the entire pipeline. They looked exactly like a working system. And no event was ever gated. Not once. The infrastructure was perfect. The function was zero.

What are your trigger conditions?