That means you are delegating more than you decided to. Not because you chose to, but because the work stopped waiting for you.

We used to communicate a lot and decide a little; now we decide a lot and communicate about the same amount, or less. The decisions didn’t stop happening. They stopped surfacing on the way to happening, or making it back to you afterward.

AI made delegation cheap and decision visibility expensive. More people can now turn intent into output without waiting for the old checkpoints. But the organization still has to understand which decisions were made, why they were made, and what now depends on them. The examples above are engineering examples because software engineering provides the clearest data points. But this structural shift applies to anyone turning intent into output with AI. Solutions, Product Management, Finance, Marketing — this is happening in all departments. Anyone building something, from a spreadsheet to software is making these calls now, faster than the org around them can register that a call was even made.

Think about what used to surface decisions. When execution was slow, people ran into walls constantly. When someone got stuck or something took longer than people were expecting, you talked about it. The act of getting stuck forced some communication; a conversation with the manager, a project meeting, an RFC, something that created alignment and contained an explanation. The slowness was annoying. But it had a clear purpose, even if that purpose was implicitly realized: it queued decisions where leaders could see them and be informed. The bottleneck was where you caught things.

That queue is mostly gone. The barriers that used to take days or weeks to clear, get cleared in an afternoon. The decision that would have waited for a one-on-one gets resolved before anyone meets. The regular meetings are all still on the calendar. They’ve just stopped being where discussion and informing happens. You and your people are still accountable for the call; it’s just that the information doesn’t get back to everyone in the room.

So here’s what’s actually happening, because most people feel what’s going on without having the words for it: scope quietly inflated at every level all at once. It did for the person above you. And for the person below you. Nobody held a meeting about it. And yet, each person’s reach got wider, which made each manager’s surface area wider, which made the layer above them’s reach wider still. The number of decisions made at each of those levels inflated to match. And those decisions are getting made wherever the work is happening.

And now everyone’s work reaches further than it used to. AI lets people stretch deep into other people’s territory — other roles, and even other disciplines — by appearing to cover the knowledge gap that used to prevent, or at least deter, that overreach. And that reach grew faster than anyone’s judgment about when to use it.

This is a structural problem, not a stylistic one, and you don’t get to opt out of it. The only thing you get to decide is whether those decisions are made with enough context to be good decisions, and whether anyone can see them after the fact.

Why Decisions Stay Quiet

A decision made below your line of sight has two ways to reach you. Someone tells you, or you find out later the hard way, usually when something breaks. One is a sentence in a standup; the other is a postmortem. And which one you get is almost entirely a question of whether the person who made the call felt it was their job to surface the issue.

When a builder goes quiet, they’re not usually blocked by technology. They’re blocked on a question they can’t or don’t want to articulate: is this mine to decide? Sometimes it’s “I’m not sure I’m allowed to make this decision.” Sometimes it’s “I don’t want to be the one responsible for it.” Sometimes it’s “I don’t have enough context to keep going and I’m not sure where to find that context.” Those are three different problems that are usually wearing the same outfit — “AI can’t do this” — and none of them is actually about what AI can or can’t do.

There’s a fourth version that doesn’t quite look like someone getting stuck. It’s that the individual actively decides not to act. They stop short because finishing the work would mean stepping into another team’s territory. They tell themselves the polite thing to do is leave it for whoever normally owns it. Or maybe that’s just more responsibility than they want to take on.

Any way you slice it, that’s still a decision. It just looks like deference.

The person made a call about scope and ownership and didn’t name it as such, so it never reaches you either. Not surfacing a decision and quietly deciding not to act are the same problem from your side of the table: a choice got made below your line of sight and you have no idea that it happened.

What they do have in common is that the person stopped for some reason and probably didn’t surface “the real” why. That why is the signal you need most, because it’s where you make the operational investment that empowers people: here is where the work is actually hard, which is the same as saying here is where we should invest, so the next person doesn’t get stuck in the same place.

But that signal needs at least two things to survive. One, the person has to notice they made a call at all — that the quiet workaround, the abandoned task, the thing the model suggested, was a decision and not just “the work.” And two, they have to feel it’s their concern to raise. That combination of noticing your own decisions and treating them as worth surfacing, is most of what agency actually is. And it’s what separates a team that merely ships from one that stays aligned while it ships. A group of capable people each making good private calls isn’t a team; it’s a set of parallel tracks that quietly drift apart. Surfacing is what keeps them converging and keeps people aligned.

The Invisible Delegation Cascade

Most people sense this layer is there. Fewer have come to terms with how far down it goes, or what it actually costs.

It isn’t only managers who are delegating more without noticing. The builders are doing it too. They are delegating their decisions to the model. Someone working with an AI accepts a retry policy, a schema choice, a new library, and a hundred small structural calls the model proposed and the builder waved through. Each one is a decision that used to be part of the process of writing code. Most never get registered as decisions. They get registered as “the code (A-)I wrote today.” The human is in the loop, technically. But the loop is moving fast enough that a lot of what passes through it doesn’t get the requisite level of scrutiny. It just gets accepted.

The human in the loop has become a crossing guard, waving everyone through without ever looking at the traffic.

Murphy Trueman made a version of this point about design systems: hand an agent a system with undocumented gaps and it fills them with the internet’s average, silently, returning a guess that looks identical to the parts it got right. The same thing happens to decisions, one level up. Murphy is representing the gap in the design and the code. I’m agreeing and furthering it org-wide. But the mechanism is identical: a silent fill that looks exactly like a choice someone made on purpose.

So the delegation is happening at every layer at once. The org delegated more to the manager; the manager delegated more to the engineer; the engineer delegated more to the model. And at each hop, decisions get made and not all are surfaced. By the time anything reaches you as the leader, you’re not looking at the decision anymore. You’re looking at the downstream impact of decisions nobody quite remembers making, with no clear line back to the calls that produced them. Including, sometimes, the person or model who made them.

I’m not suggesting you claw it all back. You can’t, nor should you want to. Pushing decisions down to the people closest to the work is the right move. It was also the right move before AI made it unavoidable and becoming more and more the norm. The problem isn’t that the decisions moved. It’s that now they’re moving invisibly. A decision you can see is one you can revisit when it turns out to be problematic. A decision that dissolved into “the code (A-)I wrote today” is one you find three months later, load-bearing, with everyone already building on top of it like it was decided with intention.

Infrastructure, Not Hygiene

The obvious objection is that, if every retry policy and schema choice is a decision, surfacing all of them would bury you. Nobody can ingest that amount of information. You’re right to call that out, and that’s exactly the point I’m making. The goal was never to see every decision. It’s to make sure the ones that matter are yours to make, and that the rest stay reconstructable after the fact — so the load-bearing call you’d otherwise never have noticed is at least findable when it starts holding weight.

That’s the bar: not visibility into everything, just traceability for the things that come to matter. Which means the move isn’t control — control never scaled to this volume and it never will — and it isn’t capturing every keystroke either. The goal is legibility: the decisions that matter need to be visible as they happen, or at least traceable once they do.

The unglamorous mechanism for that is documentation. But notice that it now has to run in two directions, not one.

The familiar direction is outward and upward: the person records what they decided and why, so a manager, an architect, or another team can see the call without reconstructing it from the code. That was always good practice. It’s load-bearing now in a way it wasn’t before. The meetings used to carry this. Then getting-stuck would force the conversation. But AI-assisted building meant that the discussions don’t happen when AI fills in those gaps. Now writing it down is the only channel left that the new pace didn’t break.

Now to the unfamiliar direction. Good documentation practice is also what lets the model tell the builder what it decided on their behalf. AI is great at creating lots of documentation that most humans never read. The structural calls that got waved through only become inspectable if the work captures them. Done well, the builder can go back and interrogate the decisions that were technically theirs and functionally the model’s. Done poorly, there’s nothing to go back to besides the code and a prayer.

That’s the whole shift in one line: documentation is now a strategic investment, not just bureaucratic hygiene. Documentation used to be how you reported a decision after you made it. Now it’s how a decision becomes visible to anyone at all — including the person who supposedly made it.

None of this requires a new initiative. It doesn’t require redrawing the org, though some companies are doing exactly that — Coinbase’s CEO has made the case for it, which I think reaches for a structural fix to a problem that should be a day-to-day operational fix.

It requires only that you accept what’s already true: more is being decided, by more people and more tools, further from your line of sight than at any point in your career. You need to treat those decisions as something worth being able to see.

That starts with making it safe to surface a stuck point. And “safe” isn’t a policy — it’s something that’s decided every time someone brings you a half-made decision they likely already shipped. Your reaction either tells them surfacing these things is welcome or it teaches them to keep the next one to themselves.

Documenting context and surfacing stuck points are easy habits to discard when raw velocity looks high. They aren’t structurally difficult; they are just easy to skip when everyone’s busy — which is exactly when and why most teams skip them. But those choices are being made either way — by your people, by the models they work with, and it’s happening at a pace the old calendar can no longer catch. The only thing you actually get to decide is whether you want to see them.

The post AI Made You Accountable for Decisions You Never Saw originally appeared on eric.lubow.org.

Someone in your sales org vibe-coded an internal dashboard with all of your sales numbers in it over the weekend. They deployed it on Vercel and made it publicly accessible while forgetting to put a password on it. As a CTO, this sounds like a nightmare that you want to be happening to someone else.

That’s much less of a hypothetical than I want it to be. The only reason it didn’t turn into something worse is that the person who built it, also excitedly shared what they’d built to a larger group. During the showing, the missing password came up when others tried to access it. Thankfully, it was fixed in just a few minutes.

Imagine if that same person didn’t share it publicly. Maybe no one would have clocked that they were able to just access it without a password. In that case, you would probably find out in one of three ways: 1) someone tells them in private, they quietly patch it and the rumor mill carries it to your doorstep, 2) an external auditor finds it during your next ISO (or SOC or whatever) review, or 3) someone outside the company finds it first. All three come with their own challenges. The best version of this requires a culture where people openly share their work.

A few weeks ago, Francesco Panina, CTO at Trustfull, described a story in a LinkedIn thread which reinforces that these things are happening everywhere and right under our noses:

An internal CSV dedupe tool someone wrote over a weekend ended up wired into three automated compliance reports. Nobody labeled it infrastructure, it stayed unversioned for months, and the team didn’t notice until it broke during an audit. Building was trivial, finding out it existed in that role was the expensive conversation.

That last line is the actual shadow IT problem in 2026. Building is cheap. Recognition — knowing a thing exists and what role it’s playing — is expensive. Most of the writing about shadow IT focuses on the building side. And the lens (unfortunately) often paints those builders in a negative light; as rule breakers. Building in the age of AI has gotten so easy that the difficulty for compliance has migrated almost entirely to the discovery side. Discovery means knowing what people are building, what data they’re using, and where they’re deploying it. This is where most leaders are flying blind. Visibility is the precondition for governance. You can’t assess or remediate what you can’t see.

Culture is what determines if that visibility is proactive or reactive. If sharing what you’ve built is the default, recognition happens through enthusiasm. This can be as easy as somebody posting in Slack, somebody else seeing it and simply asking, “are you using that for the compliance reports?” The recognition happens proactively because many people see the work while it’s still evolving. If sharing isn’t the default, recognition happens reactively through audits, outages, or customer complaints.

When the Pipeline Isn’t Enough

For anyone who is accountable for ISO 27001, SOC 2, or any other compliance system, that asymmetry isn’t an abstract idea. When building lived inside engineering, the development pipeline was the visibility layer. Code review, change management, deployment pipelines — governance had a place to apply itself, because the people working on it were specifically trained on compliance, privacy, and security. AI expanded the builder population faster than governance can adapt. The population of people who can ship working software is now roughly the whole company, and on top of that, they make their own pipelines. Without a different visibility layer, the compliance work doesn’t actually have anything to attach to.

People aren’t building in the shadows because they’re sneaky. There are many reasons these things get done behind closed doors: asking takes too long, the official path is full of judgment, peer reactions to unpolished work are unpredictable, and most orgs (often through fear-based compliance) make hiding easier than showing. These reasons aren’t character flaws; they’re how humans behave when the environment makes openness feel costly. Leaders who forget this end up writing policies for the people they want to have, not the people they actually have. The policies don’t work because the environment is the problem, not the humans. Fixing the environment starts with making it safe to be visible.

Visibility Becomes Culture

Psychological safety gets talked about so broadly that it often stops meaning anything operational. Here, it’s concrete: people have to believe that showing unfinished work, asking naive questions, or exposing rough edges won’t be punished. The moment sharing feels risky, visibility collapses and the work goes private. In an AI-enabled organization, that’s a definite culture problem. When you don’t know what people are building and deploying, it becomes a governance problem too.

The mistake most orgs make when they try to “share more” is treating it as a single mechanism. The mechanisms themselves are not the point; it’s the behavior. Each one lowers a different social cost of visibility: sharing interest, admitting confusion, showing rough work, announcing shipped work, and building in public with permission. Compliance benefits because the organization sees more of the work earlier, before it hardens into accidental infrastructure.

