There's a song in Hamilton about a deal struck behind a closed door, and about the man standing outside who will never learn how it happened.
He doesn't want the deal undone. He wants to be in the room. That's the whole ache of it. Somewhere, people are deciding. You are not there, and nobody will tell you what it took to get in.
Every company has that room. Most of them can't tell you where it is.
Here's mine. At one employer, my client groups ran their work in Jira. I sat in their meetings. I was part of the work being tracked in it.
I asked for access. I wanted to understand how the business I supported actually ran, and I thought our own team could work better if I understood it. I was willing to learn the system myself to get there.
The answer was no. My leadership team didn't understand the software well enough to feel comfortable approving it. Here is the part you have probably already guessed: they never went and found out. No research, no conversation with the teams already using it every day.
I think about that a lot right now.
There's an argument making the rounds that building software for your own work has become a foundational knowledge-worker skill. The idea is that you build the small things that make your actual job work: the tracker, the dashboard, the thing that turns a Friday export into a report nobody has to assemble by hand. Nobody is suggesting you become your company's software engineer.
The evidence is hard to wave off. Per OpenAI enterprise research reported on The AI Daily Brief, enterprise Codex usage since February grew 5× in engineering and 108× in legal. The most cautious function in the building is moving twenty times faster than the one that writes code for a living. Over the same stretch, the top ten percent of enterprise AI users went from consuming 2.6× more AI than average firms to 8.3× more. The distance is opening.
I agreed with all of it. My very next thought was that not every employer is ready for this.
If someone can build a solution in a day and it still takes four months and a hundred questions to get it implemented, all we have really handed them is a new way to be frustrated.
The barrier was never technical
The reasons people haven't started are worth sitting with. They think they aren't "a technical person." They're afraid of breaking something they can't fix. Or they tried once, hit a terminal window or a tutorial building something irrelevant to their job, and quietly closed the laptop.
Every one of those is a people problem. They are questions of professional identity, psychological safety, and training design. HR owns all three.
The opportunity in that is bigger than it sounds. An HR business partner is already the person closest to the business. An HRBP who can also build the thing that solves the people problem becomes valuable to that business immediately, without waiting for a transformation initiative to make it official.
That shift is one of identity rather than training. It moves a person from this is the work I do to this is the impact I add.
But nobody arrives at that self-concept alone
Here's the part I'd want an owner to hear, because it's the part that's actually in your control.
People don't decide on their own that they aren't builders. They learn it from how long things take, from how many people have to say yes, and from what happened the last time they raised their hand.
Governance is the right stakeholders getting a real opportunity to review, ask questions, and give input. That is the job, and it is worth the time it takes.
Dysfunction is a road show to multiple VPs of HR, every one of whom believes they hold a veto. Dysfunction is a job description taking over a year to update, so the new version is already out of date the day it publishes. If that's happening in your company, the problem is that nobody has said out loud who actually decides.
That is the room, and that is the dark. Nobody has to act with malice. A decision simply gets made somewhere the person waiting on it cannot see, by people they cannot name.
Do that to someone enough times and you don't have to block them anymore. They stop asking. And then, years later, when the tools finally arrive and someone tells them to go build something, they say oh, I'm not really a technical person, and everyone treats it like a personality trait instead of a thing the company taught them.
Not all autonomy is the same, and we hand out the wrong kind
Go back to that number for a moment. In January, the top ten percent of enterprise AI users consumed 2.6 times as much AI as an average firm. By the summer it was 8.3 times. The distance between companies is opening, and it is opening along the line of who lets people build.
Here is the part I find hard to argue with. There is a large meta-analysis of work design, covering 259 studies and more than 219,000 people, that separates autonomy into three kinds: control over your schedule, control over your methods, and control over your decisions. The three do not perform the same. Control over scheduling shows no reliable relationship with job satisfaction at all. Control over methods matters considerably more. Control over decisions correlates with job satisfaction at roughly .58, which in this field is an unusually strong result.
The same analysis found autonomy was the only motivational job characteristic with a measurable link to objective performance, not self-reported performance but the kind you can count. It also ran strongly against burnout. Meanwhile Gallup's 2026 report puts global engagement at 20 percent, the lowest since 2020, with managers accounting for most of the decline.
I resigned a few weeks after that Jira conversation. My skip level manager was curious about why.
I had given plenty of signals before that, and each one was met with inaction. Somewhere in there I remember wondering what the plan for me actually was. If I wasn't going to be allowed to do the work I believed would help, and nobody was going to help me find work that would, was I supposed to sit there and rot?
Disengagement rarely announces itself as a survey score. It looks like a person who tried, got told no by someone who never looked into it, and quietly started counting.
So the two things you want turn out to be the same thing. The AI gains and the engagement sit behind the same door. People who are trusted to decide build more, and people who get to build stay interested in the work. You do not have to choose between the productivity story and the people story, which is fortunate, because most owners cannot afford to.
What to do Monday morning
Push your HR partner. Two questions, and don't accept a soft answer to either:
What people problems do we have right now that we could build a solution for?
And what, specifically, is getting in the way of us building it?
The second question is the one that matters, because you are asking someone to describe the room. You want to know who decides, on what basis, and how long it takes. Most companies cannot answer that, and the silence itself tells you something.
If what's in the way is a real risk, then you've found something worth governing. If what's in the way is that nobody knows who'd approve it, you've found the bottleneck, and it was never the technology.
That conversation costs you twenty minutes. Skipping it costs you the difference between a team that builds and a team that waits.