I still remember the first time I deleted more code than I wrote in a day and felt like I'd done my best work in years.
For most of my career, the instinct was the opposite. A problem showed up, I reached for the keyboard, and I built my way out of it. Engineers earn their confidence that way. You learn that almost anything can be fixed if you understand the system deeply enough and you're willing to go in and change it. That instinct made me useful for a long time. It also nearly led me astray when I started rebuilding companies around AI, because the hardest problems I ran into could not be solved at the keyboard at all.
The technology was never the hard part
When I began building AI-native companies in earnest, through iii.partners and ventures like Priiism, SettleWise, and Agent Hub, I expected the difficulty to live where it always had: in the technology. Get the models right, wire up the data, design the agents, ship. The engineering was real work, but it was tractable. It behaved. You could test it, watch it fail, and improve it.
What did not behave was everything around the technology. Who is allowed to make this decision now that a system can make it faster? What happens to the manager whose job was to be the bottleneck that caught mistakes? Whose name is on the outcome when an agent acts and is wrong? Those are not engineering questions. They are questions about decision rights, accountability, and trust, and no amount of clean code answers them.
I learned this the expensive way. We built capable systems that simply did not get used, or got used once and quietly abandoned, because the organization around them had not changed to let them work. The software was ready. The operating model was not. I had been treating AI as a tool problem when it was an operating-model problem the whole time.
That reframing is the single most important thing I have learned, and it is why I now spend more time with leadership teams than with codebases.
You cannot delegate this to IT, and you cannot delegate it to a vendor
The most common mistake I see CEOs make is treating AI as a procurement decision. Stand up a task force, give it to the technology function, ask for a roadmap, wait for a demo. It feels responsible. It is actually an abdication.
AI does not slot neatly into the org chart, because it cuts across the lines the org chart is built on. It changes how decisions get made, how fast, by whom, and with what evidence. Those are the CEO's questions. They are about how the company actually operates, where authority sits, and what the institution is willing to be accountable for. A technology leader can build the capability. Only the executive team can decide what the company becomes once it has that capability.
I have watched brilliant technical teams stall, not for lack of skill, but because no one above them had made the calls that would let the work matter. The model could draft the contract, score the lead, estimate the project, route the case. But nobody had decided whether it was allowed to, who would own the result, and what the human was now responsible for instead. Without those decisions, the smartest system in the building is just an expensive demo.
That is when I stopped thinking of my job as building the system and started thinking of it as helping leaders make the calls the system forces them to make.
What I changed my mind about
I used to believe that if you built something good enough, adoption would follow. Make it fast, make it accurate, make it obviously better, and resistance melts. I was wrong, and being wrong about it cost me time and credibility I would like back.
People do not resist better tools. They resist ambiguity about their standing. When a capable system shows up and no one has been clear about what it means for a person's role, their judgment, and their accountability, the rational response is to be wary of it. The resistance I kept running into was not ignorance or stubbornness. It was a reasonable reaction to a vacuum of executive clarity.
So the work moved upstream. Before you build, you have to be honest about what the system is for, what it will change, and what stays firmly human. The scarce asset in all of this turned out not to be code, or even talent. It is clarity at the top and the trust that clarity earns. When leadership is clear and consistent about where AI fits and where human responsibility remains, adoption stops being a fight. When it isn't, no architecture saves you.
Software stopped being software
The other shift was harder to see because it crept up on me through the building itself.
I started out building applications: static things, with screens and buttons and workflows a person clicks through. Somewhere along the way, what I was building stopped looking like applications. With Agent Hub especially, the thing taking shape was less a piece of software and more an organization made of agents, workflows, data, and decisions that adapts to what is in front of it. It senses, it decides, it acts. It has to be governed more like a team than a tool.
That changes the executive's job in a way most haven't internalized yet. If your software is becoming an adaptive organization, then designing it is organizational design, and governing it is leadership. The right question is no longer "what features do we want." It is "what is this organization of humans and agents accountable for, and how do we make sure judgment and responsibility stay amplified rather than erased." The goal was never to remove people from the loop. It was to put human judgment where it matters most and give it more leverage than it ever had.
Why I still build
I could have made the move to advising cleanly and never written another line. Plenty of people do. I decided early that I would not, and I hold to it.
You cannot teach this from the sidelines. The lessons that matter to a CEO making a real capital-allocation decision about AI are not the ones you read about. They are the ones that cost you something. The campaign that sent nothing because of a setting no one questioned. The pipeline that looked alive and was dead. The capable system everyone praised and no one used. I know these failures because I have shipped them, found them, and fixed them, often at my own expense.
That is also why the advice lands differently. When I sit with an executive team now, I am not theorizing about transformation. I am still in it, this week, in my own companies. I have made the mistakes I am warning them away from, recently enough that the lessons are still sore. Building keeps me honest, and it keeps me useful.
What the rebuilding taught me
The arc from engineer to advisor was not a step away from the work. It was a step toward the part of the work that actually determines whether any of it succeeds.
The technology will keep getting better, faster than most boards expect. That is not the constraint. The constraint is whether leaders can be clear about decision rights, honest about accountability, and willing to redesign how their companies operate rather than bolting AI onto how they already run. The ones who do will compound an advantage that no tool can sell you. The ones who wait for IT to hand them a finished answer will keep wondering why their demos never became durable.
I moved from writing the code to helping leaders make the calls because that is where the real leverage turned out to be. This is the work I do with leadership teams now.