(Slack) #inspirations. I saw something cool out there. This lowers the first social hurdle by saying “this looks useful” before anyone has committed to building anything. Here, visibility starts before execution. People are more likely to show what they’re experimenting with later if they’ve already practiced sharing what caught their attention.

(Slack) #ai-help. I’m stuck. This lowers the cost of admitting confusion before people give up or create unsafe workarounds in private. Questions like “why is Claude hallucinating this API endpoint?” or “how should I structure this workflow?” surface early while the work is still malleable. The point is not just education. The real value is visibility into where people are experimenting, struggling, and improvising. This channel dies the moment people get embarrassed or put down for asking basic questions. If confusion becomes private, the resulting systems do too.

(Meeting) Builders Unscripted. I want to show this live (or we want it demoed live). A weekly demo session open to anyone building things, regardless of role or team. No slides, no scripts, no polish requirements. The demos create motivation, sharing of ideas, and ambient awareness across the org. The important part from a product or compliance perspective is that work becomes visible while it’s still rough enough to change. Someone notices a potential security concern. Someone recognizes duplicated effort. Someone else realizes they already solved part of the problem and communicates it. Visibility this early is dramatically cheaper than discovering the same thing during an audit or outage review. This is one of those meetings that I ran initially and have since handed it off. These things tend to work better when they belong to the builders rather than feeling imposed by the top of the org chart.

(Slack) #releases. This is live. Anyone can post shipped work here: internal tools, automations, experiments, fixes, dashboards, workflows. This skews more towards lightweight organizational visibility than formal documentation. Before AI, engineering systems naturally created inventories through pull requests, deployment pipelines, and change management. Now that the builder population includes everyone, that visibility layer has to emerge socially instead. #releases acts as a low-friction inventory of what actually exists inside the company. The mechanism only works if posting stays cheap. The moment sharing requires specific templates, approvals, or process overhead, people stop doing it and the work disappears back into DMs and side projects. At Mapp, we also have a Notion agent that, in just a few seconds, turns a ramble of, “here’s what I shipped in this release” into a clean paste-able post. This makes the structural work automated and humans only have to provide the substance.

(Event) Hackathons. Temporary permission structures for public experimentation. For a fixed period, building becomes the assignment rather than a distraction, and unfinished work stops carrying the same social risk. People who would never demo during the rest of the year suddenly prototype openly because everyone else is doing it too. This matters more than most leaders realize, both for the people building and for the people watching. A surprising amount of “serious infrastructure” starts life as something someone only felt comfortable showing because the environment temporarily suspended judgment. Many of the things that later appear in #releases first surfaced as a hackathon project.

Not every org needs all of these specific channels and meetings. The point is that any one alone would likely fail. Someone who’d never demo at Builders Unscripted will post in releases after the fact. Someone who’d never post in any channel will hear about it at a town hall when something that got shipped gets referenced. The redundancy is the design.

When Visibility Compounds

Visibility doesn’t just help to mitigate shadow IT. Over time, it produces something much more valuable on the path to becoming AI-native. Being an AI-native company has multiple facets. One of the core ones is whether your organization can learn from its own activity at the speed AI enables it. Most companies think “AI-native” means employees using Claude Code/Co-work, Cursor, or Codex. That’s AI-enabled, not AI-native. Moving from AI-enabled to AI-native is a much harder shift, and it’s a cultural one. AI-native means using AI to build the visibility your organization needs to learn from its own work fast enough that the learning compounds.

The mechanisms above create different ways for people to make work visible. There’s a complement to that: a way for people to surface what they tried to build and couldn’t, or what they shipped and immediately wished was different.

(Slack) #product-feedback. Here’s what’s missing or broken. The intake mirror of #releases. When someone is building and runs into a missing API endpoint, a set of data missing enrichment, an integration gap, or a capability they expected to exist and didn’t, now they have a place to put it that doesn’t get immediately lost in Jira bureaucracy. Customer feedback from the commercial teams, like CSMs and account managers goes here too. An agent reads each post, asks follow-up questions if needed, and neatly files everything into a Notion database that we use during roadmap planning, requirements writing, and figuring out who has the right expertise in that specific corner of the product. Overall, it functions primarily as a signal channel rather than a structured feature-request queue, though it captures both.

Once the organization develops enough visibility, the mechanisms start reinforcing each other. Someone sees something interesting in #inspirations, gets unstuck to build it through #ai-help, demos a rough version at Builders Unscripted, or skips that and posts the finished version in #releases, then leaves behind feedback about the missing API endpoints, integrations, or data gaps they hit along the way in #product-feedback. The next person starts with a lot more knowledge and insight at their fingertips instead of thinking through everything from scratch.

Visibility compounds when the organization’s experiments, releases, questions, and failures become searchable instead of disappearing into chat history and DMs. Once people can query what already exists inside the company (prior experiments, integrations, workflows, APIs, failed attempts), each round of building gets cheaper. Teams stop rediscovering the same things over and over because organizational memory becomes accessible at the moment someone is building. At Mapp, that includes searchable Slack history, recorded, transcribed and stored demos and meetings, structured feedback capture, and agents that help organize the information into something searchable and reusable.

When the loop is closed, people aren’t just seeing what got shipped — they’re seeing the lifecycle, from idea to deployment to iteration. This includes things like which internal APIs were involved, which Notion patterns were used, or which vendor integrations were leveraged. That’s how good internal patterns spread through the company instead of every team rebuilding the same workflows independently.

When the Mechanisms Work

The Vercel deployment from the opening is what this looks like when it works. He isn’t a software engineer, and “lock down the deployment” is not a step that lives in the muscle memory of someone whose job is selling. There was no malice or negligence involved. He just built a useful tool to solve his own problem, deployed it quickly, and missed a step that experienced builders would have caught reflexively. He shared what he’d built in a forum where someone would see it. Someone clicked through to the URL, realized they were looking at the full sales dashboard without being asked for a password, and replied with some version of “uh, is this supposed to be open to the world?” Fixed in minutes with limited exposure.

This would play out differently in most organizations. Same person, same tool, same missing password; but he doesn’t share broadly because he’s worried about having his hand slapped for not going through the right channels. Now you find out one of three ways: he tells someone in private and they patch it (best case), an external auditor finds it during your next ISO review (Francesco’s case), or someone outside the company finds it first (worst case) and you really hope they tell you. All three can be expensive in their own way: in audit findings, in customer trust, or in the time it takes to clean up. When sharing is the default, catching things like a missing password becomes part of the normal back-and-forth of work rather than a fire drill.

What This Doesn’t Mean

One natural reaction to all of this is concern that low-friction sharing means low-quality output — that you’re trading off process for visibility. That’s not the trade-off.

The most common objection to a culture-of-sharing argument isn’t “people will dump work over the wall.” It’s “you’re adding more work for people, and they’ll either do it sloppily or have AI do it for them and create slop.”

Posting in #releases doesn’t trigger documentation, and it doesn’t raise the bar for productized delivery. The act of sharing is intentionally cheap: no template enforcement, no mandatory cross-posting, no approval workflow, no required PRD. Friction at the point of sharing is what creates the shadows in the first place; the whole mechanism collapses if that friction comes back. Resist the temptation to add structure. Let an agent support adding that structure post-hoc.

Your Head of Compliance might hear “celebration” and envision a breakdown of discipline. The reality is the opposite. Formal compliance, the SOC 2 reports, the ISO evidence folders, the access reviews, the actual proof, is a downstream consumer of visibility. It can only govern what it can ingest. By the time a “weekend project” becomes accidental infrastructure, it’s usually too late to retroactively apply controls without a massive tax. When the social layer captures the birth of a tool in #releases or a demo, you get visibility at the start of the lifecycle instead of at the point of failure. At Mapp, we use agents to bridge this gap: the agent watches the “celebration” channels, identifies anything that crosses a risk threshold (like handling PII or hitting a production database), and flags it to compliance for review.

That is the point where the social convention becomes formal process. Documentation, compliance review, and privacy review are real and they kick in when the situation calls for it: when something is used by multiple teams, when it touches customer data or PII, or when other systems start depending on it. That’s the same threshold logic from the polish levels framework; the lens applies based on what the thing has become, not based on who built it. Visibility is the cheap part. Governance scales with the stakes of what got built. The compliance side of this gets its own future post.

Same Mechanism, Different Population

The #releases channel isn’t new. I ran a version of it years ago at a 2,000+ person company. It worked there for the same reasons it works now: visibility across teams, lightweight discovery, recognition of useful work, and occasionally catching duplication before it hardened into infrastructure.

What’s changed isn’t the mechanism. It’s the population it serves.

At 2,000+ people, the “tech team” was a (large, but) bounded group, and #releases tracked what they were shipping. Other functions watched, but they were rarely building software themselves. In a smaller AI-enabled company, the builder population expands far beyond engineering: sales, finance, operations, and customer-facing teams are all capable of shipping internal tools and automations now; and they all do. The same mechanism suddenly matters to the whole company because building is no longer isolated to engineering. The channel itself was never the important part. The important part was making visibility cheap enough that people actually participate. Smaller orgs get more out of the same mechanism. At 2,000 people, a #releases post might reach a few hundred relevant readers. At 200, it reaches everyone who could possibly care. The same effort, several times the return.

The Overlap is Intentional

I know that this sounds like a lot of Slack channels and meetings layered on top of an already noisy workday. Most leaders who consolidate visibility into fewer mechanisms are doing it in good faith. The intention is usually to reduce distractions, context-switching, and information overload. The intention is right; the trade-off is what’s wrong.

The problem is that cultural visibility doesn’t spread reliably through a single channel or meeting. Different people participate through different mechanisms. Someone who never demos live will still post after the fact in #releases. Someone who ignores every Slack channel might still hear about a project when it gets referenced in a town hall or leadership update. The overlap is intentional.

Most of these mechanisms are also opt-in attention rather than mandatory process. Mute the channels. Skip the meeting. Watch the recording later (at 1.5x/2x) or ignore it entirely. The important thing is not that everyone participates everywhere. The important thing is that the work becomes visible somewhere before it turns into accidental infrastructure.

The visibility layer only works if people encounter it through multiple paths. The cost of a few extra channels is much lower than the cost of any one of them being the single point of failure for organizational visibility.

The New Visibility Layer

AI expanded the population of people capable of shipping working software far beyond engineering, but the visibility systems around that work didn’t expand with it. That’s why so many organizations now feel simultaneously more productive and less governable.

Most companies are still trying to solve this bureaucratically with tighter process and more approvals. I think that’s backwards. The organizations adapting best are not the ones trying hardest to stop people from building. They’re the ones enabling building while making it visible early enough that governance can keep up.

That visibility layer is cultural before it’s technical. The moment visibility feels risky, the work goes private and governance becomes reactive again.

Celebration sounds culturally soft until you realize it’s functioning as governance infrastructure. In AI-enabled organizations, the same culture that accelerates experimentation is also the thing that makes the organization governable again.

The post If You Want Compliance, Start with Celebration originally appeared on eric.lubow.org.

That pipeline is dissolving. Engineers ship faster with AI assistance. PMs prototype tools themselves. Domain experts build internal workflows over a weekend. Building is everywhere, and when AI removes the routine work, it leaves the judgment calls. Think of it like GPS and taxi drivers: knowing every street and traffic pattern used to be the expertise; GPS commoditized that, leaving just the driving. AI is doing the opposite for coordination functions — it’s commoditizing the routine work and leaving the expertise. That’s good for the people who have the expertise. It’s a problem when someone builds something useful and doesn’t realize the expertise was supposed to be part of the process.

This piece is about what that means for product management specifically. Compliance, design, and DevOps each face their own version of this shift, and I’ll get to those separately. But Product Management is the coordination function that sat at the center of the old pipeline, so it’s the one where the dispersal is most visible — and where the question “what is this role for now?” lands most directly.

What Breaks When Nobody Applies the Product Lens

When someone, wherever they are in the org, builds something useful, they solve their own problem — often creatively and well. What they skip is everything around the problem. There’s no rollout plan — they just deployed it. There’s no thinking about downstream effects, who else this affects, or what happens to the users who now depend on it when the builder moves on. There’s no consideration of whether this duplicates a capability the product already has, or conflicts with one that’s in flight. There’s no lifecycle plan — no iteration path beyond their own use case, no real owner for the support burden it creates. They might be willing to support it, but it isn’t their primary job.

None of this means the thing they built is bad. It means the broader product judgment was never applied. I wrote about the engineering version of this pattern in Infrastructure by Adoption, An AI-Engineering First Principle — tools become infrastructure through adoption rather than decision. The same thing happens from the product side. Something becomes customer-facing, or workflow-critical, starts accumulating dependents, and the product lens was never applied because the builder was focused on their own problem. The risk isn’t that people build the wrong things. It’s that the right things become depended on before anyone has decided they should be.

The Threshold Principle

Before getting into what this means for PM, here is the principle that ties everything I’m saying together: the level of rigor should match the weight of what’s been built. That sounds simple. But in practice, it requires agreement on what counts as weight.

