What AI Builders Inside Large Orgs Actually Deal With When They Are Not Developers, Engineers, or Technologists

Table of Contents

Note: This post is about patterns, not specific people or places. The examples are drawn from my own experience building AI prototypes inside a large enterprise, but names, products, teams, and specifics are anonymised or generalised. No proprietary data, internal systems, or confidential business logic is described here. Where I point to research, I link the source so you can check my own ‘read’ against the literature.

I built a functioning proof of concept for a real-time multimodal in-product help agent — one that watches your screen, listens to your question through your microphone, and infers in real time using your natural language, your screen, and product documentation to guide you step by step through the product. Text-chat had been the dominant AI interface in our product. This was something different. It worked as a proof-of-concept and became more real after I prototyped it using Google’s Agent Development Kit.

I showed it in live demos. I got genuine interest. I also got this :

Bil built this in his bedroom.

Actual engineers need to look into this.

This is a cool AI demo you could make because of AI — but it isn’t production-ready.

Did you submit an AI Innovation intake form for this?

Why didn’t you build this with our official AI Innovation tools?

This is great — thanks. We’re going to use it for our IT project. You can go back to your desk.

This still needs to go through compliance.

None of those are technical critiques. They are status critiques, procedural deflections, and capture moves dressed up as due diligence. None of them engage with what the demo showed.

I had researched and written thorough documentation of the solution design, architecture, business case, and economics — I was able to address specific questions requiring the details. But the same fall-back statements remained, and I am never certain what the real reasons — one and two — are for not wanting to move forward, because I kept getting reasons three, four, and five that never got to the true blockers.

The first time you hit these, they feel personal. The second time, you empathise with the challenges and constraints folks are under. The third time, you start to see the system. And once you see the system, you can start working with it instead of against it — flow like water, rather than smashing against stone. What helped me most was discovering that almost none of this is unique to me, the organisation, or even to AI. The patterns are old, well-studied, and have names. Naming them is the first step to not taking them personally.

The guiding question for this post is simple : why do genuinely useful AI prototypes get dismissed inside organisations that say they want AI innovation, and what can a builder actually do about it?

Goal #

The goal here is not a manifesto. It is a field card.

I want to describe the landscape someone trying to build with AI actually operates in inside a large enterprise, name the forces that create resistance, point to the research that shows those forces are real and predictable, and offer a set of practical tactics I have tested or plan to try. This is my working model after a year of building proofs of concept, navigating demo rooms, and watching good ideas get sidelined.

Some of it is specific to my context. Most of it, I suspect, will be recognisable to anyone doing similar work inside a similarly sized organisation.

Working assumption #

The first working assumption is that most of the resistance someone trying to build with AI encounters is not personal and not irrational. It is a predictable output of how large organisations protect themselves from change. Understanding that does not make the resistance disappear, but it does change how you respond to it.

The second working assumption is that a prototype is not a formal proposal. It is a demonstration of a possible future. In the design and innovation literature, a prototype works best as a boundary object — a shared reference point that lets people from different functions engage with the same thing from their own expertise, without having to agree on everything first (Star & Griesemer, 1989; for the design-prototype version, see the boundary-objects-in-innovation work). Treating a prototype as a proposal invites people to evaluate it as one, and proposals get judged on completeness, risk, and organisational fit — all of which a prototype will fail on by design. Keeping it a boundary object keeps the conversation on the capability, not the artifact.

The dismissal layer #

The most common form of resistance is the dismissal. It usually arrives as one of a few recognisable variants.

The provenance attack. “Bil built this in his bedroom.” The demo gets judged on where it came from rather than what it shows. This is the oldest pattern in the book : Katz and Allen documented the Not-Invented-Here syndrome in a study of 50 R&D project groups back in 1982, showing that groups systematically devalue ideas based on their origin rather than their merit (Katz & Allen, 1982). The classic version is rejecting external ideas. The enterprise-AI version is subtler — the idea was generated internally, but outside the standard team or process, so the origin still becomes the argument. Either way, provenance is being used to avoid engaging with the thing itself.

