My first cubicle at the Chicago Tribune sat under a staircase that, by the account of everyone who’d been there longer than me, wasn’t supposed to exist. Newspapers kept editorial and advertising on separate floors on purpose, with an elevator between them nobody had much reason to ride. Years before I arrived a publisher had a set of stairs cut straight through the floor, sales to newsroom, no memo, no reorg.
At the time, I was a Digital Sales Manager, and I climbed those stairs constantly for no reason except that I could. Standing at the top to watch how the newsroom actually worked. I would never have pressed 3 in the lobby elevator. It wasn’t forbidden, it just wasn’t mine, and an elevator asks you to declare a destination. The staircase asked nothing. That publisher was long gone before I ever used his stairs, but he’d understood something the org chart didn’t: the information a company needs to run itself lives across the floors, and it only moves when the building makes moving cheap.
I have some version of the same conversation every week.
A CEO tells me about the AI hire they made. Sharp person. Knows the tools. The leadership team trusts them. There’s a Slack channel now, maybe a pilot or two.
Then I ask which workflow changed. Not which tool got licensed. Which workflow? Who in the building does their Tuesday differently than they did in March?
The pause that follows is the whole story.
IBM’s 2026 CEO study surveyed 2,000 CEOs and found that 76% of their organizations have a Chief AI Officer, up from 26% a year earlier. Those same CEOs estimate that only 25% of their workforce uses AI regularly as part of the job. The leadership roles are multiplying faster than daily work is changing.
Often, nobody hired a bad person. They hired someone who knows AI for a job that also requires knowing the company. And knowing the company takes more than reading the org chart. It takes relationships.
Three hires, one blind spot
The first AI hires I see tend to fall into three profiles. Each can run into a different version of the same problem.
The Technical Lead. A CTO type. Knows the tools cold. Executives trust them. But they may never see what the junior FP&A employee does between 2 and 4 on a Thursday, and they may not volunteer it to someone three floors up.
The Super User. The person who showed their manager a clever AI solution they built and got a title for it. They know their own workflow, but may have no standing to walk into the CFO’s office and ask why month-end takes nine days.
The Builder. Loves the tools, knows the backend, builds for the joy of it. Takes a requirement without seeing the workflow behind it, then ships something impressive that misses. The organization ends up with an elaborate demo of a problem nobody actually had.
These are generalizations, but I see the pattern weekly. It isn’t a skills problem. It’s a reach problem. One struggles to get to the floor, one to the executives, one to the workflow. The knowledge that makes AI useful lives at a desk, not in a strategy.
The requirement comes out when people trust you
I wrote last month about why building got cheap and why that made the operator’s knowledge of exceptions the scarce input. This piece is about what happens next: someone has to collect that knowledge, and it rarely arrives through a ticket.
It lives with a salesperson who has a good idea and no one to tell. It lives with an admin who spends six hours a week bridging two systems that were never meant to talk. And it surfaces when an employee feels safe enough to say that the process is broken and they’ve been working around it for two years.
You can’t gather all of that with an intake form. You have to be someone people are willing to complain to.
A month ago, a client mentioned, in the middle of a meeting about something else, that invoicing was painful. They invoice through QuickBooks, a customer pays half up front, then they chase the balance after delivery, and every step is a separate trip into a separate screen.
That sentence wouldn’t have reached a requirements doc. It wasn’t a request. It was a complaint, said to someone they’d worked with long enough to complain to. In a formal intake process, I might never have heard it.
Two days later, an invoicing module was live inside their instance. Deal to order to invoice, with deposit and balance built in. Reminders go to them rather than firing at the customer. Secure payments through a processor integration are the next step, and it’s shipping this week.
The build was the easy part. The hard part, the part no job description covers, was being in the room where the workflow complaint was surfaced.
Handoffs before tools
Once you see the pattern, the method is straightforward.
Sit with the person. Watch them work. Capture the workaround, because that’s often the requirement nobody wrote down. Then find the handoff: the moment their output becomes someone else’s input. That’s where the real loss often happens.
Do that across enough desks and something else shows up. The admin’s problem connects to marketing’s problem. Marketing’s handoff to sales resembles the one sales has with account management, and the one account management has with project delivery.
Every Friday, I publish The AI Operator’s Brief. It’s a one-page dispatch on what actually happens when AI meets real-world business applications.
You get the signal on what moved, what we’re seeing in the field, and one tactical thing you can build by Monday. No code required.
In practice, a systems thinker asks about handoffs before asking about tools. They can see the company as a set of connected queues instead of a set of departments. The three profiles can all learn to do this. But no one can map the handoffs of a building they can only reach a third of.
Building it is only half the job
None of this matters if the thing ships as a prototype and stays one.
The hire has to work with your dev team and within your security requirements. In my case, the systems we build have separate database, keys and logins. The AI can prepare a change to the system, but a human has to confirm before that change is executed. Security shapes the design from the start.
So the profile I’m looking for is someone who has spent years inside organizations and across functions, used the standard software stack firsthand, earned trust with frontline staff and executives, and can ship something people actually use. That’s a hard person to find with a job title. It’s a nightmare for the HR leader who’s been told to make the first AI hire and get it right.
What to screen for
If you can’t find that person by title, screen for the behaviors.
Has lived inside multiple department stacks. Not just managed them. Used them daily, and resented them.
Can earn trust with frontline staff and executives. The executive meeting is scheduled. The clerk’s real story has to be earned.
Asks about handoffs before asking about tools. Their first questions tell you what they see.
Builds trust faster than features. Ask for references from the people whose work they changed.
Can explain the same solution to a CFO and an AR clerk in one afternoon. Same build, two languages.
Measures adoption, not just deployments. Ask what they count. Licenses alone are the wrong answer.
Knows how to sell an idea. Good salespeople listen, build relationships and solve problems for someone else. In this job, that person may be two desks over.
Can ship, and can show you something someone else uses. A slide about a prototype doesn’t count. Neither does a build with no security story attached.
The takeaway
Go back to the hire you already made.
If it’s the Technical Lead, give them a partner who knows the frontline and a mandate to spend time there. If it’s the Super User, give them an executive sponsor and a rotation through other departments before you hand them a roadmap. If it’s the Builder, stop handing them requirements and give them a chair next to the person who wrote them.
Give your AI hire a way onto every floor. Then hold them accountable for what changes after the build ships.
Your AI budget buys capability: tools, licenses, models. The right hire turns that capability into adoption.
And adoption has always been a networking job. You just used to call it sales.