Find Your Builders. Or They'll Leave and Start Without You.
Part 1 made the case for urgency. This part is about who you put in charge of it, and why most companies get that decision backwards.
Stephen Messer, Co-founder of Collective[i] and LinkShare (sold to Rakuten for $425M, 1996–2005). Entrepreneur of the Year. Board member, Spire Global (NYSE: SPIR). Building intelligence.com
Find Your Builders. Or They'll Leave and Start Without You.
Part 1 made the case for urgency. This part is about who you put in charge of it, and why most companies get that decision backwards.
I get the same call constantly. A CEO wants me in front of their board. Or the ask lands as a WhatsApp DM at some odd hour from someone in my network. The message is always a version of the same thing. We are struggling to get our teams to move on AI, and when we do move, it is too slow, and we never really get results. Is this us, or is this AI?
I hate answering it, because the answer is always the same and it is never the one anyone wants. It's you. More precisely, it's the person you chose to run the AI transformation.
By the end of the meeting, or the call, the light bulb usually goes on. Luckily, once it does, the changes work.
I would like fewer of these calls. So consider this a mitzvah, a Hebrew word for a good deed, done because it is the right thing to do, not for credit, with a side benefit for me. The good deed is saving your board a year of drift. The side benefit is my WhatsApp.
I'm best known for LinkShare, Collective[i], Intelligence.com, and a board seat at Spire, but over thirty years I've been an investor or operator in more than eighty companies. The pattern repeats with almost comic precision, in almost every one of them. The tools are available. The budget is there. The leadership team has said the right things about AI in every all-hands for two years. And nothing has fundamentally changed.
The reason is almost always the same. The wrong people are controlling the pace, and the right people are sitting two or three levels below the meeting where that decision gets made.
Geoffrey Moore saw this coming thirty years ago.
In 1991, Geoffrey Moore published Crossing the Chasm, one of the most useful frameworks ever written about how new technology moves through organizations. Most people who know the title confuse it with Clayton Christensen's The Innovator's Dilemma, which came out four years later and asks a different question: why great companies get blindsided by cheaper, worse technology that eventually wins. Moore was not writing about that. He was writing about the gap inside adoption itself. Between the early adopters, who embrace new technology because they see its potential, and the early majority, who embrace it only when they can see proven, low-risk implementations from people they trust.
Geoffrey is a friend and an advisor to Collective[i], and I've had the benefit of hearing him defend and extend this framework for years past the point where most people stop reading. Most readers take Crossing the Chasm as a book about markets. When to launch, who buys first, how a product crosses the gap between early customers and the mainstream. That is the shallow read. The deeper one is an internal guide to matching the right person to the right job at the right moment in a company's life. The early majority manager is not a bad hire. They are the wrong hire for this particular job, at this particular moment, which is exactly the mistake almost every company making an AI push is currently making.
The group Moore called the “early majority,” the practical, pragmatic managers who dominate most organizations, are not obstructionists. They are doing their jobs. They manage risk. They require evidence. They want to see something work before they commit. In a stable environment, these are exactly the qualities you want in the people running your operations.
In a disruption, they become the organization's anchor.
Moore's early majority person does not kill new ideas. They do something more professionally dangerous. They manage them. They want the pilot. They want the benchmark study. They want the use case that looks exactly like the current workflow so the transition feels safe. They want the AI system explained in the language of the process it should be eliminating. They will support the transformation, actively and visibly, as long as it does not transform the thing they know how to manage.
Most companies, when they decided to “get serious about AI,” put their early majority people in charge of it. The VP of Operations who has been running the process for twelve years. The IT leader who manages the approved tool list. The project manager who knows how to run an implementation. These are competent, experienced people. They are also precisely calibrated to produce the outcome you are seeing: structured pilots, careful benchmarks, governance frameworks, and almost no fundamental change.
I wrote about a version of this move in The Oldest Trick in Management Just Stopped Working. Propose a project, buy time, call it strategy. It worked for decades because nobody outside the room could tell the difference between real progress and a well-run delay. AI removed that cover. Now the delay shows up in the numbers.
The early majority manager will not kill your AI strategy. They will professionally manage it into irrelevance. That is a harder problem to solve because it does not look like failure. It looks like progress.
So here is the part that actually matters. Not just naming the wrong group, but knowing exactly how to spot both groups before you hand anyone the mandate.
How to spot the early majority manager, the wrong person for this job
They ask for the case study first. Before touching a tool, they want to see someone else, ideally a direct competitor, already succeeding with it.
They translate everything into the old process. The AI system gets explained as a faster version of the current workflow, never as a reason to throw the workflow out.
Their timeline has a review board in it. Every proposal routes through a committee that meets monthly, whether or not the work is ready.
Their success metric is the absence of complaints. A quiet rollout counts as a win, even if nothing measurable moved.
They have never used the tool themselves. They have watched a demo. They have read a vendor deck. They have not sat with it long enough to be frustrated by it.
How to spot the builder, the right person for this job
They already automated something without being asked. A report, a follow-up sequence, a piece of their own job. Nobody approved it. They just did it.
They complain about a tool by name. Not “AI isn't ready,” but “this specific model is bad at this specific task, and here is the one that isn't.”
They can tell you what broke last week. Builders fail constantly and remember every failure in detail, because they are the ones who have to fix it.
They ask for access before they ask for budget. An API key, an admin console, a sandbox. Money is secondary to permission.
Their title has nothing to do with any of this. They are rarely in IT or a formal AI role. They are in ops, sales, finance, wherever the most tedious work lives.
The operator split is already underway, and most companies are on the wrong side of it.
Watch what happened inside engineering teams first, because it is the clearest preview of what is coming for every other function. When AI coding tools first got good enough to matter, experienced engineers fought them. Hard. They complained the code was sloppy, that fixing what the model got wrong took longer than writing it themselves, that the whole thing was a productivity tax dressed up as a productivity gain. For a while, they were not wrong. A rigorous 2025 study by METR, a nonprofit that runs controlled trials on AI capability, measured experienced open-source developers doing real tasks with and without AI coding tools. The developers expected a 24 percent speedup. They actually finished 19 percent slower, and even after the study ended, most of them still believed the AI had made them faster. The gap between what people felt and what the clock showed is the entire early-majority story in one experiment.
Then something changed. Less than a year later, METR tried to run the same experiment again to measure how far the tools had come. They could not find developers willing to take part, because, in the researchers' own words, the developers did not wish to work without AI even for the length of a study. The same engineers who had documented in careful detail why the tools were slowing them down would not go back to working without them.
That is not a story about a model getting better, although it did. It is a story about a threshold. Below it, the early majority's complaints were legitimate data. Above it, the same complaints became an excuse to stay comfortable. Most executives cannot tell which side of that threshold their own function is on, because they are not the ones doing the work.
Once the tools crossed that line, a strange split appeared. Everyone had started using AI. Some people became dramatically better while others concluded the tools were overhyped. Same models. Same subscription tiers. Same basic interface. Completely different outcomes.
The difference was not access. It was operating skill.
The best AI coders are running multiple agents in parallel. One to write, another to review, another to attack the assumptions, another to check security, another to test. They are building routines. Creating memory structures. Learning when to use the frontier model and when to route the work to something cheaper. They are managing a small synthetic team.
That split is moving through every function now. Sales. Marketing. Finance. HR. Legal. Product. Two people will have access to the same intelligence. One will get a marginal productivity gain. The other will rebuild the job. Two companies will buy the same model. One will produce a deck. The other will produce a new operating system.
WHAT THIS LOOKS LIKE INSIDE A REAL COMPANY
I see this split every day at Collective[i]. Two customers get access to the same forecasting and relationship data. One assigns it to a rep as a better spreadsheet. The other rebuilds the revenue function around it, changing how deals get reviewed, how forecasts get built, and who owns the data entering the system in the first place. Same intelligence. One gets a nicer dashboard. The other gets a different company.
Hackathons are a warning sign. First principles are the actual work.
A hackathon rewards the team that ships the best demo inside an artificial timebox, using whatever tools are already sitting on the shelf, recombined in a way that looks clever under stage lighting. Nobody asks what metric moved. Nobody checks if the demo survives contact with a real customer on Tuesday. The prize goes to the best performance, not the best change. That is precisely why hackathons feel like progress and rarely produce any.
First-principles reimagining starts somewhere else entirely. It starts with the metric the company actually needs to move, cycle time, win rate, forecast error, revenue per employee, and works backward, asking what the process would look like if it were designed today, from nothing, with today's intelligence available on day one. Most existing processes were built around a human bottleneck that no longer has to exist. A weekly forecast review exists because a room full of people could only meet once a week. A monthly close exists because reconciling ledgers by hand took that long. Neither constraint has anything to do with what is actually possible now. Keep the process and bolt on AI, and you get the same weekly cadence, slightly faster. Rebuild the process from the metric backward, and a weekly cadence looks like a self-imposed penalty nobody would choose if they were starting today.
This is why hackathons are mostly theater and first-principles work is not. An AI-first company rewards the team that changes the metric that matters. Cycle time down. Win rate up. Forecast error down. Revenue per employee up. That is how you know the company is actually learning, and it is also the test for whether the person running your AI effort belongs in that seat. Ask them what metric they are trying to move before you ask them what tool they are using. If they cannot answer the first question without reaching for the second, you have the wrong person in the job.
The builder in your building tonight has options you don't know about.
In January 1962, five years into his career as an IBM salesman, Ross Perot hit his entire annual sales quota in about three weeks. IBM had already capped how much a salesman could earn in a year, so there was nowhere left for that performance to go. Perot had a better idea anyway. He pitched IBM's leadership on selling computer services and support alongside the hardware, not just the machines themselves. IBM's leadership turned him down. Later that year he left, and with a thousand dollars his wife loaned him from her teacher's savings, he founded Electronic Data Systems. IBM had the technology. IBM had the customer relationships. IBM had every advantage a company could ask for. What IBM did not have was someone in the room willing to notice what its own customers actually needed and act on it before a committee could get around to ruling on the idea. Perot built EDS into a company General Motors eventually paid two and a half billion dollars for.
Somewhere inside your company right now, there is a version of that story starting. Someone is automating the work everyone else complains about. They know which models are good at which tasks. They know when the official tool is worse than the open-source one. They know where the data is broken. They know which process is fake. They may not have “AI” in their title. They are the internet-native developer of 1998, and IBM's mistake with Perot is available to you as a warning, not a repeat.
Find that person. Not eventually. Now. Because the alternative is not that they stay quiet and compliant while you get around to noticing them. The alternative is that they take what they have already built, walk out, and start the company that eats yours. You do not need to invent a reason to give them room. They are already giving you the reason. It shows up as a side project, a personal automation, a complaint about a process that everyone else has stopped noticing is broken.
Give them the budget, the authority, and the cover to move. Not to run a pilot. To change something real. If the first thing they want to do makes the early majority manager uncomfortable, that is probably a sign they have identified the right target.
The senior leaders who are not using AI personally, not watching demos, but actually using it, building with it, failing with it, learning its texture, are not qualified to lead this transition. You cannot delegate fluency. You can delegate implementation. You cannot delegate instinct.
The org itself was built for a different speed.
The problem is not just the people. It is the architecture the people built. Most large organizations have vendor onboarding processes that run six to eighteen months. Security reviews requiring documentation packages that take quarters to assemble. Procurement cycles with approval layers that predate the technology being evaluated.
That infrastructure was built for a different speed of change. It made sense when the cost of a bad vendor decision was catastrophic and the cost of a slow decision was minor. That calculus has inverted, which is the same argument I made about CRM in Workflows vs. Outcomes. Systems built to standardize the last era of work will not tell you what to optimize for in this one.
THE ORGANIZATIONAL DNA OF THE AI-FIRST COMPANY
Security moves fast. Not recklessly. Fast. Pre-approved low-risk tool categories deployable in days. Serious review reserved for tools touching regulated data or autonomous action. Most companies have one speed. The AI-first company needs two.
Vendor onboarding compresses. A fast-lane commercial and legal structure for short-duration pilots gets a new capability into hands within weeks, not quarters. Due diligence still happens. It happens faster.
Budget is switchable. A line item for experimentation can be redeployed monthly based on what is working. The finance team that says “we'll revisit at next year's planning cycle” is making the riskiest possible bet with the company's time.
Metrics connect to goals from day one. Every test needs a metric that connects to the outcome the organization cares about. If you cannot define what a successful test looks like before you start, you are not running a test. You are running a delay with a progress bar on it.
Management support is active, not declarative. Support means specific named actions. I will unblock the security review by this date. I will approve the pilot budget this week. I will attend the first results readout. Not “we support AI adoption” in the all-hands.
The infrastructure of caution is the most invisible competitive disadvantage in business right now, precisely because it looks like good governance. The companies that rewire it are not just choosing better tools. They are building a different operating rhythm, closer to what I described in Infinite Leverage, where the constraint on what a company can build stops being headcount.
AI is not one thing. Most companies are using one thing and calling it a strategy.
A surprising number of leadership teams still use the word AI when they mean an LLM. That is like saying “transportation” when you mean a bicycle.
Language models are extraordinary at words, code, summarization, reasoning, and research. Diffusion models generate images, video, and design directions. World models simulate environments so robots and autonomous vehicles can learn before they touch the real world. Biology models like AlphaFold model life's molecules. Economic models study how business actually happens to predict outcomes. Relationship graphs map real trust and verified connection across the commercial network.
These are not “AI tools.” They are different brains. Different architectures, trained on different data, designed for fundamentally different problems. Deploying a language model against structured commercial data and expecting it to predict sales outcomes is the category error that killed Einstein and Watson. The model knows language. It does not know deal physics.
An AI-first company asks what kinds of intelligence should exist inside this company. A language brain for words. A code brain for software. A revenue brain for economic outcomes. A relationship brain for trust and access. Then the harder question: how do these brains talk to each other so the company gets smarter as a system?
The board question nobody is asking.
A company cannot become AI-first if the people governing it do not understand what disruption feels like from the inside. Not from a board presentation. From having been inside an organization when the ground shifted.
A board without AI fluency will ask management to prove the future using the metrics of the past. The CEO will be rewarded for protecting the current model instead of building the next one. Only two percent of boards rate themselves highly knowledgeable about AI. That number explains a great deal about why most companies have not fully integrated AI across the enterprise.
The board should have someone who has built with AI at the operational level. Someone who has watched a market form before incumbents understood what was happening. Someone who knows the difference between a company talking about AI and a company running on it.
I've spent thirty years building networks, first at LinkShare, now at Collective[i] and Intelligence.com, and I sit on Spire Global's board because that same question comes up there too. It is not a credential you get from a course. It is scar tissue you get from being in the room when the model broke and you had to build the next one before the quarter ended.
Finding the builder before they walk out the door and putting the early majority manager somewhere they can still do good work, just not this work, are not side notes to an AI strategy. They are the actual first steps of one. I wrote in The Race Is On about how far the AI-first organization already is from a typical one, flatter, faster, with fewer layers between an idea and its execution. Nobody arrives at that structure by installing software. They arrive at it because the right people, using first principles and more than one kind of model, were given the room to take the company apart and rebuild it. That is not the end state. It is the ignition.
PART 2 OF 3
The tools are not the problem. The people controlling the pace are. Part 3: What an AI-First Company Actually Does.
Artificial CommonSense is published at reloadnyc.com. For revenue intelligence: intelligence.com.
FROM ARTIFICIAL COMMONSENSE, RELOADNYC.COM
Part 1 → The Safest Move You Can Make With AI Will Cost You Everything
Part 3, next in this series → What an AI-First Company Actually Does