The production-readiness deflection. “This isn’t ready for production.” True, and also irrelevant. A prototype is not supposed to be production-ready. Saying so is not a critique ; it is a change of subject. The useful question is whether the capability is worth pursuing, not whether this particular artifact is deployable. Even with economic modelling of the potential cost impacts, the looming shadow of roadmap changes and new projects stalls discussion of next steps.

There is a research finding underneath this that took the sting out of it for me. Mueller, Melwani and Goncalo showed that people hold a hidden bias against creativity that activates when they feel uncertain — and, crucially, that this bias impairs their ability to recognise a good creative idea even when they are actively looking for one (Mueller, Melwani & Goncalo, 2012). A live AI demo is a maximally uncertain stimulus. So the room that says it wants innovation and then reaches for “not production-ready” is not necessarily being cynical. Under uncertainty, that is the predictable human response. The fix is to reduce the uncertainty, not to win the argument.

The tooling-attribution dismissal. A newer variant, specific to this moment : “You only built this because AI made it easy.” The implication is that the capability is cheap and therefore unserious. It is worth noticing that this is the provenance attack wearing a 2026 coat — it relocates the credit from the builder to the tool, which is just another way of not engaging with what was shown. Though, I should admit that I invite the ‘unserious’ label as my style is to work extremely hard to synthesise complex systems into simple explanations and visuals — a double-edged skill learned during my time as a telecommunications systems instructor and a learning developer.

The proxy attack. This one is subtler. If a written proposal is thorough enough that it is hard to attack directly, the sceptic will find the weakest-looking surface instead and attack that. The demo is usually that surface. In my case the dismissals almost never landed on my written proposals — they landed on the scrappy demo, because the demo looked attackable. So the dismissal was not really about the demo. It was about the proposal the demo supported, redirected onto an easier target.

What these have in common is that none of them engage with the capability being demonstrated. They are all ways of stopping the conversation without having it.

The role layer #

The dismissal layer goes after the artifact. This next set of moves goes after you — your standing to be in the room, and your willingness to keep going.

The role-legitimacy challenge. “Who are you? Your title is Learning Program Manager, but you’re asking about things well outside that role.” This is the stay-in-your-lane move, and it is the most personal of the lot. What I have found that works is to answer it lightly — a quick, jovial nod to my earlier background as a technician and technologist, and a mention that a sponsor asked me to look at the problem. That usually gets the conversation moving again. What it does not do is tell me what was actually being asked : was it about seniority, authority, my level in the org, or just territory? I rarely find out.

Edwin Hollander’s old idea of idiosyncrasy credit explains both the challenge and why the workaround works. Hollander showed that a group extends you a kind of running balance of credit — earned through demonstrated competence and through being liked — and only once you have banked enough are you permitted to deviate from what the group expects of your role (Hollander, 1958). A title is shorthand for how much credit the group thinks you should have. Asking about things “outside your role” spends credit you may not visibly have yet. Naming my technical background and the sponsor’s request is, in effect, a fast deposit — competence plus borrowed authority — before I overdraw. The durable fix is the same as tactic seven below : build a visible track record so the credit is already in the account before the question gets asked.

The pre-emptive discouragement. A quieter one : people who spend real energy convincing you the solution will probably never happen, so there is no point putting serious planning, effort, or resources behind it. It can sound like realism, even like kindness. But notice what it is doing — it lowers your investment before anyone has evaluated the idea on its merits. Sometimes it is genuine context-sharing. Often it is an antibody response (Blank, 2019) : discouraging the effort is cheaper than engaging with it. The reframe I use : treat the prediction as information about their certainty and incentives, not mine. If the only argument against pursuing something is that it probably will not survive the org, that may unintentionally be a statement about the org, not about the idea.

The capture layer #

Dismissal is one pattern. Capture is another, and in some ways it is harder to navigate, because it starts with agreement.

