Builder, Not Buyer

I'm not a developer. I don't have a computer science degree. I've never worked at a technology company. And I personally built the dashboards, the MCP integrations, the skills library, the custom applications, and the training infrastructure that drove 98% AI adoption at a global investment bank. That combination — non-technical background, hands-on builder — is the point.

There's a common assumption in enterprise AI that the person leading the program should be either a strategist who manages vendors or an engineer who builds from scratch. I'm neither. I'm a practitioner who builds with AI, using AI. And I think that profile produces better programs than either alternative, because it generates a type of understanding you can't get any other way.

When you build the system yourself, you learn things that no vendor demo will teach you. You learn where the model hallucinates on your specific data. You learn which prompt structures work for your firm's document formats and which produce garbage. You learn that the feature that looked transformative in a sales presentation creates three new problems when applied to actual workflows. You learn the failure modes, and that knowledge is what lets you design around them.

I built a skills library of 40+ structured AI workflows. Each skill was designed, tested, iterated, and documented by me — not purchased from a vendor's template gallery. That matters because every skill reflects the actual work our professionals do. I watched people use them, saw where they got stuck, and rebuilt the parts that didn't land. That feedback loop — build, observe, rebuild — is what makes the library effective. A purchased library doesn't have that loop. It has assumptions about your work, not knowledge of it.

The same principle applied to our dashboards. I built the analytics infrastructure that tracked adoption, usage depth, and value creation. I built it because I needed to see specific things — which practice groups were deepening their usage, which skills were sticky, where activity was clustering around power users — and no off-the-shelf dashboard showed me what I needed. The act of building the measurement system made me a better program designer, because I had to decide what mattered before I could measure it.

MCP integrations are another example. When I needed AI workflows to connect to our firm's actual systems — internal databases, document repositories, communication tools — I built those connections. Not because I enjoy systems integration, but because the alternative was waiting months for a vendor to build a connector that might not map to our architecture. By building it, I controlled the timeline, the design, and the data flow. More importantly, I understood exactly what data the AI was accessing and how, which is non-negotiable in a regulated environment.

People sometimes ask if this approach scales. The question misses the point. Building is how you learn what to scale. Every custom application I built started as a solution to a specific problem someone brought me. Some of those solutions turned out to be one-off fixes. Others turned out to be patterns that applied across the entire firm. I wouldn't have known which was which if I'd outsourced the building to a vendor. The vendor would have built what I spec'd. By building it myself, I discovered things I didn't know to spec.

There's also a credibility dimension that matters more than people acknowledge. When I train a senior professional on an AI workflow, they can tell whether I've actually used it. If I'm reading from a vendor's training guide, they disengage. If I can say "here's where this breaks, here's the workaround I found, and here's why the third iteration of this prompt works better than the first" — that's practitioner credibility. They trust me because I've done the work, not just managed the contract.

I'm not arguing that every AI leader should become a full-stack engineer. I'm arguing that the person leading an AI program should be building with the tools, not just evaluating them. There's a category between "pure strategist" and "pure engineer" that I'd call the AI-native builder: someone who uses AI itself as the building medium, who understands the capabilities and limitations from direct experience, and who maintains enough technical fluency to architect systems without necessarily writing production code from scratch.

The savings our program generated didn't come from choosing the right vendor. They came from building the right systems — systems designed with intimate knowledge of where the tools work, where they don't, and where a thoughtful workaround turns a limitation into an advantage. That knowledge lives in the builder, not in the buying decision.

If you're hiring for an AI leadership role and your job description reads like a procurement manager with a strategy overlay, you're hiring for the wrong thing. Hire a builder. Or better yet, become one.