A tool one person uses to solve their own problem doesn’t need a PRD, a compliance review, or a design audit. A tool that three teams depend on probably does. A system that customers interact with definitely does, along with a rollout plan and compliance documentation. No matter what, you need a way to decide when a fuller set of questions should be asked and answered. Polish levels are one way to provide the shared vocabulary for this conversation — not a gate, but a common language for “how much rigor does this need right now?”

This reframes what coordination functions are for. PMs, compliance, engineers, QA, and designers aren’t gatekeepers of the build pipeline. They’re the people with the experience to recognize when something has crossed a threshold — and to help calibrate the response. The hard part isn’t applying the judgment. It’s agreeing on what counts as a threshold in the first place.

Sometimes that threshold is about complexity. Sometimes it’s user experience, or compliance, or PII. It’s hard to define cleanly in the abstract, but usually obvious when you’re looking at a real tool. The goal isn’t to review everything — that’s neither practical nor useful. It’s to make the criteria clear enough that builders can self-assess, and to be available (without taking ownership) when that self-assessment says “I think I need help with this.”

Having builders distributed across the org also distributes accountability. A builder owns solving a specific customer problem, and they might solve it in a way that doesn’t match how a PM or designer would have built it into the product.

That isn’t a failure. Cohesion and customer experience aren’t the same thing. A builder can improve CX at some cost to cohesion. But someone still has to notice when that tradeoff starts to matter. The PM (or whoever holds the lens) owns recognizing when a local win needs to be re-examined through a broader one.

There’s a real tension here that’s worth calling out. If coordination functions become “available to help” with everything builders ship, they can run into a capacity and context switching problem; they stop having time for the work they’re actually accountable for. The PM who’s answering questions from six people building side tools isn’t taking the time to keep stakeholders informed or building prototypes to inform their thinking. The compliance lead who’s fielding every “is this okay?” question isn’t answering the compliance questions that sales is waiting for. The line between being supportive and becoming support staff is real. The threshold is what protects against this. If the criteria are clear, most builders self-assess correctly and rarely need to escalate. The ones who do escalate are the ones who should be escalating. That only works if the criteria are published, taught, and trusted — which is the thing the framework actually requires.

What This Means for Product Management

Product management is one of those jobs that looks easy from the outside. Everyone who understands a problem and builds a solution thinks they’ve done the hard part — and for their own use case, they probably have. What they’re not thinking about is the 80% of product work that lives beyond their immediate problem: how does this fit into existing workflows, what does success look like beyond adoption, how do we communicate changes to people who depend on it, how do we ensure adoption, when does it need iteration, etc. They did the part that feels like product management from outside of product management. The rest is often what they don’t know they’re skipping.

This doesn’t mean PMs need to personally review every tool that gets built across the organization. PMs are already pulled in too many directions by too many people — adding “review everything the entire org builds” to their plate would just create a new bottleneck. The shift is different: PMs help define the threshold criteria. They set up the questions builders should ask to determine whether their creation needs product involvement. Where the engineering recognition checklist asks “would anything break if this went down?”, the product equivalent asks “would any user or workflow be surprised if this changed?” If the answer is yes, that’s when a PM gets involved — not to take over, but to help apply the lens the builder doesn’t have.

The other thing that’s changed is how PMs actually work. When engineering was the scarce resource, the PM’s artifact was the document — the PRD, the spec, the one-pager — because the document was how you secured engineering time and communicated what to build. Now engineering isn’t scarce, and the document isn’t the best way to develop an idea anyway. With AI building tools, a PM can produce a working prototype in the format of the existing architecture in a matter of hours. Multiple prototypes a week is now not just expected, it’s the norm.

This isn’t just a change in tooling. It’s a change in how people think and communicate. Some people think with writing and some people think with building — and AI lets PMs do both. You can think with writing, prototype the idea to see if it holds up, get feedback from SMEs faster, form opinions faster, and make mistakes faster. The PRD or spec, if you still need one, comes later to lock in the thinking after iteration (and if compliance requires it). That’s a better artifact than the one you would have written before the prototype existed, because it captures what you actually learned.

Working this way is faster — and that speed has consequences for everything built around the old pace. The tempo changed. Some of the old rituals still work at the new speed; some don’t. 2-3 week long sprints made sense when a team shipped a handful of things at a time. They’re the wrong ceremony when one PM is producing multiple prototypes and engineering is shipping continuously.

Milestones need the same rethinking. “Feature X is done” misses that “done” now means “done at polish level 2 for this outcome, and we’ll move to polish level 3 if adoption justifies it.” Milestones should represent outcomes and carry a polish level, not a binary complete/not-complete status. Engineers can ship faster; PMs need to work faster in their own way; and the rituals have to accommodate both.

All of that is new. But there’s an older part of the PM job that becomes more important, not less. PMs have long been coordinators. They did it by knowing a little bit about a lot of functions — enough engineering to know when a plan is unrealistic, enough design to know when the UX is going to trip someone up, enough about the data flows to know when to loop in compliance. That role was mostly implicit. Different PMs did more or less of it depending on their background and their org’s maturity.

When building was centralized, that implicit coordination was enough, because most of what got built went through the same pipeline anyway. Now it isn’t. The lines between engineering, product, design, DevOps, and general builders have blurred — engineers do more PM and DevOps work, PMs prototype including new designs, designers build functional things that solve engineering problems, and domain experts ship tools that all three used to be involved in. In that environment, the PM’s coordinator role has to become explicit. Lead through influence. Help the groups that didn’t previously have good access to cross-functional coordination get some of it. Route things: this needs a compliance conversation, that needs an architecture review, this other thing overlaps with what the growth team is building. PMs used to apply judgment before anything was built. Now they apply it after something proves it matters.

This is actually the part of PM work AI is worst at. Models can write a PRD, generate a prototype, draft a changelog, summarize a user interview. What they can’t do is get three people in a room to agree — manage opinions, navigate organizational politics, broker tradeoffs between competing functions, or align stakeholders who see the same problem differently. Cross-functional coordination is the work that doesn’t automate. It’s also the work that’s becoming more important, because distributed building creates more coordination surfaces, not fewer.

Done well, the coordinator role pays off in both directions. When a PM reviews something a builder created, they might recognize that it solves a problem the product team was already planning to address, or that it could improve an existing feature elsewhere in the product. And it’s prototyping in real conditions — there’s no better stress test than a tool that’s already being used by the builder under actual pressure. The builder gets product context they didn’t have. The PM gets signal about unmet needs — or more clarity on needs they were already tracking.

There’s also a canary-in-the-coal-mine element. A builder may have quietly solved a problem that’s bigger than their team, or touched on a contract, a partner relationship, or a strategic decision they don’t have visibility into. Catching that early — while it’s still a weekend tool rather than something three teams depend on — is the difference between a quick conversation and a much harder, potentially demotivating one later. The check-in is how that signal reaches the people who need to act on it. That exchange doesn’t happen by accident — it happens when the check-in is easy to facilitate and the environment feels collaborative.

What to Do About It

Your mileage will vary on which of these matters most. But a few principles are worth acting on regardless of your specific situation.

Make the criteria visible, then teach people to use them. Builders need to know what thresholds exist and what triggers involvement from Product Management (or compliance, engineering, DevOps, or design). Publish the recognition checklists. Make them short and digestible, even if they don’t cover everything at once — you need people to come to you, and they won’t if they expect to be overwhelmed. Publishing isn’t enough on its own, though. Run a short training session, walk through real examples, show people what a self-assessment actually looks like in practice and what you might do to help when they want it. Checklists that people don’t know how to use are the same as no checklists at all.

Make expertise a service, not a gate. PMs, compliance leads, engineers, and designers should be resources that builders can reach — a Slack channel, office hours, a standing check-in. The question shifts from “did you get sign-off?” to “did you get the right eyes on this?” If getting help is easier than hiding, people will get help. It also lets builders maintain ownership of what they’ve created, which matters for both motivation and ongoing maintenance.

Use polish levels to calibrate rigor, including at the milestone level. A prototype doesn’t need a PRD. A tool that customers or multiple teams now depend on does, along with a rollout plan and compliance documentation. Match the process to the maturity of the thing, not to a one-size-fits-all standard. This applies to how you define milestones too — “done at polish level 2 for this outcome” is a more clearly communicated milestone than “done.”

Lighten up the ceremonies and processes. If prototyping is multiple times a week and shipping is continuous, the old cadence of weekly sprint reviews and monthly roadmap cycles is out of sync with how the work actually happens. Keep the ceremonies that still serve a purpose; cut or compress the ones that are running on inertia.

Create visibility into what exists. If something is being used by a team, processing real data, or sitting in a workflow, it needs to be accounted for somewhere — a service catalog, a building block registry, a shared inventory. The specific mechanism matters less than the principle. You can’t apply the right lens to something you don’t know exists.

Build a culture of surfacing, not permission. This whole framework depends on people being willing to say “I built this” and the organization responding with support rather than suspicion. If surfacing what you built is met with “why didn’t you ask permission?”, you’re never going to get visibility. The response that works sounds more like: “Great. Let’s make sure it’s covered, let’s work on it together where it needs work, and you still own it.” Covered, collaborative, constructive — and the builder keeps ownership. That’s what reinforces the enthusiasm and motivation you want more of, instead of training people to stop bringing things forward.

The Role Didn’t Disappear. It Moved.

I don’t think I have a final answer to the question in the title, and I’m not sure anyone does yet. But the ideas here are where I’ve landed so far. It’s worth noticing that the frontier AI companies are hiring PMs aggressively — they aren’t shedding the role, they’re expanding it. That’s a useful signal. Product management isn’t primarily about writing requirements documents that engineers implement, or being the single throat to choke on whether something should get built. It’s about the judgment: the lifecycle thinking, the workflow understanding, the coordination across functions, the recognition of what’s worth doing and what isn’t; applied at the moments those things actually matter.

That’s a harder job in some ways. It requires defining the criteria clearly, being accessible without being overrun, and trusting that most builders will self-assess honestly. It also requires letting go of the control and comfort of owning the pipeline, because the pipeline isn’t a thing you can own anymore. But it’s also a more interesting job, because the PM’s value stops being about gatekeeping access to engineering time and starts being about applying judgment where it genuinely matters.

And here’s the thing AI is worst at and won’t catch up to soon: getting humans to agree. Writing code, generating designs, drafting documents, summarizing research — all of that is getting commoditized. Aligning six people with six different priorities and six different read-outs of the same situation is still a human job. It may be the most human job left in building software. PMs have been doing it the whole time, often without being recognized for it. The organizations that handle the AI-enabled shift well won’t be the ones with the most process. They’ll be the ones where builders know when to ask for help, where asking is easier than hiding, and where PMs are present at the moments their expertise matters most.

The post What Is Product Management For When Everyone Builds originally appeared on eric.lubow.org.

Useful tools are getting built everywhere now — a solutions architect writes an integration wrapper to unblock onboarding, a PM stands up a dashboard pulling from three APIs, an engineer builds a CLI to automate a migration. These things work. They get used. They get adopted. They become part of the workflow — other things depend on them. And that’s how infrastructure gets born without anyone recognizing it: not by decision, but by adoption, regardless of who built it or how quickly it was stood up.

The definition of application infrastructure changed. The rules for building it didn’t.

The Transition That Nobody Sees

Two forces make this more common than it used to be:

1. AI collapsed build cost. People across the organization can stand up functional tools in hours, and the outputs are more capable and widely adopted than the quick fixes of five years ago.
2. Composable systems are becoming the default: APIs as products, shared data layers, MCP servers, agent toolchains. This all means more of what gets built is designed to be built upon, or accidentally becomes something other things depend on.

The precarious moment is the transition: when a useful tool or workflow duct tape quietly becomes a system that other systems, teams, or agents depend on. In the old world, engineers built infrastructure, engineers recognized infrastructure, and engineers operationalized infrastructure. The people identifying the need and the people building the response were the same. Nobody needed a process for “who figures out if this is infrastructure” because the people building it already knew.

That’s no longer true. When everyone builds, the person who created the thing often doesn’t have the context to recognize that it became foundational. They are probably just solving their own problem. So if recognizing the transition isn’t anyone’s explicit job, it only surfaces when something breaks.

This is how it actually shows up. Someone builds an onboarding tool to unblock a workflow. It works, so more teams start using it. Now every new customer gets onboarded through it, internal teams rely on it to track progress, and it keeps evolving. At no point did anyone decide this was production infrastructure — but it is. And it never went through the processes that would normally apply to something carrying that weight.

The danger isn’t that people are building without permission; it’s that they are building dependencies without awareness. This creates an immediate tension. In an environment that has always prized velocity, any reversion to a manual check feels like a regression. The goal is not to return to centralized control. It’s a trigger-based check that only kicks in when something starts carrying dependency weight. But we have to be clear about the trade-off: the friction of a brief engineering review is a small tax to pay compared to the cost of discovering you’ve been running production infrastructure with prototype-level support.

The New First Principle

When other things depend on what you’ve built, it needs engineering judgment applied, regardless of who built it.

