I don’t like broccoli. Depending on where I am — a restaurant, a dinner party, a work lunch — I will quietly move it to the side of the plate and carry on with the meal. Nobody notices. Nobody cares. The plate looks mostly finished. Everyone is satisfied.

After fifteen years at Microsoft, coming across internal and customer implementations of most major governance and management framework you can name, I have come to believe that most organizations do the same thing with their methodologies. They adopt a framework. They get the certifications. They roll out the templates. And then, quietly, they push the broccoli to the side of the plate.

The word broccoli traces back to the Latin brocchus, meaning something that sticks out, something protruding. Broccoli is, etymologically, the part that sticks out. In framework adoption, the broccoli is the part of the methodology that sticks out in the same way: the uncomfortable principle, the founding element that is visible, load-bearing, and impossible to ignore — except through a conscious act of avoidance. It is the part of the framework that is uncomfortable. The part that forces difficult conversations, exposes gaps in accountability, or demands rigor that slows people down. Every major methodology has founding principles that hold the whole structure together — and in practice, organizations routinely leave one or more of those principles out. What remains looks like the framework. It has the vocabulary, the artifacts, the meeting cadences. But the load-bearing mechanism is gone, and nobody talks about it.

To be fair, the broccoli rarely gets left on the plate out of laziness or bad faith. The reasons are structural and human. Organizations are complex — technically and politically — and the founding principles of frameworks often require cross-functional alignment that cuts against the grain of how teams are actually organized. Resources are finite, and the hard parts of a methodology are almost always the most resource intensive. People carry multiple roles: the project manager who is also a technical lead, the risk owner who is also running three other programs, the service manager who has no dedicated staff. When you are stretched thin, the uncomfortable principle — the one that demands a difficult stakeholder conversation, or a mapping exercise that no one has time for — is the first thing to slip. Not because it doesn’t matter, but because everything else feels more urgent.

The result is that the broccoli gets left on the plate not once, as a deliberate decision, but gradually, through a thousand small acts of pragmatic triage. I would bet that most of the readers will recognize such a pattern and would be able to identify the broccoli in their recent corporate meals. And I have seen this pattern so many times that I can almost predict which piece will be left.

The Broccoli, Framework by Framework

ITIL is built on a simple premise: IT services exist to support business processes. That is the foundation. Everything — service design, service transition, continual improvement — flows from the idea that the service catalog maps to what the business needs. In practice, I watched organizations define services that mapped perfectly to their internal IT org chart. A “cloud management service” that didn’t support any identifiable business process but corresponded neatly to a team in infrastructure. The service catalog became a mirror of the IT department, not a bridge to the business. The broccoli — aligning services to business outcomes — was too politically awkward. It would have required conversations about which teams really delivered value, and which were organizational artifacts. So, it was left on the plate, and ITIL often became an expensive relabeling exercise.

Project management under PMI has a similar story. Organizations invest in PMP certifications for their project managers. They adopt the PMBOK terminology. They run projects through phase gates. But the charter — the foundational document where outcomes are agreed with stakeholders, where success criteria are made specific and measurable — is routinely skipped or reduced to a paragraph of generic benefits that very few will ever measure. Without a real charter, the project drifts toward deliverables and milestones as ends in themselves. Dependencies that put those milestones at risk get buried because surfacing them would require difficult conversations with stakeholders or adjacent teams. The project team optimizes for avoiding exposure rather than delivering outcomes. The broccoli — binding the project to measurable results and confronting the dependencies that threaten them — sits untouched.

Agile suffers perhaps the most creative avoidance. The core admission of Agile is radical: you do not know in detail what the implementation will look like at the start. You trust the methodology — iterative delivery, continuous feedback, working software as the measure of progress — to guide you toward value aligned with your goals. That admission of uncertainty is the broccoli. It is uncomfortable for stakeholders who want fixed scope, fixed timelines, and fixed budgets. So, what emerges in many organizations is what I call “Improvised Wagile”: a creative hybrid of Waterfall and Agile where the team uses Agile ceremonies — standups, sprints, retrospectives — but operates under a fixed scope, fixed milestones, and fixed resources. The methodology’s founding principle has been surgically removed. What remains is Waterfall with better meeting hygiene.

