I built my first computer for myself, then started building them for customers. As a teenager running a small PC-building business, I tested every rig against a punishing stress-test suite before I let it out the door. A computer that crashed under load wasn't finished. It was a returned sale and an unhappy customer. That's a strange place to start a story about consulting and AI, but it's the honest one. Long before I had a title, I had the same habit I use now: build the thing, find where it actually breaks, and fix that.
Where it actually started
My first real job out of undergrad wasn't in technology at all. At a consulting firm, I worked on research and development tax credit cases and chased documentation across dozens of active projects. Every case had its own stakeholders, timeline, and quiet way of almost falling apart. That job taught me something school hadn't: much of "the work" in a complex organization is getting the right information in front of the right person before the window to act closes.
From there I moved into ERP and enterprise software implementation consulting, and that's where the pattern locked in. Over five years, I worked inside more than twenty client engagements across industries that had almost nothing in common on the surface: real estate, waste management, higher education, insurance, retail, and energy. I found the same underlying problem every time. The technology was rarely the hard part. A change could be honest and correct inside one system, one department, or one person's head while quietly threatening something three steps away. My job in those rooms was to see the connection before it became an emergency.
What business school actually gave me
I went back for an MBA at Rice because I wanted language for something I'd been doing by instinct for years. The strategy coursework gave me useful frameworks. More valuable, and less flattering to admit, was learning to sit with a genuinely hard, ambiguous problem long enough to think about it instead of reaching for the first plausible answer because a room full of people is waiting. That's a discipline rather than a personality trait, and I've had to keep relearning it. The pressure to look decisive is relentless, while being decisive is not the same thing as being right.
The bottleneck that never went away
By the time I was leading larger programs, I'd hit the same wall often enough to stop treating it as a coincidence. One cross-functional platform assessment for an energy operator put me in front of dozens of subject-matter experts across a dozen disciplines, including drilling, land, regulatory, finance, and production. Analysis wasn't the bottleneck. Synthesis was. Someone had to listen to fifteen people describe their own slice of a system, then produce the document showing how all fifteen slices connected. That work was enormously valuable and enormously slow. For most of my career, the only tool for it was a sharp analyst and a lot of hours.
Doing that work taught me that clarity has to be produced, not merely requested. A structure earns its keep during a bad week, when a good team needs it most. And the people side of a project is often the load-bearing wall, even when everyone calls it the "soft" side.
Why AI, and why now
I came to AI through the synthesis problem, after spending hundreds of hours connecting scattered, unstructured information into a coherent picture someone could act on. Language models are unusually good at that work. Handing it off still deserves care, because synthesis has been the bottleneck in almost every complex program I've run.
So the last stretch of my career has felt less like a pivot than closing a loop. I studied how these systems work, including their strengths, failure modes, and the specific places they overreach or quietly make something up. I wanted to design around those limits with the same rigor I'd apply to any system carrying real consequences. The framework I built decides how much rigor an AI build needs by asking what happens when it is wrong and who finds out. That keeps a weekend project from being over-engineered and a client-facing system from being under-engineered. I use the framework in my own work now, including an agentic decision desk that does in software something close to what I used to do by hand in those cross-functional rooms: trace a change across disciplines to the thing it threatens, then put a clear, evidence-backed decision in front of the person who has to make the call.
What I actually enjoy
None of this would stick if it were only strategic. I like systems for their own sake, especially the moment when a complicated thing finally coheres. That can be a PC I built by hand as a teenager, a personal knowledge base I've spent years refining so it becomes more trustworthy rather than more cluttered, or an organization learning how to move through a hard transition without breaking. I also spent a few years running a personal training business. What stayed with me wasn't fitness so much as the work of translating a general principle into a plan specific enough for one person to follow. I still do that work now, just with different systems.
Outside of work, I sit on the board of a small historical society tied to my family's Scottish heritage, which has nothing to do with any of the above and is exactly the kind of thing I think a person should keep doing anyway.
Where this is headed
I don't think of the move into AI as leaving project management and consulting behind. It's the same job I've always had: understand a complex system well enough to see where it's about to break, and build something, a process, a plan, or now, increasingly, software, that keeps it from breaking. The tools changed. The job didn't.