I think about engineering judgment as the accumulated context of knowing where things break and why. It’s the scar tissue from systems that failed at 2 AM, from fixing data migrations that corrupted silently, or from troubleshooting integrations that worked in dev/staging and broke under production load. It’s what tells an engineer whether to build an MCP server, an API, or a CLI tool, and what to expose through each one. It’s knowing what to monitor, how failure cascades, and where the trade-offs actually are. That context is the product of experience, and applying it is what distinguishes a tool that works from a tool that keeps working.

This underlying principle isn’t “engineers should build everything.” Non-engineers don’t build badly — they build without a specific type of context because they’ve never needed it. But the principle is also not “overengineer everything.” If someone builds a data sync service that processes forty records a day and an engineer tries to redesign it with queuing, retry logic, and idempotent writes, they’ve failed the assignment. What that tool likely needed was simple error logging and a notification for when it fails. Overbuilding is the same category of mistake as underbuilding; both reflect misclassified trade-offs.

The principle is about applying that accumulated context — the scar tissue and the “why” of failure — at the moment a tool crosses from “just a tool” to building block: something other systems or workflows depend on. Engineering judgment isn’t about building things “the right way”; it’s about ensuring the rigor of the solution matches the weight of the dependency.

Who’s Responsible for Recognizing It

Everyone who builds is responsible for recognizing it, whether they know it or not. That’s the uncomfortable answer, and it’s also the only one that works when building is no longer confined to engineering. As a leader, your job is to make sure people know that this is now expected of them, give them the vocabulary to recognize it, and make clear what happens next when they do.

This doesn’t mean every builder needs to think like an engineer. It means every builder needs to be able to answer a short set of questions about what they’ve built. These questions will help them determine whether other things now depend on it and if it needs engineering involvement. This is not an engineering checklist, it’s a recognition checklist. And these are all ways of asking pretty much the same question: has this become something other people or systems now depend on?

• Are other people, teams, or systems now depending on this beyond what I originally built it for?
• If this tool went down tomorrow, would it affect anyone other than me?
• Is it handling data it wasn’t originally designed to handle, or data that has compliance implications?
• Has it grown beyond my ability to support, maintain, or explain how it works?
• Are agents, automations, or workflows depending on it?
• Did I build this as a one-off, but it’s now part of how the organization operates?

If the answer to any of these is yes (or even “I think so”), this thing has probably become a building block. In more plain terms, other things now depend on it, and it needs more scrutiny than it’s currently getting. That recognition is the trigger. What happens next depends on the situation.

What To Do About It

The response should scale with the stakes.

At the lightest level, it’s a conversation. An engineer sits down with the builder, the builder walks them through what they’ve built, what workflows it’s a part of, and what decisions were made during building. The engineer’s job in that conversation is to listen to what the builder describes and ask the questions the builder didn’t think to ask — reading between the lines on how a non-engineer explains what they built, and translating that into where the technical risks actually are.

The kinds of questions that matter are practical: How does it handle failure? What happens when the data it depends on is null or malformed? Is there any testing? Are there database indexes on the queries that matter? What monitoring exists and who should be alerted if this stops working off-hours? Many of these are questions the builder can turn around and ask the agent they used to build with. The answers won’t always be complete, but asking them surfaces gaps that would otherwise stay hidden until a production incident reveals them.

This is intended more as coaching and education than a hand-off grilling session. The builder learns what to think about next time. The engineer learns what the tool does and where the risks are. The next thing that person builds will be stronger for it.

When the stakes are higher — when something needs to move up in polish level, or when it’s going to carry real operational weight — the response can be a pairing session or a proper hand-off. That might mean writing a PRD or an RFC that defines the expected capability set, the resiliency requirements, the documentation and monitoring standards. Engineers are used to receiving hand-offs; they’re just used to receiving them from other engineers. The process is the same. The source is different. This will add some time to the hand-off itself, but the mechanics are familiar.

The goal in both cases is the same: make sure that when something becomes foundational, someone with engineering judgment has looked at it and either blessed it, improved it, or flagged that it needs more work, either before too many other things depend on it or before the first client dependency creates an implicit SLA nobody agreed to.

The Principle in Practice

Without this first principle, your organization will discover that something is core to your operations only when it breaks. A prototyped tool quietly starts carrying production-level expectations even though nobody agreed to that transition. The recognition questions never got asked because it wasn’t anyone’s job to ask them. In the traditional workflow, PMs ask “is this ready for customers?” and QA tests it in ways the original developers hadn’t considered. Those functions act as backstops. But when something is built outside the product development workflow — when it was never on a sprint, never went through a product review, and never hit a QA cycle — those backstops aren’t in the loop. The first principle creates a trigger that works independently of that workflow; because the things that most need the backstops, are being created outside of that exact workflow.

This doesn’t happen on its own. Someone in leadership has to set the expectation that builders assess what they’ve built, provide the vocabulary and training to do it, and create a clear path for what happens when a tool starts carrying dependency weight. The recognition checklist is only useful if people know it exists and know what to do when one of those questions becomes a “yes.”

The first principle creates a simple responsibility: recognize when something has dependents, and act on it. That’s the trigger: reassess its classification, reassess its polish level, and get engineering judgment applied. This isn’t a tax on speed; it’s how you keep speed from outpacing your foundations. You can build as fast as you want. But if you don’t recognize what other things have started depending on, you won’t know what your infrastructure actually is until it breaks.

The post Infrastructure by Adoption: An AI-Engineering First Principle originally appeared on eric.lubow.org.

The roadmap is still the coordination surface. It just isn’t structured for what the organization is actually doing. It needs three concepts it’s never carried: the difference between an outcome and a building block, and a way to express how much investment each one warrants — what I’m calling a polish level.

Outcomes and Building Blocks Are Different Things

The coordination problem shows up as a classification problem. If everything is a “feature,” you can’t tell what’s reusable, what’s foundational, or what other teams should be building on. The roadmap appears with items like: “new onboarding flow,” or “recommendation improvements.” The capabilities those rely on, things like customer data access, scoring services, integration layers, are either implicit or missing entirely. That works when a small group of teams is building in a shared context. It breaks down when more people are building, faster, without that shared understanding.

Outcomes are what the business promises. A Shopify integration that lets customers bidirectionally sync their data. A self-service onboarding flow. A recommendation engine that improves conversion. Outcomes answer “what value did we create?” And fortunately, they’re what most roadmaps already track well; whether they’re called features, deliverables, or epics. Product managers typically own outcomes because they own the value conversation — what are we building, for whom, and why it matters. Though engineering-facing outcomes exist too: making auth capabilities accessible to other business units is an outcome even if no customer ever sees it directly.

Building blocks are composable capabilities. These are typically data layers, services, interfaces, tooling, piping; things that extend what your systems and products can do. Other things get built on top of them.

Not all building blocks carry the same weight. Some are foundational capabilities that make building possible; like authn/authz, SDKs, or service catalogs. Nobody outside engineering thinks about them unless they’re missing or broken. Because they rarely appear on the roadmap, the engineering effort required to maintain them remains invisible during prioritization. Others are product-level: APIs, data layers, integration surfaces — capabilities that serve both internal teams building features and external customers integrating with your platform.

Once these are visible on the roadmap, something else becomes visible too: where dependencies cluster. Dependencies have always existed in roadmaps. What’s changed is that AI-enabled development makes it practical to build the shared capabilities those dependencies point to — which means identifying where they cluster becomes a prioritization question, not just a sequencing one. When the same building block shows up as a dependency across multiple outcomes, that’s telling you where investment has outsized leverage. A scoring service that three different product initiatives need isn’t just a shared dependency — it’s a bottleneck if it doesn’t exist and a multiplier if it does.

But building blocks don’t only get created intentionally. Outcomes can become building blocks whether or not anyone decides they should. You ship an integration as an outcome and then three internal tools start depending on the data pipeline it created. That pipeline is now a building block. If your roadmap doesn’t have vocabulary for that transition, you discover it only when the pipeline breaks and three teams come to you complaining. Recognizing that transition before things break is where engineering judgment provides the most value — and it’s a topic that deserves its own focus.

Unrecognized transitions aren’t the only risk. When more people can build, the odds of duplicated effort increase. Someone on the onboarding team builds a customer data lookup tool without knowing that a nearly identical capability already exists in the platform team’s service layer. If building blocks are on the roadmap, properly tagged and categorized, they become a place you can actually check before building (this is a coordination problem, not a talent problem). If they’re not, you get accidental rebuilding that nobody maintains. And unlike people, agents and automations can’t improvise their way to the right capability. They fail silently or build a duplicate.

Polish Is a Spectrum, Not a Binary

Distinguishing outcomes from building blocks tells you what you’re working on. It doesn’t tell you how much to invest in each one. That question used to live inside the definition of done. It needs its own concept, and I’m calling it polish level.

Most roadmap items are implicitly treated as either “done” or “not done.” That binary hides a real question: done to what standard? A vibe-coded internal tool that saves the operations team four hours a week is “done” in a meaningful sense. A fully self-service feature with documentation, error handling, and SLA commitments is also “done.” These are not the same investment, and the roadmap should make that distinction visible.

The framework for polish level is a five-point scale:

1. Manual Service – Fully manual, handled by internal teams as a human-driven process. No tooling, no UI — just people and process. (Internal only)
2. Internal Tool – A lightweight or vibe-coded tool that streamlines work for internal teams. Not client-facing, but significantly reduces manual effort. (Internal only)
3. Prototype – Accessible to selected clients for testing and validation. Used to gather real-world feedback before committing to productization. (Selected clients)
4. Productized Feature – Fully integrated, available to all clients but may require some guided setup or onboarding. (All clients, assisted)
5. Full Self-Service – Clients can discover, configure, and use the capability independently without any internal support. (All clients, autonomous)

It’s tempting to view this scale as a progression; as if every item should eventually strive for Level 5. That is a mistake. Polish is not a proxy for quality; it’s a choice about the intended relationship between the builder and the user(s). A Level 2 internal tool is not a “worse” version of a Level 5 product; it is a tool built for a specific, high-context audience that doesn’t require (and shouldn’t pay for) the overhead of self-service documentation and autonomous error handling.

The conversation this scale enables is one of “fit for purpose”. When a PM and an engineering lead (or an external-to-Tech builder checking in with a PM) agree on a polish level, they are agreeing on the long-term support model. Moving up the scale reduces friction for the user, but it increases the maintenance burden and potentially the compliance rigor required from the team. The goal isn’t to reach the top of the scale; it’s to ensure that the level of investment matches the intended use case. This becomes especially critical when a Level 2 tool unexpectedly starts acting like a Level 5 building block. If you haven’t agreed on what that transition looks like, you’ll find yourself supporting a critical piece of infrastructure with the resources of a side project.

Polish Levels in Practice

The scale provides structure for those who need it. But the amount of polish remains a spectrum, not a strict taxonomy. The delivery reality often straddles levels in interesting ways. Something might be a strong Level 2 with elements of Level 4 (an internal tool with lots of documentation), or solidly Level 3 on its way to Level 5 (a prototype built on your main codebase exposed via feature flag that lacks configuration and documentation). The value isn’t in the precision of the number; it’s in making the conversation possible. When a roadmap item has an explicit polish target, you can ask useful questions like:

• Is a prototype sufficient here, or do we need to productize?
• This prototype involves customer data — does it need more compliance rigor even at this polish level?
• Five customers are already using what started as an internal tool. Should we invest in moving it up the scale?

The polish level also matters for governance. As someone responsible for Product Management, Engineering, DevOps, and IT/Compliance, I need to know whether something touching customer data is a Level 3 prototype being tested with two accounts or a Level 4 productized feature serving hundreds. The compliance treatment is different, and without a shared way to express that on the roadmap, every conversation starts from scratch.

The same applies to DevOps. If they don’t know that non-engineers are deploying code into production or production-adjacent environments, they can’t create appropriate guardrails or limit the damage radius when something goes wrong (or add additional monitoring and observability for safety). The polish level tells them what kind of deployment infrastructure and safeguards each item needs.

Polish levels also make the shadow IT problem more manageable. When someone outside engineering builds something useful — and in an AI-first organization, they will — the polish framework gives you a way to acknowledge the work, classify it honestly, and decide what investment it warrants. “You built a Level 2 internal tool that’s solving a real problem. All the solutions architects are using it. Do we clean up the API and add documentation so it can graduate to a Level 3?” That’s a much more productive conversation than “who authorized this?” or “why did you build this?”

This terminology and extra tracking might sound like overhead. It’s not. Or at least, it’s less overhead than the alternative. Every planning conversation already includes an implicit negotiation about what “done” means and how much investment something warrants. The polish level just makes that negotiation explicit so you have it once instead of every sprint. It ensures that as the organization builds faster and more creatively, you aren’t just creating a pile of features, but a structured library of capabilities that both your people and your agents can actually use.

The Roadmap Becomes the Coordination Surface

The roadmap you already have still works for what it was designed to do. This isn’t a replacement for the When of a roadmap; it’s the necessary What and To what standard that makes the timeline honest. When everyone in the organization can build, and most will, the roadmap becomes the place where you answer: what are we building, what are we building with, how polished does each thing need to be, and when something breaks, who’s responsible for it?