IT capture looks like governance. The approved path for building AI solutions leads through a centralised process — in practice, into a specific cloud infrastructure controlled by the IT department. The stated rationale is security, compliance, and scalability. All of those are real. The effect, however, is that concepts built elsewhere get absorbed into IT’s roadmap, the original builders get sidelined, and the credit follows the infrastructure. The intake process is not always an innovation and assurance channel ; it can turn into an innovation funnel into a different team’s portfolio, discarding the original thinker once they are squeezed of their innovative juices.

L&D capture looks like support. A grassroots community of AI practitioners is artificially formed. The internal learning-and-development function — well-intentioned, doing exactly what it is meant to do — moves to coordinate and formalise the skills, knowledge, and practices. From there it becomes a program with a curriculum, a sponsor, and an enrolment process. The energy that made it interesting drains out. What started as builders sharing cool new approaches with others willing to try them out is turned into a stale curriculum of what worked six months ago, and becomes a foundations course that everyone has to take.

Lateral capture looks like collaboration. This is the one I underestimated. A peer team — often a sister business unit’s learning or product group — engages with your concept, then spends the working session steadily reframing it toward something they want to own, and quietly manoeuvres with the leaders above you to position your direction as the risky one. You think you are co-designing. They are re-pointing the work. You can walk into the last day of a workshop with a detailed proposal nearly ready to submit — that you had worked all night on — and you walk out having spent the final day helping produce a single weak slide in someone else’s grand vision with no clear direction — because they wanted to pivot into a direction that gave them control.

Sponsor capture. A senior leader sees the work, gets excited, and takes it on as their team’s project. That is the best version : the concept gets resources and air cover. The harder version is that it also gets a new owner, a new direction, and a new set of constraints, and the builder becomes a contributor to someone else’s initiative. Credit is the first thing to drift, scope is usually next. Another version of this is senior leaders not displaying interest and only fully buying in after other senior leaders show interest — and then quietly rewriting history into “I always supported this concept.”

None of these are necessarily malicious. Organisational research frames the underlying driver clearly : people develop psychological ownership over intangible things like ideas and goals, and that ownership produces territoriality — defending, marking, and withholding (Brown, Lawrence & Robinson, 2005). Capture is territoriality expressed as enthusiasm. The problem is that absorption is not the same as adoption, and standardisation is not the same as progress.

The structural layer #

Underneath the dismissals and the capture mechanisms is a structural problem that makes all of them worse : most large organisations do not have a real intake path for internally generated AI innovation.

What they have instead is a patchwork. IT has a cloud platform and a process for using it, but a convoluted intake process where path-finders and explorers are weeded out. One VP has budget for a small AI team. Another has found a strong builder on her team and carved out time. A third is running a pilot that may or may not connect to anything else. None of these efforts coordinate. None share infrastructure, tooling, or learnings. They compete for executive attention, because that is the only resource they share.

Steve Blank has a name for the visible version of this : innovation theater — hackathons, innovation labs, and intake forms that produce lanyards and activity but little that moves the business, while the real operating units quietly ignore the output. He also names the force that kills the substance underneath the theater : innovation antibodies, the departments and processes that treat every new idea as a risk to be managed rather than a possibility to be tested (Blank, 2019). A “false intake path” is innovation theater with a capture mechanism bolted on : it performs openness to innovation while functioning as a routing layer into an existing team’s empire.

The result is balkanisation — multiple small efforts running in parallel, none strong enough to be the institutional answer, each protective of its own territory. Air time becomes the scarce resource everyone optimises for, instead of actual outcomes.

In that environment, a builder with a strong proof of concept is not presenting to an audience evaluating ideas on their merits. They are presenting into a political economy where every new idea is also a potential threat to someone’s headcount, roadmap, or claim to relevance. That is why the same demo can get an enthusiastic response from half the room and a deflection from the other half.

The shape-shifter’s double bind #

There is one more challenge, and it is less about how others receive the work than about what the work demands of you.