Risk management under COSO follows the same pattern. Organizations are generally willing to do the analytical work: map the risks, build the heat maps, assign likelihood and impact scores, prioritize. This part is intellectually satisfying and produces impressive presentations. The broccoli is execution — managing the effectiveness of controls and mitigations over time. Are the controls actually working? Is there evidence that mitigation plans were implemented and had their intended effect? In many organizations I have seen, the answer is that plans exist on paper, but evidence of execution and effectiveness is thin or absent. The risk register becomes a living document in name only — a snapshot that is periodically refreshed but never truly operationalized.

Dancing Without Listening to the Music

There is a common thread across all of these cases. When organizations leave the broccoli on the plate, what remains is process as performance: the dance steps without the music. Meetings happen. Deliverables are produced. Presentations are given. Approvals are granted. The choreography is visible and familiar. But the underlying purpose of the framework — the thing the founding principles were designed to ensure — has been forgotten.

This has always been a problem, but it was a survivable one. The deliverables themselves had weight. A risk assessment required real analysis. A service catalog demanded mapping work. The effort involved in producing the artifacts created a kind of incidental rigor, a false sense of realization — even when the hard conversations were avoided, the work of creating the documents forced at least some engagement with the substance.

Now add AI.

The Emperor’s New Deliverables

In a previous essay, I argued that AI has removed the constraints that shaped decades of software and process design — and that our mental models haven’t caught up. The broccoli problem makes that argument concrete.

When AI can generate a project charter in minutes, the charter is no longer a forcing function for thinking. When a risk register can be populated instantly, the analytical work that used to create incidental engagement with the substance disappears. When status reports, service catalogs, and compliance documentation can be produced at near-zero effort, the artifacts that once gave the illusion of rigor lose even that incidental value.

What remains is the broccoli — the uncomfortable, substantive, politically difficult work that the framework was designed to ensure in the first place. Aligning services to business outcomes. Binding projects to measurable results. Admitting uncertainty. Verifying that controls really work.

AI strips the camouflage from framework adoption that was already incomplete. The deliverables that used to provide cover — that made it look like the methodology was being followed — become trivially easy to produce and therefore trivially easy to see through. The dance steps, performed without the music, were always hollow. AI just makes them obviously hollow.

This is the emperor’s new clothes moment for organizational processes. The organizations that were already eating their broccoli will barely notice — AI simply accelerates work they were doing with substance. But the organizations that have been quietly pushing the hard parts aside will find that the easy parts, which used to take enough effort to feel meaningful, now take no effort at all. And when the easy parts are effortless, all that’s left is what was being avoided.

You Will Have to Eat Your Broccoli — The Opportunity

There are mature organizations where none of this applies. They do the hard work. They have the uncomfortable conversations. Their frameworks function work as designed because the founding principles are intact. For them, AI is a straightforward accelerator.

But for the many organizations where the broccoli pattern is the norm — and I believe it is far more common than most leaders acknowledge — AI adoption is about to force a reckoning. The path forward is not more deliverables, faster. It is going back to the founding principles of the frameworks these organizations already claim to follow and asking, with honesty, which ones were left on the plate.

Here is the counterintuitive opportunity: the same removal of constraints that exposes the broccoli problem can also make the broccoli easier to eat. Remember the structural reasons organizations skipped the hard parts — complexity, scarce resources, people stretched across multiple roles. When AI absorbs the mechanical burden of producing deliverables, drafting documentation, synthesizing data, and maintaining status visibility, it frees exactly the capacity that was missing. The project manager who never had time for a real charter conversation now has time, because the drafting work that consumed her week takes minutes. The risk owner juggling three programs can now review control effectiveness, because the evidence gathering that used to be a manual audit is now continuous. The service manager can finally align to business processes, because the mapping work that required weeks of interviews can be accelerated dramatically.

The removal of constraints — what I called the moment when the room changed in When Constraints Disappear — doesn’t just expose what was being avoided. It removes many of the legitimate reasons it was being avoided. Organizations can focus on the right goals instead of the right documents. They can leverage their talent on the substantive problems — stakeholder alignment, outcome definition, control effectiveness — instead of on the production work that used to crowd those problems out. The conversation shifts from implementation to adoption and value: not “did we produce the artifact” but “did we achieve the outcome the framework was designed to ensure.”