Without this vocabulary, organizations keep running into the same problems. Building blocks stay invisible until they fail. Prototypes get treated like production features (or production features get treated like prototypes). People rebuild capabilities that already exist because they couldn’t find them — and the agents they’re building with can’t find them either. And smart people in planning meetings talk past each other because one person’s “feature” is an outcome and another person’s “feature” is a building block.

Implementing this doesn’t require a new tech stack. It’s a metadata problem. Whether it manifests as a custom field in a tracker, a dedicated view in a roadmap tool, or a column in a spreadsheet is secondary. What matters is that the coordination surface, the place where people actually look to see what is happening, carries the vocabulary. If the data isn’t there, the conversation won’t happen.

Roadmaps were designed to track features that product and engineering would deliver. They were never designed to coordinate what everyone is already building. You don’t fix that gap with better prioritization. You fix it by making what exists visible, classifying it honestly, and being explicit about how much you’re willing to invest in it.

The post Your Roadmap Needs a Type System originally appeared on eric.lubow.org.

But if you’re a CTO or any senior leader trying to figure out how to actually execute an AI transformation, a hackathon is the cheapest, fastest way to simulate what your organization looks like operating at the speed of AI. In other words, your future operating model, pressure-tested without the consequences.

The outputs aren’t the projects people build (though they can be valuable). The output is what breaks, what surfaces, and how your organization actually behaves when you remove the usual constraints. You learn things about your people, your infrastructure, and your operating model that you won’t get from training, surveys, or vendor decks — things that most teams only discover during an incident.

I’ve written before about why hackathons work as an adoption strategy. They offer a vehicle to create the kinds of motivation that training can’t. I also explain why letting people solve their own problems beats mandating curriculum. This piece is the view from the other side of the mountain. It’s about what the hackathon gives you as a leader, and why every one of those outputs is worth the two days.

Know Where Your People Actually Are

Part of the AI transformation process is knowing where your people sit on the adoption spectrum. Not where they say they are in a survey. Where they actually are when you put tools in front of them and say, “build something.”

In practice, you see the spread immediately. A small group takes off and starts pushing the tools in ways you didn’t anticipate. A larger group realizes the barrier to entry is much lower than they thought and starts experimenting. And a third group keeps working the way they always have.

The categories themselves aren’t the interesting part. What matters is that you now have an accurate map of who needs what, who should be pulled into champion roles, where your biggest adoption leverage actually is, where you’re going to need patience instead of pressure, and who will move slower by design. This last group are the people who tend to anchor you to stability. It’s been their instinct and pacing that has historically kept systems from breaking. You still need to bring them along, just more deliberately. Writing them off is how you trade short-term speed for long-term fragility.

You won’t learn any of this from training completion metrics. A hackathon gives you an honest map of your organization in two days. That map determines where you invest your time, your budget, and your coaching energy.

But only if you treat it like a diagnostic, not an event. Right after the hackathon, sit down with your leadership team and walk through what you saw. Who took off. Who needs support. Who didn’t engage. Where AI was used as a sidecar versus a primary tool.

This is where the value compounds. It’s where the signal turns into decisions about where to invest and how to move.

Bring the Shadow AI Into the Light

If you are early in your organizational transformation, then there are already people in your organization using AI. Only they are doing it on personal accounts, outside your security perimeter, with no governance and no visibility. You can’t survey for this honestly. Nobody’s going to volunteer that they’ve been pasting customer data into ChatGPT on their personal login to bypass enterprise friction. And monitoring for things like this destroys the trust you need for adoption to work.

A hackathon solves this. When you create a sanctioned, celebrated space for AI experimentation, people show you what they’ve been doing, even if they pretend to rebuild it just for the hackathon. They aren’t doing it because you asked, but because the context makes it safe. The person who’s been quietly automating their reporting workflow will demo it. The PM who’s been using AI to draft specs will share their process.

That visibility is valuable. Some of what surfaces needs guardrails, like if someone builds a neat new UI for searching log data that contains PII. Some of it should be formalized and shared across teams, like the PMs new tool for drafting PRDs can be abstracted to Engineers for creating RFCs. Some of it is exactly the kind of grassroots problem-solving you want more of. But you can’t make any of those calls if you don’t know it’s happening.

Stress-Test Your Infrastructure at Low Stakes

When two hundred people need AI tool access at the same time, you find out very quickly what your organization isn’t ready for. Most systems fail on concurrency, not capability. Things that seemed fine at 20 or 50 users start breaking in ways you didn’t anticipate at 200 or 300.

Policies are usually the first gap. Data classification rules that made sense six months ago don’t cover the gray areas that show up when someone wants to feed customer feedback or internal data into Claude to find patterns.

Then the infrastructure shows up. SSO configurations that don’t include the tools people actually want to use. API gateway limits, logging gaps, missing audit trails, token tracking that works at low volume but breaks at scale. Some of this you’ve already built. Some of it behaves very differently once usage spikes.

Then the support model gets tested. Someone hits a firewall rule that blocks an API call. Someone else needs a permission escalated. Someone discovers the VPN drops their connection to a tool that works fine off-network. Individually, these are small issues. At scale, they stack. The hackathon tells you whether your IT team can actually respond at the speed broad adoption requires.

And then there’s cost. Are people burning through tokens when a subscription would be cheaper? Or sitting on subscriptions when API usage would be a fraction of the cost? Most people default to whatever they signed up for first. Multiply that across a few hundred people and the difference between intentional and accidental cost management becomes material.

If you’ve built internal templates or starter infrastructure — standardized app skeletons with SSO, monitoring, data access baked in — this is where you find out if they actually work. Can non-engineers use them? Do they hold up when thirty people spin up projects at once? Are the guardrails around customer data tight enough while still being usable? How good is the documentation — for humans and the AIs? The hackathon pressure-tests your build infrastructure the same way it pressure-tests everything else.

AI doesn’t just make individuals faster. It creates bursts of simultaneous demands on your systems and processes that they might not have been initially designed for.

A hackathon surfaces all of this at low stakes.

Engineering Isn’t the Whole Picture

If your hackathon only includes engineers, you’re only diagnosing part of the organization and leaving most of the value on the table.

Include product managers, designers, solutions consultants, marketers, ops people, CSMs; anyone and everyone whose work could be changed by AI. You discover where AI adoption hits organizational boundaries that engineering alone can’t see. The solutions team’s proposal process assumes a turnaround time that AI just compressed by 80%. The marketing team discovers they can automate content approval workflows between systems, cutting out manual copy-paste steps and the errors that come with them. These bottlenecks only surface when those teams are in the room using the tools.

You also see cross-functional connections form that didn’t exist before. A solutions consultant and an engineer end up working on similar problems and start comparing notes. A CSM and a product manager realize they’ve been solving the same workflow problem from different ends. Sometimes this reveals a missing dependency in your org. Sometimes it just means two people who had no reason to talk before now have a direct line to each other. Either way, those connections persist after the hackathon ends.

And you find champions in places you weren’t looking. Your best AI advocate might not be an engineer. It might be someone in pre-sales who realizes they can build onboarding tools, or a PM who discovers they can prototype wireframes in an afternoon. These are the people who’ll drive adoption in their own teams — and you’d never have identified them from inside engineering.

Side Quests That Power the Main Quest

Karri Saarinen at Linear talks about main quests and side quests — the idea that side quests feel productive but only the main quest advances the company’s mission. In normal operations, he’s right. But a hackathon is the one time you want people on side quests.

When someone builds a meal planner, a home renovation estimator, or a fantasy football optimizer, they’re not wasting time. They’re learning prompting patterns, discovering tool limitations, and building intuition for what AI is and isn’t good at. They’re failing in low-stakes ways that build the judgment they’ll need in higher-stakes situations. All of that transfers directly when they sit back down at their day job. The side quest and the main quest teach the same skills.

This is why the first learning hackathon should be open-ended — build whatever you want, doesn’t have to be work-related. When people choose their own problem, the “I don’t know where to start” barrier disappears. They already understand the domain, so the only new variable is the tooling. That’s one thing to learn instead of two. Once your team has that foundation, future hackathons can get more directed — give them themes, point them at specific organizational problems, ask them to build on what came out of the first round. But the first time, let them pick.

Work-constrained hackathons tell you who follows instructions. Open ones tell you who has curiosity, initiative, and creative instincts. The hackathon side quests are the training that sticks because it’s self-directed and personally motivated.

Real Data for Real Decisions

Before the hackathon, your AI transformation budget is projections and vendor promises. After, it’s based on how your organization actually behaved.

How many seats do you really need? Which tools/vendors did people gravitate toward? What does cost-per-user look like across different platforms? Where did the productivity gains show up, and where didn’t they? Do you have the right protections and limits in place?

AI comes at a real cost, and you have to justify it — to the CFO, to the board, and to the rest of the company. But you also have to be able to justify it to yourself. Your job isn’t just to fund technology. It’s to make sure the spend translates into real outcomes.

“Here’s what three hundred people built in two days” is a fundamentally different conversation than “here’s what a vendor, a consultant, or AI thinks we should budget.” You have demo-able outputs. You have usage data. You have a map of organizational readiness.

That converts a meaningful portion of your AI investment from a speculative line item into something grounded in observed behavior.

Two Days of Recon

Every one of these — adoption patterns, shadow AI visibility, infrastructure limits, cost behavior, cross-functional connections, real budget data — is something you need to understand, and usually only discover when it’s already causing problems.

The two days aren’t only a gift to your team, they’re reconnaissance. The projects people build, and the relationships they form along the way, are a bonus. The real output is how your organization actually behaves when it’s running at AI speed.

Most organizations don’t choose when they learn this. They just delay it. In other words, you can learn this safely, or you can learn it when it matters.

The post Hackathons: A C-Suite Perspective originally appeared on eric.lubow.org.

Not necessarily a specific person. Just someone — from engineering, from product, from anywhere in the company who steps up, goes on a building spree, finds the killer feature, and helps the company get to the next level — or at least live another day. It’s the miracle play. And it’s understandable, because sometimes the miracle play feels like all you’ve got. Therein lies the trap.

The Old Version

Everyone in tech knows this story. The 10x developer stays up all night, fixes the impossible bug, saves the release, builds a new thing for the client to win the deal. Everyone celebrates. The org even builds a mythology around it. We all know someone who has done this at some point.

Then the inevitable happens. The hero picks a new project, takes a vacation, or worse, burns out or leaves. And then everyone discovers just how much that person was carrying. Nobody else knows how their systems work, what decisions were made and why, or what they were planning next for this wondrous new thing. The organization was standing on fragility the whole time. It just couldn’t tell because the hero was heroing.

The AI-Accelerated Version Is Worse

Hero dependencies have always existed. Organizations have always had people who carry more than they should. AI didn’t create that pattern. It removed the constraints that used to keep it contained. The old hero could overextend on one thing. The new AI-enabled hero can run three or four projects in parallel. They understand the codebase, they know how to prompt effectively, and they’re shipping faster than entire teams used to. One person, moving at the speed of what used to take five. This looks like a superpower. It is, and it’s also multiplied fragility.

Knowledge concentration compounds. The hero built four things. Who else understands how any of them work? With traditional development, knowledge concentration was bad but bounded — one person could only build so much. AI removes that bound.

Things may not get handed off fully or at all, but they just keep running. Not every project ends in a clean handoff. Some things the hero built just … continue. They work. Nobody else touches them. Nobody else understands them enough. They don’t get the love, attention and maintenance that they need to exist properly. They just sit there (accumulating risk) until something breaks and now another hero someone needs to step in and perform CPR.

The hero can’t focus. When you’re carrying four things, you can’t give any of them the attention they need. The hero isn’t just at risk of burning out — they’re at risk of being pulled to hero something else while the thing that actually needs focus goes neglected. The company thinks it has coverage, but it’s just continuing to operate on momentum. Meanwhile, the hero is slowly getting more run down from operating beyond their own cognitive horizon.

The natural speed limit is gone. Manual development used to create a built-in buffer. As systems were written, the rest of the team had time to review, discuss, and build a shared understanding of what was happening.

AI removed that buffer. Now one person can move faster than the organization’s collective processing time. Without that thinking window, nobody else builds a mental map of the system. This doesn’t just matter when things break; it makes the system harder for anyone else to extend.

Now Multiply This Across the Org

One hero is a risk. But one hero is manageable. You can see the dependency and you can plan around it.

The real danger is when you have multiple heroes across multiple products, each one carrying their own expanding surface area of things only they understand. Each hero individually creates one or more of every problem above. Together, they create something exponentially worse: an organization where critical knowledge is fragmented across several people who are all overextended, all building things that, without a proper handover, are effectively unmaintainable. Not because the capability isn’t there, but because everyone else has their own work and no one was brought along for the ride.

And here’s the thing about crisis mode: when a company is fighting to survive, heroes feel essential. Someone stepping up and shipping looks like exactly what you need. So you encourage it. You celebrate it. You get more heroes. Each one saves the day on their front.

But without structure underneath them, you’re not actually surviving. You’re prolonging the inevitable. Every hero adds capability and fragility in roughly equal measure. At some point, the weight of all that unshared knowledge, all those under-maintained systems, all those potential single points of failure, collapses in on itself. The heroes didn’t save the company. They just delayed the reckoning while making it worse.

