At the Autonomous Summit, Walmart's SVP Dave Glick said something that stopped the room:
"The myth is that it's hard."
Walmart trained thousands of business users to build their own agents. Not because engineering couldn't do it. Because engineering shouldn't have to.
When the customer and the engineer are the same person, requirements docs become irrelevant. Backlogs disappear. The person who feels the pain builds the fix.
PERMISION THE BOTTLENECK
It's not a technology problem. It's who's allowed to build.
THE PERMISSION PROBLEM
Most enterprises are treating AI like a technology problem. Build the platform. Train the models. Deploy the tools.
But the companies actually seeing results are treating it like a permission problem. Who's allowed to build? Who's allowed to experiment? Who's allowed to ship?
One of Dave's team members, who hadn't written code in 10 years, built a SaaS product in a weekend. His reaction: "This isn't overhyped. It's underhyped."
"When the customer and the engineer are the same person, they get what they know they wanted." - Dave Glick, SVP Enterprise Business Services, Walmart
THE RESULTS
115x faster ideation. What took 5 days now takes 1 hour.
Trend-to-factory cut by 18 weeks. An agentic system spots trends, designs products, and ships tech packs directly to manufacturing.
That's not automation. That's a different way of working.
THE JANUARY ARC
Three weeks ago I asked: Are you in the 6%?
Now you know what the 6% actually did:
Week 1: The gap is real. 6% vs 94%.
Week 2: You're seeing signals too late. The timing tax.
Week 3: Your best people are buried in work that should be automated. The bandwidth tax.
Week 4: The answer isn't better AI. It's who's allowed to build. The permission problem.
The 6% didn't just add AI. They redesigned who gets to build.
THE PERMISSION CHECK
■ Who in your org is allowed to build and ship without committee approval?
■ How many requests are sitting in an engineering backlog because they're "not big enough"?
■ What's the distance between the person who feels the problem and the person who can fix it?
■ Are your business users trained to build, or just trained to request?
If the answer to every problem is "ask engineering or IT," you have a permission problem, not a technology problem.
WHAT TO DO THIS WEEK
Find someone in your org who isn't technical but has a problem worth solving.
Ask them: "If you could build anything to fix this, what would it be?"
Then ask: "What's stopping you from building it yourself?"
The answer tells you whether you have a technology problem or a permission problem.
FROM THE PORTFOLIO
This is what BOI (Board of Innovation) builds. Not AI implementations. Permission structures. Operating models where innovation, marketing, and sales work as one system, where insights flow to action without waiting for the next planning cycle. The Walmart engine didn't just speed up ideation. It changed who's allowed to build. Learn more →
At HauerX Holdings, we're on a mission to make AI-native growth the standard for every enterprise.
If any of this resonated, or you have ideas for partnering, I'd love to hear from you.
Talk Tuesday,
Jason Hauer
CEO, HauerX Holdings
jason@hauerX.com
Jason Hauer is the founder and CEO of HauerX Holdings, where he backs and builds a portfolio of AI-native companies that accelerate how businesses grow, operate, and compete. From mid-market to Fortune 500.
Frequently Asked Questions
Why is AI transformation a permission problem, not a technology problem?
Most enterprises are treating AI like a technology problem. Build the platform. Train the models. Deploy the tools. The companies actually seeing results are treating it like a permission problem: who's allowed to build, who's allowed to experiment, who's allowed to ship. The bottleneck isn't capability. It's who's authorized to act on the capability. The approval chain that protected you in 2015 is the bottleneck crushing you in 2026.
What did Walmart do to remove the AI permission bottleneck?
Walmart trained thousands of business users to build their own agents. Not because engineering couldn't do it. Because engineering shouldn't have to. When the customer and the engineer are the same person, requirements docs become irrelevant. Backlogs disappear. The person who feels the pain builds the fix. The results: 115x faster ideation. Trend-to-factory cycle cut by 18 weeks. That's not automation. That's a different way of working.
What's the difference between AI guardrails and AI speed bumps?
Guardrails are clear rules about what can be built without escalation: low-risk use cases, internal tools, prototypes. Inside those guardrails, teams move fast. Speed bumps make every team go through full review regardless of risk. Guardrails enable speed because the rules of engagement are clear. Speed bumps slow everyone down equally. Most companies are building speed bumps and calling it governance.
How do you tell if you have a permission problem in your organization?
Four checks. Who in your org is allowed to build and ship without committee approval? How many requests are sitting in an engineering backlog because they're "not big enough"? What's the distance between the person who feels the problem and the person who can fix it? Are your business users trained to build, or just trained to request? If the answer to every problem is "ask engineering or IT," you have a permission problem, not a technology problem.
What changes when business users are trained to build instead of trained to request?
When the customer and the engineer are the same person, they get what they know they wanted. Requirements docs become irrelevant. Engineering backlogs disappear. One Walmart team member who hadn't written code in 10 years built a SaaS product in a weekend. His reaction: "This isn't overhyped. It's underhyped." The 6% didn't just add AI. They redesigned who gets to build.