That is where the real work of AI adoption begins — not with the technology, but with the disciplines that the technology now makes both impossible to fake and, for the first time, genuinely possible to practice. In a follow-up to this essay, I intend to explore what that looks like in practice: how organizations can use this moment not just to adopt AI, but to finally eat their broccoli.

In the opening chapter of How Music Works, David Byrne shares what he calls a “slow-dawning insight”: that context, not internal emotion, is the primary force shaping creative output. He describes standing in Gothic cathedrals and realizing that the long, modal, slowly evolving compositions of medieval church music weren’t the product of unsophisticated musical thinking — they were perfectly engineered for a room where sound can hang in the air (reverberate) for up to four seconds. A chord change before the previous chord had dissipated would have sounded like mud. The composers weren’t primitive. They were, in Byrne’s word, adaptive. They wrote for the room they were in.

He extends this argument across centuries of music history. Jazz solos originated not as artistic expression but as a pragmatic solution to a logistical problem: the written melody would run out while dancers were still on the floor, so musicians kept playing over the chord changes to buy time. Songs in the 1970s were three to four minutes long not because that’s the natural duration of a human musical idea, but because that’s what fit on one side of a vinyl single — and songs placed closer to the center of a record had to carry less bass, because the grooves were physically tighter. The room, the format, the physics: these shaped the art. The composers and musicians adapted so naturally that, eventually, nobody remembered the room.

Byrne’s phrase for this is “creation in reverse.” We like to imagine that artists begin with pure creative vision and then find the means to express it. His argument is that the opposite is usually true: we work backward from the context that exists, creating work that fits the venue available to us.

This essay argues that exactly the same dynamic has governed the history of technology — and that we are living through the moment when the room has finally changed.

The Technical Cathedral

Consider what “truths” the technology industry has treated as universal over the last fifty years, truths so embedded that they stopped being perceived as constraints at all:

“Software needs a user interface.” This became axiomatic because computers couldn’t interpret intent — they needed humans to translate their needs into precise inputs through structured forms, menus, and buttons. Natural language was computationally too expensive to parse at scale. So we built entire disciplines (UX design, information architecture, accessibility) around the challenge of making interfaces less terrible. We didn’t question whether the interface was the right solution. It was the room.

“Processes happen in steps.” Submit a form, wait for processing, receive an output. This architecture exists because computers were discrete, batch-oriented machines. Real-time continuous processing was expensive. So business workflows were modeled as sequences: intake, review, approve, notify. The step-based structure wasn’t native to the problem — it was native to the machine.

“Meetings exist to synchronize teams.” Before shared documents, persistent messaging, and asynchronous collaboration tools, the meeting was the only mechanism for getting everyone to the same version of reality at the same time. Calendar-based rhythms — weekly standups, monthly reviews, quarterly planning — emerged from the cost of coordination, not from the nature of the work. The meeting is a seam in a world that no longer needs most of its seams.

“Reports are how organizations know what’s happening.” The monthly report, the quarterly dashboard, the annual audit: these are rhythms imposed by the cost of data collection and synthesis. When pulling information together required significant human labor, you did it on a schedule. The schedule became the ritual. The ritual became policy. The policy became “the way things are done.”

“Data needs to live in one place.” Databases were expensive. Storage was expensive. Moving data between systems required custom integration work that could take months. This forced enormous simplification: you picked one system of record, and everything else adapted to it. The single source of truth was not a philosophical position — it was an economic necessity. It has long since ceased to be either.

None of these “truths” emerged from the nature of the problems they were solving. They emerged from the constraints of the technology that existed when the patterns were first laid down. Like medieval modal harmony, they were compositions written for a specific room. And like that music, they became so natural that the room became invisible.

The effect runs deeper than product design. The governance and management frameworks that organizations have built around technology — COSO, ISO standards, ITIL before v5, PMBOK, NIST, and their many cousins — were shaped by exactly the same constraints. They are profoundly procedural: step-by-step, gate-driven, committee-reviewed, document-heavy. COSO’s internal control framework is organized around formal reporting lines and periodic assessments because continuous monitoring was not feasible when the framework was designed. ISO certification cycles run on annual rhythms because auditing was expensive and labor-intensive. Project management methodologies emphasize deliverables — charters, status reports, sign-off artifacts — because the handoff between humans was the critical coordination mechanism in a world where systems couldn’t carry context forward on their own. These frameworks codified best practice for a specific technical era. They were, like the modal chants, exactly right for their room. The question now is whether organizations will recognize that the room has changed — or whether they will keep auditing the acoustics of a cathedral they no longer work in.

