Precision Is Creative

There's a persistent myth in technology that creativity lives in the blue-sky phase — the whiteboard sessions, the brainstorms, the "what if we just" conversations that feel generative because they're unconstrained. The implication is that constraints are the enemy of creative work, that precision is what you apply after the creative part is done, a kind of bureaucratic tax on imagination.

I've come to believe the opposite. The most creative work I've done has happened under severe constraints — tight timelines, fixed architectures, immovable requirements that initially seemed to make good solutions impossible. Constraints don't suppress creativity. They redirect it. They force you to find solutions that are elegant because they have to be, not because you had infinite room to add complexity.

Precision isn't the opposite of creativity. It's what creativity looks like when the stakes are real.

--- title: "The Build vs. Buy Question Nobody Asks" subtitle: "Why the real question is about ownership, not software" type: thinking slug: build-vs-buy status: published featured: false published_at: "2026-01-05" ---

Every enterprise AI conversation eventually arrives at the build-vs-buy question. The standard analysis weighs development cost against license fees, time-to-market against customization, and engineering capacity against vendor support. These are reasonable factors. They're also the wrong frame.

The question that matters isn't whether to build or buy the software. It's whether to own or rent the capability. Software is an artifact. Capability is the organizational muscle that knows how to use the artifact, adapt it, evolve it, and — crucially — know when it's not working. When you buy a platform, you acquire an artifact. Whether you also acquire the capability depends entirely on how you integrate it, and most organizations don't think about that until it's too late.

The most dangerous AI vendor relationship is the one where the vendor understands your system better than you do.

I've seen this play out with enough regularity to call it a pattern. A company buys a best-in-class AI platform. The vendor's professional services team does the initial integration. The system works well during the honeymoon period. Then requirements change — a new data source, a different use case, a shift in business logic — and the company discovers they can't adapt the system without going back to the vendor. They've acquired software but not capability, and the gap between those two things is where vendor lock-in actually lives.

The build option has its own version of this failure. Companies that build from scratch often over-invest in the initial system and under-invest in the organizational learning that makes the system useful. They end up with a custom solution that's perfectly tailored to yesterday's requirements and expensive to adapt to tomorrow's.

The organizations I admire most have found a third path. They make deliberate decisions about which capabilities are core — meaning they must be owned, understood, and evolvable by internal teams — and which are commodity — meaning they can be rented from vendors without strategic risk. The line between core and commodity isn't static. It shifts as the organization learns, as the market evolves, and as the technology matures. The skill is in knowing where to draw it at any given moment.

For most enterprises, the core capabilities in AI are not model training or infrastructure management. They're data curation, domain-specific evaluation, workflow integration, and feedback loop design. These are the capabilities that determine whether an AI system works in your specific context, and they're the ones that are hardest to buy from a vendor — because they require deep knowledge of your operations that no outside party will ever fully possess.

My advice to clients is usually the same: buy the infrastructure, build the integration, own the feedback loop. The infrastructure is commodity — cloud providers and model APIs will compete on price and performance. The integration layer is where your operational knowledge lives, and the feedback loop is what turns a static system into one that improves. Rent the things that don't differentiate you. Own the things that do.

--- title: "Systems That Listen" subtitle: "What it means to build technology that pays attention" type: thinking slug: systems-that-listen status: published featured: false published_at: "2026-02-15" ---

Most enterprise software talks at people. It presents dashboards, generates alerts, pushes notifications, produces reports. The information flows in one direction: from system to human. The human's job is to absorb, interpret, and act. If they fail to do so — if they miss the alert, misread the dashboard, ignore the report — the system's position is clear: I told you.

The systems I find most interesting are the ones that listen. Not in the conversational-AI sense of processing natural language input, but in the deeper sense of paying attention to how people actually behave and adapting accordingly. A system that notices which metrics an executive actually examines and reshapes its display to surface those first. A triage tool that learns from nurse overrides instead of treating them as errors. An operations copilot that watches how engineers diagnose problems and refines its hypotheses based on what they investigate.

Listening, in systems design, means building feedback loops that treat human behavior as signal rather than noise.

This is architecturally expensive. Feedback loops require instrumentation, storage, processing, and — hardest of all — a model of what the feedback means. When a user ignores a recommendation, is the recommendation wrong, or is the user busy? When an executive drills into one metric and not another, is the second metric irrelevant, or does the executive already know its value? Building systems that listen means building systems that can reason about ambiguity in human behavior, which is a fundamentally harder problem than building systems that broadcast.

But the payoff is proportional to the difficulty. Systems that listen get better over time. They earn trust incrementally, because users can feel the system adapting to them. They surface problems that static systems miss, because they're tuned to the gap between expected behavior and actual behavior — and that gap is where the most valuable operational insights live.

There's an ethical dimension here that I think about often. A system that pays attention to human behavior has power, and that power can be used well or poorly. The systems I build are designed to listen in service of the user's goals, not in service of engagement metrics or behavioral manipulation. The distinction matters, and it should be encoded in the architecture, not just the privacy policy.

The practical question for any organization considering AI is not "what can we automate?" but "what are we not hearing?" Somewhere in your operations, there are patterns in human behavior that contain diagnostic information your current systems ignore. The most valuable AI systems are often the ones that simply start paying attention.

[DRAFT]

[DRAFT]

[DRAFT]

[DRAFT]