It’s always been true that you need to survive long enough to win the war. That’s always sitting in the back of everyone’s mind. But if your survival strategy is “more heroes, faster,” you might win every battle and still lose the war.

The Hero Isn’t Who You Think

Here’s what makes this even harder: the new hero isn’t necessarily an engineer.

AI lowers the barrier to entry for technical debt. A product person, an executive, a champion from outside of tech — someone who couldn’t have built anything on their own two years ago — can now spin up tools, prototypes, or workflows. That’s genuinely powerful. I’ve written about finding and empowering those champions because they’re essential to adoption.

But they create the same hero-shaped dependencies. Maybe worse, because they often don’t have the engineering context to recognize what they’re creating in terms of a maintenance burden, integration assumptions, or operational debt. They built a thing that works. They’re (rightfully) proud of it. And now it’s on the leaders to explain, without killing motivation or enthusiasm, that “works” and “is sustainable” are different states of being.

This isn’t their fault. It’s a leadership responsibility. If your organization doesn’t have structure around how things get built, handed off, and maintained, then every empowered builder — engineer or not — is a hero-in-waiting. The problem isn’t that they step up; it’s that our systems don’t let them step back down.

The Leader’s Job

To be clear: there’s nothing wrong with heroics. When someone steps up — stays late, takes on the hard problem, builds the thing nobody else could or did — that’s a signal that they care. They care about the product, their job, the company, the people around them. Whatever it is that they care about, they care. That’s something you want to see and something you want to encourage.

The problem was never the heroes. It’s the cost of the heroics.

Your job as a leader isn’t to stop people from stepping up. It’s to build the right support structure so that stepping up doesn’t mean burning out, hoarding knowledge, or becoming a single point of failure. You want to lower the cost of heroics so that the people who care the most aren’t punished for caring.

There’s an old proverb: “If you want to go fast, go alone. If you want to go far, go together.”

AI lets individuals go very fast. That’s empowering, real, and can be incredibly valuable. But without systems to support those individuals, you’re just creating more people going fast alone — and the organization isn’t going to get far together.

Your job as a leader is to recognize that this new world enables heroes in ways that weren’t possible before, and to build the structure that keeps hero-shaped dependencies from forming in the first place. That means investing in the things that feel like they slow you down: communication cadences that move information without requiring any single person to be present. Handoff processes built into the structure, not bolted on when someone leaves. Knowledge sharing that doesn’t live in one person’s head. Explicit protocols that don’t assume “everyone just knows.”

I’ve written about this at length in Treat Your Organization Like a Distributed System. The full framework is there. But the short version is simply: systems aren’t overhead and shouldn’t be treated as such. They’re the infrastructure that lets everyone move together, not just the heroes.

Yes, this means making people slow down at times. That’s hard to do and even harder when the business is in crisis mode, when speed feels like survival. But slowing down is how handoffs actually work. The only place where both parties are at a full sprint during the exchange is an elite Olympic relay — and that takes a lifetime of practice. In business, slowing down is how someone other than the hero can pick up the thing when the hero is pulled elsewhere. It’s the difference between surviving today and being able to survive tomorrow.

That’s why when I see AI-enabled development creating hero-shaped dependencies, I stop and map the problems so I can reinforce systems around them. Not because systems are fun to build (though I do enjoy it). But because without them, every hero you empower is also fragility that you’re creating.

The Point

Your job as a leader isn’t to be the hero, and it’s not to find one — though both might be necessary at times. It’s to make sure the heroes you have can do their best work without the organization paying for it later.

See where the dependencies are forming. Put structure around them. Lower the cost of heroics so your best people can keep caring without it breaking them or the org.

The post Systems Over Heroes originally appeared on eric.lubow.org.

These aren’t hypothetical risks; they are the friction points showing up as organizations begin to build development workflows at the speed of AI. Most of these problems will seem obvious once they are named. You might even think, “Yeah, we’ve already solved for that.” But depending on where you are in your adoption cycles, you might only be seeing symptoms.

These AI speed gains don’t come for free. This is an attempt to name the costs, the organizational friction, the workflow breakdowns, and the people problems, so we can move past reacting to symptoms and start designing from a position of understanding. That begins with acknowledging exactly what our newfound speed has actually changed and what it broke.

What Speed Actually Broke

One of the first things to break is the implicit contract between product and engineering. The familiar cycle of specs, handoffs, review processes, and coordination mechanisms was built around a simple assumption: writing code was the slow part of software development.

That assumption no longer holds. AI has moved the bottleneck. Writing code used to be the constraint; now the constraint is everything around it — reading, validating, coordinating, and maintaining shared understanding across teams. Most organizations haven’t noticed yet because they’re still measuring speed-to-build instead of the things that are quietly degrading around that speed.

Working through this at my own company, a few recurring patterns have started to show up. Some of them are well-understood. Some we’re still figuring out management strategies for. All of them will show up in any product and engineering organizations that are seriously adopting AI as a first class citizen in their workflows.

And most of them are people and organizational problems with process-shaped solutions. The underlying pattern is straightforward: AI has moved the bottleneck in software development from writing code to coordinating people. The intent here isn’t to dictate how every team should work. It’s to name these problems clearly enough so that when teams hit them, they have a starting point and some structure to work with instead of figuring it all out from scratch.

The People Problem

Your teams are getting faster and less-informed at the same time. AI makes individuals more capable, but it also reduces the natural incentive to collaborate. When an engineer can get an answer from AI in 30 seconds, they stop asking colleagues. Instead of knowledge spreading through the team, it lives privately in individual prompt sessions that no one else sees. The real problem is that those conversations were never just about getting answers — they were about knowledge transfer, mentorship, shared context, trust and rapport building, and catching blind spots. Junior engineers who bypass learning conversations will ship code but won’t build the judgment and experience, often built through mistakes, to know when the AI is wrong, or not as right as it could be if it had more context. Institutional knowledge stops transferring between people and starts getting mediated through an AI that only knows what’s been documented; which is never the whole picture. If you’re not thinking about deliberately maintaining and reinforcing the human connections, you’ll end up with an org where everyone is individually productive and collectively disjointed.

The knowledge loss goes deeper than just some missed conversations. In the old cadence, knowledge got reinforced organically. Engineers heard things multiple times across stand-ups, spec reviews, planning sessions, and code reviews. The repetition wasn’t an inefficiency of operations (though it can be that too), it was how people built mental models of the system and each other’s thinking. When AI compresses the build cycle, those touch points shrink or disappear. The work moves too fast for understanding to keep up through osmosis. If knowledge sharing is going to survive, it has to become intentional and be prioritized rather than simply a byproduct of a slower process.

There is a morale risk here that’s easy to overlook because it presents like resistance to change. It isn’t resistance, it’s a loss of professional identity. Many of your best people became engineers because the act of solving problems in code is deeply satisfying. Some people just love to code. When the job shifts from writing code to prompting an AI and validating its output, that satisfaction can disappear. This is a real loss that requires acknowledgement and, frankly, grieving. If you don’t recognize that the craft itself is being hollowed out, you will lose the people who value that craft—the same people whose deep system knowledge you now need more than ever to catch the AI’s mistakes.

There’s also a capacity illusion that comes with AI-assisted work. When the AI can generate code quickly, it’s tempting to run multiple work streams in parallel. And why not, the AI is doing the heavy lifting. But the human still has to hold context for each one, validate each one, and make decisions on each one. The cognitive load doesn’t parallelize even if the code generation does. What looks like three projects running concurrently is really one person context switching between three projects at AI speed instead of human speed. The throughput might go up for a while, but the sustainable pace drops. People get tired faster and the quality of their judgment on each individual work stream suffers because none of them are getting full attention.

The Handoff Problems

The people problem above is about what’s happening inside teams and for individuals. The handoff problems are about what happens between teams — though they’re people problems too. Every one of the following involves getting work from one person or team to another. This could be from a PM’s prototype to an engineer’s implementation, from a lab or skunkworks experiment to a production system, from one document to the next review cycle. In the old world, these handoffs were mediated by specs and meetings that moved slowly enough for everyone to stay aligned. AI blew up the speed of building but didn’t change the speed of human understanding. The result is that handoffs are now a primary source of friction, miscommunication, and risk.

Greenfield is the easiest one. A new project built from scratch in a small team. This is ideally one PM and one engineer, scaling to no more than three to five, with a prototype as the communication artifact instead of a spec. The coordination mechanisms are simple: a Slack channel, small frequent PRs, and a clear owner for merge conflicts. This mostly works already if you keep teams small enough.

The harder question comes next, when this prototype needs to become a real product with monitoring, integrated auth and permissions, access to your data and pipelines, operational support and everything else involved in productionization — how does it move from wherever in the org that created it into engineering? Greenfield solves the building problem cleanly. It doesn’t solve the graduation problem. But these things won’t stall, they’ll make it to production. They just make it to production without being productionized. I’ve written before about why building isn’t the hard part; this is where that lands.

Brownfield is where it gets genuinely hard, and it’s where most organizations actually live. A PM can prototype a feature, but that prototype creates an asymmetry of knowledge: it effectively captures the ‘what’ while ignoring the ‘how’ of the system complexity underneath—the dependencies, the performance requirements, and the ways a 20-year-old monolith can turn a small change into a production incident three weeks later.

The old spec cycle (PM spec → technical spec → implementation spec → review → repeat) is too slow, but you can’t skip the planning either. In brownfield, upfront planning isn’t overhead, it’s the risk mitigation step. The engineering lead who catches a dangerous dependency during a complexity triage just saved you an SLA violation. The question isn’t whether to plan. It’s how to keep the risk mitigation value of planning while eliminating the document-heavy overhead that AI is actively making worse. Without this triage, the asymmetry of knowledge remains. It ends up forcing the person with the most context to spend their time reacting to what was built, rather than guiding how it’s built.

Lab-to-production graduation is closely related to greenfield, but still distinct as an ownership problem. People are building prototypes. Sometimes with real customer data. Sometimes already in front of customers. Sometimes before anyone in Product or Engineering hears about the idea and can ask the question of who maintains it, who’s on-call for it, how it fits into the strategy, and which team absorbs it. Even if these questions could be asked, they probably don’t have a clear answer when everyone is moving so quickly. The technical gap between prototype and production is shrinking (good template systems help), but the organizational gap is wide open. And this comes with the same handoff challenges as any production work — someone has to own it end to end.

The Documentation Trap

Spec cycle bloat deserves its own section because it compounds every handoff problem above. AI makes documentation cheap to produce and therefore often quantitatively difficult to read. Every handoff generates longer, denser documents with even more detail. Every review cycle requires more reading to ensure all the nuance is captured and correct. The thing that was supposed to make you faster creates a heavier process because the bottleneck shifted from writing to validating.

If you’re not careful, your engineers spend more time reading AI-generated specs than building. This becomes even harder when the people validating still carry undocumented knowledge in their heads — the gotchas that aren’t in any spec because they never needed to be until now. The AI doesn’t know about the database migration that failed silently in 2021, or the vendor integration that breaks if you send more than 500 records at once. The humans who carry that knowledge are now reading longer documents and catching fewer issues because the volume overwhelms their attention.

This is the feedback loop that isn’t getting enough attention: AI generates more documentation, which requires more human review, which takes longer, which slows down the very process AI was supposed to accelerate. The solution isn’t less documentation — it’s almost certainly going to require rethinking what documentation is for and who (or what) needs to read it at each stage. You can’t solve an understanding problem with a summarization tool.

The PM Throughput Bottleneck

The documentation trap slows down the work that’s already in flight. But there’s a related problem upstream: the pipeline feeding that work can’t keep pace either. There is a growing asymmetry in the contract between Product and Engineering. It’s not just that engineering velocity is increasing; it’s that the volume of work required to direct that velocity has expanded. In the old model, PMs had weeks or months of lead time while engineering built a feature. That buffer allowed for slower, more sequential discovery processes. Now, that buffer has been compressed. This isn’t a matter of PMs simply “moving faster” or lowering their standards to keep the team busy; it’s a structural requirement for Product to operate differently.

The bottleneck has moved upstream. When a team can ship in days what used to take months, the “thinking” work, like validating needs, defining logic, and synthesizing feedback, has to happen at a completely different cadence. But we can’t let this increased throughput trick us into building the entire backlog without the requisite consideration for each feature. Just because we can build everything doesn’t mean we should. If the PM operating model doesn’t evolve to match this implementation speed, the engineering team either sits idle or begins building from half-baked inputs. This happens not because of a lack of skill or talent, but because the old process for defining the “why” wasn’t built for an engineering team that no longer has a “slow” build phase.

The Code Quality Problems

Everything above is about how people coordinate around the code: the handoffs, the documentation, the upstream pipeline. But at some point the code itself becomes the problem.

Merge and duplication get worse at speed. When AI generates code fast, you can get multiple versions of the same utility function in multiple branches before anyone notices. Worse, teams might solve the same problem in different ways in different parts of the codebase, leading to inconsistent behavior across the application. In a monolith, you can’t contain this the way decomposed services can. Decomposition would help, but it’s not realistic on most roadmaps right now when everyone else is speeding up their delivery. The pragmatic answer might be accepting some duplication as the cost of speed and building detection tooling to catch it, rather than trying to prevent it through process.