Technical Implementation Bias

There is a name for what happens when this invisibility becomes systemic: technical implementation bias. It is the unconscious tendency to shape new solutions around what used to be hard, even when the hardness is gone.

Technical implementation bias is why the first generation of AI products largely consisted of AI filling out forms faster. The form remained — we just added intelligence to the task of completing it. It is why “chatbots” were conceived as replacements for menu-driven phone trees, replicating the interaction pattern of the thing they were meant to replace. It is why early e-commerce was basically a paper catalog with a shopping cart bolted on.

This is entirely understandable. It is the same mechanism Byrne describes. Composers didn’t fail to imagine other kinds of music — they were writing for the room they were standing in, and doing it well. So were we. Adaptive thinking within a given constraint set is not a flaw; it is how people and organizations survive. The problem arrives later, quietly, when the room changes and the music doesn’t notice.

The Room Has Changed

The nature of the shift brought by AI is not primarily about capability — though the capabilities are remarkable. It is about which constraints have been removed. For the first time in the history of commercial software development, several things are simultaneously true:

• The marginal cost of cognition is approaching zero
• Generation and synthesis are instantaneous
• The cost of iteration is measured in seconds, not sprints
• Natural language is a viable interface between humans and machines
• Integration between systems is a software problem, not an infrastructure project

This means the constraints that shaped decades of product design have been lifted almost simultaneously. The solution space is now wider than most teams’ imagination of it. And that is precisely where the problem lies. As Byrne observed about music: when the room disappears, you have to decide what to write.

People feel disoriented. Teams default to the familiar. The old mental models persist not because they’re still valid, but because they’ve been internalized so deeply, they no longer feel like choices. We are still designing cathedral music in a world with headphones.

Ten Heuristics for a Post-Constraint Era

What follows is a set of working heuristics for people trying to approach problems without the invisible walls of technical implementation bias. These are not rules — they are prompts for noticing when you’re about to compose for a room that no longer exists.

1. Start from capability extremes, not feasibility

The old question was: what can we build with this tech stack? That question had the room baked into it.

The new question is: if intelligence, generation, and automation were effectively free — what would the ideal experience be? Assume near-zero cost of cognition, instant personalization, infinite iteration. Design that first. Then introduce only the constraints that are genuinely real: regulatory requirements, trust thresholds, ethical boundaries. These are chosen constraints. Everything else is a vestigial groove from the vinyl era.

This prevents premature narrowing — the most expensive mistake in product design, because it looks like rigor.

2. Separate “problem truth” from “implementation artifact”

Most current solutions are distorted by legacy constraints that have been absorbed into the definition of the problem itself. When someone says “we need a better ticketing system,” the ticket is already in the room. Strip the nouns back to verbs and frustrations. What is the person actually trying to do when they file a ticket? Almost certainly: get something fixed, get acknowledged, not lose track of an issue. None of those require a ticket.

Ask of every element in an existing workflow: does this exist because of human memory limits, UI constraints, batch processing, file formats, or organizational latency? If yes, it is an implementation artifact. It earned its place in a different room. It does not automatically deserve a place in the next one.

3. Design for continuous systems, not discrete steps

Pre-AI systems are step-based: submit → process → output. This architecture is native to batch computing, not to human problems. Human problems are continuous. A health condition doesn’t wait for a quarterly review. A compliance risk doesn’t resolve itself between report cycles. A customer’s frustration doesn’t pause at the ticket queue.

AI-native systems can be ongoing, adaptive loops — continuously collaborating toward an outcome rather than executing discrete transactions. The heuristic is to replace “user does X → system returns Y” with “system continuously moves toward outcome Z, surfacing only what requires human judgment.” Think co-pilot, not tool. Think ongoing relationship, not completed transaction.

4. Invert the human-machine boundary

The historic division of labor was clear: humans think, machines execute. This was a constraint, not a design choice. The constraint is gone.