To get a concept moving, I have to bring it to very different teams — program, product, UX, front-end, back-end — each with its own composition, strengths, and preferences. None of them starts from a blank page. So I do the priming : enough program framing, enough design, enough working front-end or back-end to prove the thing is possible and give each team a place to stand. This is boundary spanning in the literal sense Tushman and Scanlan described — one person carrying information and possibility across the seams between units, which is exactly where innovation tends to stall and where communication is most prone to distortion (Tushman & Scanlan, 1981).

The bind is that the priming has to land in a narrow band. Do too little, and the specialist team “shuts down” — the input was not in the form they are used to, so nothing starts. Do too much, and I have stepped onto their craft, and the feedback turns to “this isn’t to our standard.” That second reaction is territoriality again (Brown, Lawrence & Robinson, 2005) — the specialist defending the boundary of their work. So I am expected to produce something concrete enough to react to, and penalised for having produced it with the ‘wrong’ hands or without the formal ‘credentials’ required. There is no position in that band that is fully safe from criticism, which is worth naming plainly : the criticism is structural, not a verdict on the work or on you.

What actually helps #

Now, the practical part. These are tactics I have tested or am considering trying across demos, proposals, and informal conversations. Where I can, I have tied each one to why it should work, not just that it worked for me.

1. Pre-empt the deflection before they can use it.

Open the demo by naming what the artifact is and is not : “What I am about to show is a proof of concept. It is not a production build, and it is not a proposal for one. The question I want to explore is whether this capability is worth pursuing, and what it would take to get there.”

This removes the “not production-ready” line of attack by saying it first, and it reframes the question from “is this done?” to “is this directionally right?”. It is also doing something the research points to directly : if uncertainty is what triggers the bias against creativity (Mueller, Melwani & Goncalo, 2012), then naming the boundaries of the artifact lowers the uncertainty in the room, which is the actual lever.

2. Shift the closing question.

Instead of ending with “what do you think?”, end with “what would need to be true for this to be worth pursuing?”. The first invites a verdict. The second forces the sceptic to articulate a condition, which is a far more productive place to negotiate from. It also lowers the interpersonal cost of engaging honestly — which is the core of what Amy Edmondson calls psychological safety, the shared belief that you can raise a question or a doubt without it being held against you (Edmondson, 1999). A room that feels safe to name conditions will engage with substance ; a room that does not will reach for the safe deflection.

3. Do not present alone if you can avoid it.

The “bedroom project” framing collapses when a second credible voice is in the room. That voice does not need to be senior — a peer from engineering, product, or design who has looked at the work and can speak to what a real build path involves is enough. This is the boundary-object idea in action : a prototype that two functions have already engaged with is no longer one person’s artifact, it is a shared reference point. The moment it is not just Bil’s thing, the provenance attack loses most of its force.

4. Do the research, and build documentation with real technical accuracy.

You do not need years of seniority to earn a place in the conversation. You need to have done the work. Spending focused time to research a domain, gather the relevant details, and build documentation that is technically accurate — or to put together a reasonable working model of how something would function — does more to establish standing than any title. The goal is not to write the definitive text in a field you are not fully versed in. It is to get a credible, accurate-enough grasp of the facts that engineering, legal, InfoSec, and the other gatekeepers will care about, and to write it down clearly.

This does two things the research points to. First, it pre-empts the procedural deflections directly : when someone reaches for “this still needs to go through InfoSec and legal,” a builder who already has a documented first-pass on data handling, threat surface, and compliance touchpoints has changed the conversation from “you haven’t thought about this” to “here are my readings — where am I wrong?”. Second, it lowers the uncertainty in the room, which is the actual lever on the bias against creativity (Mueller, Melwani & Goncalo, 2012). Accurate documentation is also the clearest way to bank competence credit before you need to spend it — the alpha value in Hollander’s idiosyncrasy-credit model (Hollander, 1958). Modern tools make this far more achievable for one person than it used to be ; the constraint is no longer access to information, it is the discipline to verify it and write it down honestly.

