Who has the standing to write about AI-Native?
A reader who has gotten this far is allowed to ask the obvious question. Why this person. What does he know.
I want to answer it honestly, because the honest answer is more interesting than the credentialed one and probably more relevant to whether you'd want me in a room with your team.
I think associatively. I have known this most of my life, and for much of it I did not have good language for the difference. I move between broad framings and narrow details and make connections across domains that do not usually meet. A conversation about a factory can call up something I learned in hospitality; a question about an AI architecture can expose a problem in how a leadership team makes decisions. Sometimes I see the connection before I can explain it; sometimes the room sees what I missed. I have spent years learning to slow the leap down, expose the steps, and let other people test whether the connection holds. That matters because intuition can produce insight and nonsense with the same feeling of arrival. People ask how I thought of something. The honest answer is often that the connection arrived first and the explanation came afterward. That makes the explanation, evidence, and challenge more important.
I am telling you this because the work in this field guide is the product of a particular kind of mind, and you should know what kind of mind it was so you can calibrate what to do with what you have read.
The mind would not be enough on its own. What gave it traction is what I have spent my career doing. For more than two decades I have designed and led collaborative experiences for senior teams working on complex, high-stakes problems. The work has spanned industries that don't usually share rooms with each other: financial services, hospitality, defense, healthcare, retail, manufacturing, professional services, and technology. The work has spanned topics that don't usually get worked on by the same facilitator: strategy, innovation, operating model redesign, HR transformation, culture change, technology rollouts, customer experience design, and large-scale change management.
Working across those fields has taught me to recognize patterns and ask where the comparison holds. I have watched rooms avoid the subject they were assembled to discuss and then turn when someone finally named it. I have watched an artifact carry a decision for years, and another become wallpaper before the week ended. I have learned to ask what produces a real conversation, how power appears in collaboration, when disagreement generates insight or deadlock, and which artifacts remain useful. What might be shared across a Navy command, a hotel loyalty program, a software company's culture, and an insurance firm's strategy? Cross-domain work can reveal patterns a specialist may not encounter. Specialists can also see causal detail, history, law, and risk that a pattern-seeker misses. The work is strongest when breadth and depth correct each other, and when the facilitator knows which kind of knowledge is absent from the room.
The work has also given me a long view on what humans can do together under different conditions and what no framework guarantees. The most important principle I carry is simple: people are more likely to understand, shape, and support work they legitimately help create; work done to them without voice or recourse creates a different relationship. Participation does not confer ownership automatically, erase disagreement, or substitute for rights and authority. The principle is why I am skeptical of consulting that promises to deliver transformation as a package. Co-creation is not a ceremony added to delivery. It changes who has standing in the design.
The third thing I bring is more recent: I have been building a company of my own, from an idea to a working product, living inside the AI-Native question rather than studying it only from a distance. Founder experience is not a credential that outranks enterprise experience. It is exposure to a different set of constraints: limited time, limited capital, incomplete roles, direct consequences, and no clean separation between the person proposing the operating model and the person who has to work inside it tomorrow.
That experience has changed how I think about everything I had written about this topic before. It has shown me, in my own work and in my own team, what it actually feels like when AI is genuinely woven through how you think, build, and decide. It has also shown me what goes wrong. The moment we noticed we were defaulting to Claude Code instead of talking to each other and had to correct it deliberately. The moments where the gain was real and the moments where the gain was illusory. The places where AI compressed timelines and the places where it produced confident output that needed to be torn up and started over. The texture of doing this kind of work rather than the theory of it.
What I have learned at this scale does not transfer cleanly to a company of a thousand people or ten thousand. Even the principles must be retested under different power, regulation, legacy systems, geography, labor arrangements, and consequences. Lived experience gives me something observation alone does not: a felt sense of the work, including its seductions and failure modes. I know the pleasure of compressing a week into an afternoon and the danger of mistaking speed for correctness. I know how quickly an AI collaborator can become the default participant in a conversation and how deliberately a human team has to reclaim the moments that should remain between people. It makes me less satisfied with maturity scores without behavior, operating-model diagrams without lived work, and answers that arrive before the room has learned to ask the consequential questions.
I am sharing all of this because the field guide you have just read is shaped by all three of these things: the way I think, the breadth of what I have facilitated, and the lived experience of building inside the question. If you have found yourself in disagreement with parts of the field guide, you should know that those disagreements are with a particular mind that has come to its positions in a particular way, and you are entirely entitled to think differently. If you have found yourself agreeing with parts of the field guide, particularly the parts that argue this conversation is more about human life than about technology, you should know that the agreement is with a position someone has come to, the long way, after a lot of years and a lot of rooms.
The offer, if you are considering bringing me into your organization, is that I would help your leadership team do this work in your context, with the people affected and on the questions that matter. The engagement needs facilitation and operating-design capability alongside credible technical architecture. I have spent more than two decades practicing the first and recent years building inside the second; Nodalix and other qualified technical specialists bring engineering depth that I do not claim as my own. We would build and test frameworks with your team rather than deliver them as doctrine. The valuable part is what your organization accepts, rejects, corrects, and creates that would never have occurred to me. That is the part I look forward to most.