The useful question now is: what would a human only do if they had infinite intelligent assistance? The answer, almost always, is: judgment, taste, ethical decision-making, and trust. Everything else — research, synthesis, drafting, analysis, routing, follow-up — is negotiable. It doesn’t mean humans shouldn’t do those things. It means they now do them by choice, not by necessity, and that the design of any system should reflect that distinction.

5. Use time-to-value compression as a north star

AI collapses time in a way that fundamentally changes what “good” looks like. Measure ideas not by their features, outputs, or intermediate steps, but by how close they get the user to the final outcome immediately.

The best AI-native products feel like skipping the process entirely. Not faster forms — no forms. Not better reports — no waiting for reports. Not improved dashboards — no dashboard required, because the insight arrives before you thought to look for it. If the design still has a meaningful gap between “user intent” and “outcome,” the gap is worth questioning.

6. Replace features with outcomes

Old products sold tools: documents, dashboards, CRMs, ticketing systems. The tools existed because producing outcomes required human effort, and the tools were what scaled human effort. AI-native products can deliver finished results — not tools to produce them.

The reframe: don’t build a “presentation tool.” Build a system that produces a persuasive narrative given an intent. Don’t build a “knowledge management system.” Build a system that ensures the right person has the right context at the right moment. This is not semantic. It determines what you build, how you measure it, and what your customers pay for.

7. Introduce artificial constraints deliberately

Here is the paradox: when constraints disappear, people often freeze. The blank canvas is harder to work from than the constrained one. This was always true of creative work, and it is true of product design.

The answer is not to let legacy constraints fill the void. It is to introduce new, enabling constraints — designed for the present rather than inherited from the past. Latency budgets (instant vs. deep-thinking modes). Explainability levels. Human-in-the-loop checkpoints calibrated to trust, not to technical limitation. Cost ceilings per automated decision.

These are Byrne’s cathedral acoustics — but chosen, not inherited. The difference between a cage and a frame is whether you put it there on purpose.

8. Think in probability spaces, not deterministic flows

Legacy systems were built around the idea of correct answers: the right output, the approved record, the filed report. This was a constraint of deterministic computing — systems produced single answers because that’s what machines did.

AI systems explore a space of possibilities. They produce probability distributions, ranked options, and confidence-weighted outputs. This is not a limitation to be engineered around — it is a feature that changes how interfaces should work. Design for exploration, ranking, and refinement rather than exact correctness. Make iteration the native mode of interaction, not the fallback when the first answer is wrong.

9. Assume interfaces are optional

Many of the most durable assumptions in software design — that users need screens, that products need navigation, that systems need dashboards — exist because humans required structured interfaces to interact with machines. Natural language was too expensive to parse. Context was too complex to infer.

Before reaching for a UI, ask whether it’s actually needed. Sometimes the best product is an agent that acts. Sometimes it’s an API that integrates. Sometimes it’s a workflow that runs invisibly and only surfaces when something requires a human decision. The interface should be earned, not assumed.

10. Anchor in human trust, not technical possibility

When constraints disappear, risk increases — not because the technology is less reliable, but because the surface area for things that matter grows so rapidly. The real limiting factor in AI-era design is not what can be built. It is what people will rely on for something important.

The design question shifts from “can this be built?” to “would someone trust this with something that matters?” That shift changes everything: what you measure, how you test, what you explain, where you put humans, and what you leave to the system. Trust is not a feature. It is the new ceiling.

The Cathedral Is Not the Music

There is a role emerging in technology organizations — sometimes called a forward-deployed engineer — whose core function is precisely this: to sit with a client’s existing processes and ask which of their “requirements” are songs written for a cathedral that no longer exists.

It is a harder conversation than it sounds. The cathedral was real. The music composed for it was genuinely good. The people who built the workflows and the systems were not wrong — they were adaptive, just as Byrne’s medieval composers were adaptive. The constraint-shaped solution served its purpose. The problem is only when the constraint disappears and the solution doesn’t notice.

Byrne concluded that music didn’t evolve freely — it evolved to fit rooms, formats, and physics. He argued that this isn’t a failure of imagination; it’s how creativity works. We adapt to the context we’re in. The interesting moment is when the context changes.

The context has changed. The room is different. The question is no longer what we can build — the answer to that is, effectively, anything. The question is what should exist, and which constraints we choose to keep.

That’s a different kind of composition. And it requires noticing, first, that the cathedral is gone.