5. Protect the concept through obscurity early.

The best time to absorb a concept is before it has its own identity and momentum. An idea announced before it is real is easy to redirect ; an idea that already has a small working group, a few concrete outputs, and a shared vocabulary is much harder to absorb cleanly.

This is not just my instinct — it is a documented strategy. Miller and Wedell-Wedellsborg make the case for stealth innovation : developing an idea quietly, out of the line of fire, until it is robust enough to survive contact with the organisation (Miller & Wedell-Wedellsborg, HBR 2013). The organisational-behaviour literature goes further : Mainemelis’s award-winning work on creative deviance describes exactly the move of continuing to develop an idea after it has been told to stop, and shows that ideas developed out of sight are less subject to the conformity pressures and biases that kill novel ideas early (Mainemelis, 2010). The implication : do not socialise a concept widely until it has enough shape to defend itself.

6. Find the champion who understands the structural problem, not just the demo.

An enthusiastic VP who likes the demo is useful. A VP who understands why the intake path is broken and has the appetite to say so in a room is a different kind of useful. The first gives the idea air cover ; the second changes the conditions the idea operates in. Howell and Higgins, in their study of innovation champions, found that effective champions do not just cheerlead — they articulate a clear vision, deploy a wide range of influence tactics, and crucially work the political process : securing top-level backing, building peer support, and sometimes pushing ideas through without formal approval (Howell & Higgins, 1990). If you can find a champion who operates at that level, invest in the relationship.

7. Build in public, inside the organisation.

The most durable protection for a concept is a visible track record : working sessions, documented experiments, posts like this one, a consistent practice of showing work as it develops. It is slower than a single demo, but it builds something a demo cannot — a pattern of credibility that is hard to dismiss with one line about bedrooms. It is also the direct counter to NIH-style provenance attacks (Katz & Allen, 1982) : a documented body of work establishes a legitimate provenance of its own. It is, in idiosyncrasy-credit terms, how you keep a positive balance in the account before anyone asks who you are.

8. Prime just enough, then hand the craft back deliberately.

The shape-shifter’s double bind has no perfectly safe position, but it has a better one : produce the smallest artifact that makes the possibility legible — a rough prototype, a one-page flow, a thin slice of working code — and present it explicitly as a starting point for them, not a finished example of their craft. Something like : “This is a scrappy version to react to. The real build is yours, and you will do it better than this.” That framing does two things at once. It gives the team the concrete object they need before they will engage — the prototype doing its job as a boundary object — and it pre-emptively returns ownership of the craft, which lowers the territorial response (Brown, Lawrence & Robinson, 2005). You spend a little credit to start, and deposit some straight back by naming their expertise.

Risk or limitation #

A few honest caveats.

These tactics assume a builder with some standing and some runway. If the political environment is actively hostile rather than just resistant, some of them will not be enough. There are organisations where the intake path is not just broken but deliberately protective or cannibalising, and where the right answer may be to find a different environment.

The capture mechanisms are also not always bad. Sometimes the right outcome is for a concept to be absorbed by a better-resourced team that can actually build it. The thing worth protecting is credit and influence over direction — not necessarily ownership of the execution.

And the research I have cited describes tendencies, not laws. NIH, the bias against creativity, territoriality, innovation theater — these are well-evidenced patterns, but they are probabilistic. Plenty of rooms engage in good faith. The point of naming the patterns is not to assume the worst of everyone ; it is to stop assuming the problem is you.

The structural diagnosis here — balkanisation, false intake paths, competitive air time — is my read of my context. It is recognisable to others I have talked to. It is not universal.

Next step #

I am planning to run a small, informal session with a handful of folks I know who are trying to build with AI. The goal is not to build a coalition or formalise a community — it is to test whether the patterns I have named here resonate with people in similar positions, and to learn what they have found that works. Delivering what I think I have learned is also the fastest way to find out where I am wrong.

If the session is useful, I will write a follow-up about what came out of it. For now, this post is the artifact I want to start that conversation with.