PR review is the code-level version of spec cycle bloat. AI-generated code can produce hundreds of files and thousands of lines in a single pass. Traditional human review can’t assess that volume meaningfully. But skipping review in a production codebase isn’t an acceptable alternative. The instinct is to use AI to review AI-generated output, and that might end up being part of the answer. But it’s worth being honest about what that actually is — a recursive validation loop where you’re trusting one model to catch the mistakes of another when neither of them have all the context. That might be a reasonable tradeoff. It might also just push the problem one layer deeper.

And regardless of how the code was generated or how many AIs went over the PR, the engineer who submits it owns it. A large PR doesn’t absolve anyone of responsibility — if anything, it raises the bar on making sure you understand what you’re shipping. The discipline of keeping PRs small enough, structured, and reviewable matters more now than it did when humans were writing every line by hand.

And when something breaks, the problem compounds even further. The person on-call for troubleshooting often didn’t write the code — but in the old world, they usually would have. They’d have a mental model of why it was built that way, what the edge cases were, what they were worried about when they wrote it. Now they’re debugging AI-generated code they’ve never seen, trying to reconstruct intent from output. When they get stuck, they escalate to their engineering lead to support, who also didn’t write it and can only offer architectural intuition rather than implementation-level knowledge. The AI that generated the code has no memory of the conversation that produced it. Incident resolution takes longer on code that was faster to produce — another version of the pattern running through this entire piece.

Where the Guardrails Aren’t

The problems listed so far are pretty much all variations on the same theme: speed creating new forms of friction. These last two are different. They’re not about the work itself, but about the guardrails around the work, and the reality that AI is putting people into territory they weren’t operating in before.

GDPR, compliance, and data protection requirements still exist. The risk is different in three contexts: during development (lower concern since you’re working with code, not production data), during troubleshooting (high concern as you may be sending PII to external AI tools), and when building applications that handle PII or personal data (full compliance required before go-live). These often get conflated into a single “be careful with what you send to AI” warning when they all need distinct answers. And those answers can vary by customer and by region. On top of that, contractual obligations add another layer that a blanket policy can’t cover.

DevOps boundaries are inconsistent. Faster development expands the surface area where teams can operate independently. That includes infrastructure, which means mistakes also happen faster. Most organizations have no clear definition of what engineering teams can do independently versus what requires DevOps involvement. There was usually more time in the development lifecycle and DevOps could plan and deliver accordingly. The new result is bottlenecks, inconsistency, and risk from engineers doing DevOps work without the full picture.

This gets particularly dangerous when an engineer can tell an AI to provision infrastructure without understanding whether the AI is following best practices or just following orders. An inexperienced engineer (or non-engineer) with an AI assistant can create a production-facing VM, a misconfigured database, or a security hole with a few prompts, and the AI won’t flag the risk because it wasn’t asked to. On top of that, who maintains this infrastructure and does things like OS upgrades when the engineers aren’t used to following standard DevOps practices on maintenance?

From Naming to Structure

All of these issues are fundamentally people and organizational challenges. Process can provide the scaffolding, but the real work is in the people and the culture.

I’ve written before about the leadership philosophy of context, not control — giving people the information they need to make good decisions rather than telling them what to do. That same principle applies here, this time to the process design itself. This piece is the context part. Naming the problems clearly enough that when your teams hit them, you’ve already been thinking about them. And when everyone is working from the same vocabulary, the org starts learning from itself — teams can share what’s working because they’re describing the same problems.

There aren’t yet clean answers for all of these. Some are further along than others and will come in future posts. But the pattern behind them is already clear: AI has moved the bottleneck in software development from writing code to coordinating people. The first step is naming these problems, because they’re already here whether you’ve articulated them or not.

The post The Month Two Reality of AI-Enabled Development originally appeared on eric.lubow.org.

Two that have worked well for me for AI adoption specifically are: hackathons and local champions. Hackathons (Using Hackathons to Drive Real AI Adoption) are the spark because they create permission, surface potential, and, through their peers and colleagues, show people what’s possible. But they’re events. The energy from them fades quickly. The question is what keeps adoption moving between the events. That’s where your local champions come in.

What Happens When You Do Nothing

When you let AI adoption happen organically, what you actually get is a widening gap. A few people figure it out on their own because they’re already curious and already experimenting. Most don’t. They’re busy and already have their workflows. The tools feel like one more thing on the pile.

Training doesn’t solve this either. At least not the way most companies do it. Standalone training is a checkbox. People complete the modules, do their “Hello World”, and go back to their real work. There’s no destination to build their excitement. No connection to a problem they actually have. It’s education without motivation, and motivation is the hard part.

The gap compounds. The early adopters get faster, produce better work, and start pulling away from the rest of the team. Two months later (AI moves quickly), you have a bifurcation within the team: there is a handful of people who can’t imagine working without AI and a group who’ve barely touched it. The absence of an adoption strategy is itself a decision. It tells your org that you’re fine with the split.

There’s a second cost that’s easier to miss. Your best people, the ones leaning in, are watching whether the organization is keeping up with them. Top talent wants to work at places that match their vibe and their pace. If you make them use new tools under old constraints, or treat adoption as optional, they’ll eventually find somewhere that doesn’t. It’s the same logic as the old training question: “What if we invest in people and they leave? What if we don’t and they stay?” With AI adoption, there’s a third option that’s worse than both: you don’t invest, and they leave.

Find Your Champion

If you’ve been around enterprise sales, you’ve probably seen MEDDPICC (Metrics, Economic Buyer, Decision Criteria, Decision Process, Paper Process, Identify Pain, Champion, and Competition). We’re selling a new way of working into our organizations and we need to find our Champion. In the framework, a champion is someone with credibility and influence inside the buying org who actively sells on your behalf. Not because you asked nicely, but because they believe in the outcome. You don’t sell to the whole buying committee. You find your champion, arm them, and let them do what you can’t: influence from the inside.

AI adoption works the same way. In every department, there’s someone who’s already leaning in — or could be with a little investment. Your job as a leader isn’t to convince the whole team. It’s to find that person and make them wildly successful. Their results do the convincing for you.

Don’t forget that your org chart doesn’t dictate your influence map. The champion is often not the team lead or the department head. It’s whoever has the right combination of curiosity, credibility with their peers, charisma, enthusiasm, and willingness to show their work publicly. Sometimes it’s the most junior person on the team. Sometimes it’s someone in a completely different department.

That last point becomes more important the higher up you are in the org chart. If you’re a CTO or a senior executive, your champions aren’t limited to your own org. You can spot these people in different departments across the company and support them from the outside. Give them air cover. Connect them with your technical team to accelerate their capabilities. Help them go further than they could go alone. You don’t need to own the department to enable the person.

Influence and charisma beat authority in behavior change. Once you’ve found your champion, back them. Don’t use them as a mouthpiece for leadership, but focus on them as an organizer. Have the champion pull together the people around them. Here, it’s more about small groups, local to their team, who are working through similar problems. This works because the champion is a peer, not a manager. When your team lead says “you should try using AI for this,” it’s a directive. When the person next to you, doing the same job, dealing with the same frustrations, shows you how they solved something in twenty minutes that used to take a day, that’s leading through influence. It’s like the gym: you don’t get energy and then go. You go, and the energy comes. The champion’s early success creates the momentum for the people around them to start. Peer-driven change doesn’t trigger the same resistance as top-down mandates. It doesn’t feel like a corporate initiative. It feels like colleagues sharing something useful.

The leader’s role here isn’t to run the group or set the agenda. It’s to recognize the champion, give them the space, and make sure they know they have support. The organizing energy comes from the champion. The air cover comes from you. Once people are convinced, you can swoop in with the training and enablement.

Shifting the Internal Baseline

One person on our strategy team started building pre-sales tooling with AI. Specifically, they built an onboarding tool that mirrors our existing sales and onboarding workflows. This helped the sales reps get up to speed faster on a new offering and demo more effectively without waiting for someone to walk them through every detail one at a time.

The tool wasn’t “engineering spec” perfect. But it didn’t need to be. It did the job better and faster. It’s hard to argue with a working demo. When the rest of the strategy, pre-sales, and sales teams saw what was possible — the speed, the quality, and the fact that one person built it — the baseline shifted.

Now the rest of the team is adapting. Not because someone set a mandate. Not because there was a training module. But because someone on their team demonstrated a new standard, and the gap between “how we’ve been doing it” and “how it could be done” became visible and undeniable. The champion didn’t need a title or a directive, they needed room to run. And they needed to know that this kind of initiative is what the org actually wants, not just tolerates.

Make the Work Visible

Give champions room to run and they’ll create proof points. But a proof point only works if people see it. If the strategy team’s onboarding tool lives in one person’s demo and one team’s Slack channel, the effect stays local. You need mechanisms that make the work repeatedly visible across the org.

We run a weekly show-and-tell where anyone can present what they’ve built. It doesn’t have to be finished or polished. The point is exposure to ideas: people seeing what’s being built, how fast it can be built and iterated on, and what problems are being solved.

We also run a #topic-inspirations channel in Slack where people share tools, prototypes, and vibe-coded projects built outside the company, and explain why they’re interesting. This expands the frame of reference. It’s not just “AI is coming.” It’s “look what people are already building, right now, everywhere.” It sets the context for what’s possible.

Then there’s #topic-prototypes, where people share what they’ve built internally. This is the lower-barrier version of the show-and-tell. It’s available all the time and for people who’d rather share asynchronously or aren’t ready to present live. Plus there is immediate discussion that you don’t get during presentations. But it’s also where the external inspiration becomes personal. The inspirations channel shows you what the world is doing. The prototypes channel shows you what your peers are doing. That’s the one that usually hits home.

This creates a specific kind of productive peer pressure. When you see someone from a completely different team demo a tool they built in an afternoon that solves a problem you’ve been dealing with for months, it recalibrates your sense of what’s possible. And when it happens with regularity, it becomes hard to sit on the sideline. These channels are also where your champions, the most vocal and enthusiastic people, gravitate to the same conversations.

But inspiration without enablement creates frustration and potentially resentment. It’s easy for someone to watch a show-and-tell, get excited, open a tool, and immediately feel lost. That’s where targeted training closes the gap. Not training as a standalone program either. It needs to be training that gives people just enough to mimic what they saw. The champion built an onboarding tool? Show people how to prompt effectively for that kind of output. Someone demoed a workflow automation? Walk through the first three steps. The goal isn’t mastery, it’s a first successful attempt. It’s making the mountain of learning feel like a molehill.

There’s a third channel that serves a different purpose: #topic-ai-support, where anyone can ask questions. This is including questions that they may feel are stupid. How do I get Claude to stop hallucinating this API end point? Why isn’t my prompt doing what I want it to? Can someone explain what a repo is? How do I even start? This channel has to be actively protected. The moment someone gets a dismissive response or feels judged for not knowing something, the tone changes and the channel goes silent. And with it goes the fastest path for people who are willing to try, but aren’t yet confident. Visibility and pressure only work if there’s a safe space to be a beginner. Without it, the people in the middle of the adoption curve, the ones who are curious but uncertain, will continue to just watch from the sidelines instead of jumping in. The show-and-tell creates aspiration. The training creates a bridge. The support channel creates permission.

None of this is accidental culture. The weekly cadence, the Slack channels, the low barrier to sharing — it’s all designed to keep adoption visible and normal. The more people see their peers building, the more building feels like the default rather than the exception. When you’re asking everyone to move faster through the adoption curve, you have to make it accessible.

Let the Process Catch Up

As adoption picks up, some of your existing processes will start to feel out of place. That’s probably because they are. AI changes the cost and speed of certain kinds of work, and that means the sequence you’ve always followed may no longer make sense.

Here’s a simple example: we used to write a PRD, get alignment, and then build. That’s a reasonable workflow when building is expensive or time consuming. But when someone can prototype a working version in an afternoon, the smarter move is often to build first and write the PRD once you’ve validated the idea. The PRD becomes a document that captures what you learned, not a speculative document that guesses at what you’ll build.

This isn’t about abandoning rigor. It’s about being honest that AI changes the economics of certain steps. Refusing to adjust your process is its own kind of rigidity. Some processes will shrink. Some will move. Some will disappear entirely. If you’re serious about adoption, you have to be willing to let the workflow evolve alongside the tools. Otherwise you’re asking people to use new tools inside old constraints, and they’ll feel the friction of that choice every day.

Your local champions will surface these friction points before anyone else. They’re the ones hitting process walls first because they’re moving fastest or just operating differently. Pay attention to where they’re getting stuck or slowed down. When a champion tells you the approval workflow doesn’t make sense anymore, or that a review step is now the bottleneck instead of the build, that’s not a complaint. That’s a signal about which processes require review.

Why Pushing Is the Kind Thing to Do

Left alone, most people will stay where they’re comfortable. That’s human nature, not a character flaw. We all default to the familiar until something forces us out of our comfort zone and into change.

But the world is changing whether your team opts in or not. The tools are getting better every month. The expectations are shifting and the goalposts are moving. The people who aren’t building these skills now will be materially behind in just a few months.

This is where I think a lot of leaders get it wrong. They frame adoption as optional, “here are the tools, use them if you want.” It feels respectful because they don’t want to be heavy-handed. But that’s actually the less kind option. You’re letting people fall behind because pushing feels uncomfortable for you.

The other version of this mistake is making adoption mandatory but skipping the infrastructure: no champions, no visibility, no training with a destination, no safe place to ask questions. Just a mandate and a deadline. That gets the direction right but with none of the mechanics. People comply without adopting and you end up with checkbox completion, not behavior change.

The kind version is the harder one: push and invest. Nudge people along the adoption curve while giving them every reason and resource to move. You are not dragging people because you’re impatient with their pace. You are pushing because you can see where things are going and you’d rather they be ready than surprised.

That’s what it means to actually care about your people’s growth, not just their comfort. Sometimes caring about someone means making them uncomfortable now so they’re not in crisis later.

This Is All Culture

Every decision you make, and every decision you don’t make, defines your culture. Running a hackathon is a culture statement. Investing in your champions is a culture statement. Building visible channels, targeted training, and a safe place to ask beginner questions; these are all culture statements. Letting the gap widen because you don’t want to force change on people; that’s a culture statement too.

Culture isn’t what you put on a slide. It’s what you do repeatedly when it’s inconvenient. Culture is how people behave when no one is telling them how to operate. If your culture is about making people better, genuinely better, then building these mechanisms is what that looks like in practice.

Hackathons to create the spark. Champions to sustain it. Visibility to create momentum. Training to close the gap. Support to make it safe. And a willingness to keep pushing even when people would rather stay where they are.

Adoption strategy is culture strategy, whether you frame it that way or not.

The post Champions, Not Mandates: How to Actually Drive AI Adoption originally appeared on eric.lubow.org.

Then you spend a few hours communicating it. It’s a 30-45 minute explanation in all-hands. A Slack post. Maybe a follow-up Q&A. Then you’re surprised when people aren’t aligned, when they make decisions that don’t reflect the strategy, or when they ask questions you thought you’d already answered. This matters even more when the strategy isn’t incremental, like when you’re asking people to change how they fundamentally work, not just what they’re working on.

The uncomfortable truth is, as a leader, you’ll be sick of your own voice long before the message sticks. Most leaders stop repeating because they’re bored, not because they’re done. Repetition isn’t about persuasion. It’s about responsibility.

It’s not a failure of your people’s ability to understand and internalize change, it’s a reflection of the information asymmetry. It’s a failure to recognize that absorbing strategy takes repetition — often a lot more of it than we, as leaders, want it to take. Strategy isn’t strategy unless repeated.

Why One-and-Done Fails

Your people have day jobs. They’re deep in their day-to-day, shipping features, troubleshooting issues, managing their teams, sitting in their own meetings. They are still executing the last version of the strategy as they understand it. They are still working off the priorities that they know. When you present the (new) strategy, you’re asking them to context-switch into your world for an hour, absorb weeks or months of your thinking, follow your train of thought, and then go back to their work with (hopefully) perfect retention.

That’s not how brains work. It gets harder when you factor in that everyone comes with different context, different tenure, different experiences with past strategies that did or didn’t pan out, different abilities to internalize new information, different levels of trust in leadership, different baggage from previous companies, you get the idea. People are people. The person who’s been at the company for five years hears your strategy differently than the person who joined last month. The person who got burned by the last reorg hears it differently than the person who benefited from it.

A single communication gives people facts and opinions. It doesn’t give them understanding. And without understanding, you get compliance at best. People will mostly do what they’re told because that’s how the professional game is played and people want to do a good job. But compliance isn’t buy-in. Buy-in is when people bridge the gap between what you’re asking and what they already care about. That takes (much) more than one pass.

Strategy Delivery Should Be Multimodal

Repetition doesn’t mean sending the same email five times (or 3 times on email and twice on Slack). It means delivering the same core message through different channels, at different depths, in different contexts, and usually also from slightly different angles.

Here’s what this looks like in practice:

• Town Halls work for the macro view. Monthly, I cover the big strategic updates. These are things like: what’s changing, why it’s changing, what success looks like. This is the org-wide context that everyone needs to hear directly, not filtered through three layers of management. These should be happening weekly if you are in the thick of the changes.
• Weekly leadership syncs keep the cascade flowing. Every week, I make sure my staff has the latest context from the Senior Leadership Team so they can translate it for their teams. This isn’t about them parroting my words, it’s about them having enough context to answer questions and connect strategy to their team’s specific work. They know their people and how to talk to them. It’s also giving them the forum to deepen their understanding amongst their peers who likely have the same questions.
• One-on-ones are where the really deep understanding actually happens. This is where you find out if the message landed and can see where the translation gaps are. It’s where you can connect the abstract (“we’re shifting our focus to enterprise customers”) to the concrete (“here’s what that means for the project you’re working on”). It’s also where people feel safe asking the questions they didn’t want to ask in front of 250 people or 10 of their peers.
• Async updates handle the in-between like emails or Slack. Not everything can or should wait for the next Town Hall. When something important shifts, I send updates to the relevant levels of the org. This keeps people from being surprised and reinforces that communication is ongoing, not just a monthly event.

The point isn’t volume (although sometimes that helps). It’s that the same message, delivered through different formats at different depths, with different starting points, helps it to actually stick.

Same Strategy, Different Depths

Strategy means different things at different altitudes in your organization.

At the departmental or org level, people need the what and the why. What are we doing? Why are we doing it? What does success look like? This is the narrative. It’s the story that ties everything together.

At the team level, people need the so-what. How does this affect our roadmap? What should we prioritize differently? What does this mean for the project we’re halfway through?

At the individual level, people need the connection to their work. Why does what I’m doing matter to this strategy? How do I make decisions when I’m deep in the details and nobody’s watching?

You can’t skip levels. If you only communicate at the org level, people nod along but don’t change their behavior. If you only communicate at the team level, people don’t understand the bigger picture and can’t make judgment calls. The goal is for people to connect the dots between their day-to-day and the change in strategy. Part of that connection is helping them see how the strategy aligns with what they already care about– their growth, their team’s success, the problems they’ve been wanting to solve, whatever it is. That’s what generates real motivation. You have to help them make that connection at every level.

Problem Before Solution

You can’t give people everything at once. The temptation is to lay out the full picture: here’s the problem, here’s the solution, here’s the plan, here’s the timeline. People try to do all that in one comprehensive presentation. Resist that urge.

People need to understand the problem deeply before they can hold the solution. If you jump straight to the answer, you get two failure modes. First, people who didn’t fully grasp the problem can’t evaluate whether the solution makes sense. They’ll nod along and usually follow your logic, but they won’t be able to make judgment calls when they hit edge cases. Second, if the solution changes later, and it inevitably will, you have to re-educate from scratch because they were never afforded the opportunity to build the foundation. They learned “do X” without learning why X was the answer to begin with.

Start with the problem space, then the problem itself. Let that sit. Some people need the processing time that you already heard during the time you were building the strategy. The goal is to anchor them in the problem so deeply that when the solution evolves, they can follow why.

If you don’t have the whole solution figured out, say so. If you do have the full plan, you can share it, but spend more time ensuring people understand the problem than the solution. The solution is what they’ll execute, but the problem is what lets them adapt when execution gets messy.

Then, when you come back to them, in the next Town Hall, the next leadership sync, the next async update, use the questions you collected to fill more of the gaps between problem and solution. Remind them of the foundation before you rush to build on it. The old writing advice applies: tell them what you’re going to tell them, tell them, tell them what you told them. But the real point isn’t repetition for its own sake. It’s that each pass adds depth to a structure they already hold.

Restating From Their Perspective

The challenge that’s less obvious is getting everyone to believe that you understand the problems from their perspective. You see the path clearly. You’ve been thinking about this for months. You know the problems, you’ve mapped as many of the solutions as possible and you see how the pieces fit together. But your people see their corner of it. They see the problems as they experience them — the frustrating process, the unclear priorities, the thing that’s been broken for six months that nobody seems to care about.

Just because you see it doesn’t mean they know you see it. Most of the time, this is about restating the same problem with a different perspective. Not new information, new framing. When you describe the problem the way they experience it, you go from only trying to convey that, “leadership has a plan” to, “leadership actually gets it.” That’s when the nodding stops being performative and people really buy in.

The questions people ask along the way are how you learn their perspective. Pay attention to what’s coming up repeatedly in 1:1s, in Slack threads, in the Q&A after Town Hall, or through the grapevine. Those patterns are telling you three things at once: where your communication has gaps, where their understanding has gaps, and where your strategy itself might have gaps. That third one is easy to miss — especially when you’ve been thinking about this non-stop for weeks or months and started to drink your own koolaid. The questions aren’t just revealing what people don’t understand, they’re revealing what you might have gotten wrong or left unconsidered. The people closest to the work often see things you don’t.

When you take those questions and weave the answers into your next communication, you’re not just filling gaps. You’re demonstrating that you’re listening, that you heard them, that their perspective shaped the conversation, and that the strategy is a living thing that incorporates input from across the org. That’s what makes repetition feel like dialogue instead of broadcast.

Making Strategy Stick

All of this repetition has a goal beyond alignment: getting people back to a state where the new strategy is their normal.

Change requires a different kind of energy than execution. During transformation, people operate in high-alert mode because they are processing new information, questioning old assumptions, adapting workflows, and finding a new normal. That’s cognitively expensive. Some people thrive in it briefly, but nobody thrives in it indefinitely, even the highly motivated ones. People can be productive in crisis mode, but they’re more consistent when they’re back to business as usual. The sooner you get them there, the more easily work flows from all levels of the organization.

The goal isn’t perpetual communication about the strategy. It’s reaching the point where people stop thinking about the change because the change has become the default. That’s when you get sustained output. That’s when people have headspace to be creative within the new model rather than spending their energy just understanding it and adjusting to it.

Visibility of progress accelerates this transition. If you’re in the thick of transformation, weekly updates like company-wide Town Halls are reasonable. You reinforce the information, build on it, and add nuance where relevant. At a minimum, there should be monthly communication about what’s shipped and what impact it’s had. People need to see valuable work coming out of the organization, even work that doesn’t touch their team directly. This is especially powerful through the lens of the new strategic direction. It creates stability during periods of change and signals that business as usual is still occurring, even while things are shifting.

Repetition is how strategy becomes culture.

Your Posture Matters

How you show up matters as much as what you say. There are two important things to get right here.

First, be honest about what you don’t know. It’s okay to say “here’s what we’re confident about, here’s what we’re still figuring out.” This isn’t weakness, it’s honesty; and it’s the kind of honesty that builds trust and leaves room for people to contribute. You’re reminding people that they’re not just executing orders. They’re in the positions they’re in and part of your organization because they can contribute, spot problems, and ask hard questions. Being genuine about uncertainty creates the conditions for people to actually speak up when something doesn’t make sense. If you perform total confidence, you’ll get compliance and silence. If you’re honest about the edges of the plan, you’ll get engagement.

This connects to something bigger: you want people to believe that you’re in this together. The strategy will never be perfect. Moving forward as a group, testing assumptions, changing course when needed, that only works if people have the psychological safety to raise concerns and everyone’s willing to engage honestly. Your willingness to say “I don’t know” models that it’s safe for them to say it too.

Second, manage your own excitement. If you’re genuinely energized by the strategy — and hopefully you are — the temptation is to share too much, too quickly. You want to brain-dump for hours, get them as fired up as you are, and show them the whole vision in all its glorious detail. Resist that urge. Your enthusiasm can work against you if it floods people before they’re ready. When you give them everything — the problem, the solution, the implementation details, the long-term possibilities — you crowd out their own thinking. They become executors of your ideas instead of contributors to the strategy.

Show the excitement. That kind of energy is contagious and necessary in moments where you’re trying to bring people along. Let them see that you believe in this. But hold back on every single detail until they’ve had time to hear the core message a few times, digest it, and start forming their own ideas. The goal isn’t just to transfer your vision into their heads. It’s to create enough space that they can add to it.

A Cadence You Can Steal

If you’re looking for a starting point, here’s a simple communication cadence:

• Monthly: Town Hall covering macro updates (repeating prior context while adding new layers), progress on strategic initiatives, and visible wins from across the org. These should be weekly during the more intense periods of change.
• Weekly: Leadership sync where your direct reports get the latest strategic context so they can cascade it, prioritize it and tie it in appropriately.
• Ongoing: One-on-ones that explicitly connect individual work to strategy, not just status updates and career conversations.
• As-needed: Async updates when something important changes and can’t wait for the next scheduled touchpoint.

The work isn’t done when you’ve communicated the strategy. It’s done when the strategy changes how people decide without you in the room. If you’re tired of hearing yourself say it, you’re probably halfway there. Until then, keep repeating. Until then, keep repeating.

The post Strategy Isn’t Strategy Unless Repeated originally appeared on eric.lubow.org.