The Tools Were Never the Point

Four decades of experimenting with technology, questioning its promises, and finding useful things to build.

I talk and write a lot about technology and its impact on business, culture and how we see ourselves and our place in the world... sometimes I'm enthusiastic, sometimes critical, and sometimes utterly and completely wrong.

Recently I sat down to investigate a colleague's back-story in order to more effectively understand their perspective on things and it occurred to me that before digging into other people's credentials, I should probably do the same for myself first.

So here I offer a brief accounting by ChatGPT (written in first person in my own voice) based on a pretty exhaustive set of research and analysis of my experiences, how they shaped my perspective on technology, and how I apply that perspective in my own life.

I Was Never an Engineer

I went to Auburn University in 1987 intending to become an engineer, although I wasn't entirely sure what that meant. A few months later, I attended a party where a band had rented a small sound system. It made them louder, but it didn't make them sound any better. I thought I could do both.

So I persuaded my father to advance me about $6,000 in what would have been tuition money to instead start a business. He approved of the idea so I took the money, bought a Volkswagen Microbus, drove to Atlanta, and purchased a PA system. I began teaching myself sound engineering in my bedroom from a Yamaha handbook and whatever I could learn by experimenting.

At my first show, I discovered I was missing something fairly important that I hadn't known existed: an audio snake, the multicore cable that connects the stage to the mixing console. That was an expensive omission for someone who had already spent his entire startup funding and was working for free. Fortunately, a local music shop sold me one on a handshake and extended credit. The show went ahead, and so did my education.

Curiosity Before Credentials

I've always been interested in how things work. Not just machines, but music, organizations, ecosystems, human behavior, and the relationships between them. As a teenager, I discovered electronic synthesizers and became fascinated by the idea that elementary mathematical functions could produce complex and expressive sounds. That led me toward electronic music, sequencing, sampling, and eventually computers. I wasn't following a curriculum. I was following questions, often without any particular expectation of where the answers might lead.

In the early 1990s, I worked at the Texas Union MicroCenter at the University of Texas at Austin. It was a remarkable place to encounter the competing visions of personal computing: Macintosh, NeXT, Silicon Graphics, and the emerging world of networked information. The graphical web was just arriving. We were using tools like WAIS and Usenet, and experimenting with ways to connect machines that weren't necessarily designed to cooperate. What interested me most wasn't any particular computer. It was the realization that these machines could become tools for building other tools.

HyperCard, Macromedia Director, and eventually Flash were presented largely as creative authoring environments, but I saw opportunities to use them to construct applications, connect information, and solve practical problems. Some of those experiments became businesses. Others became abandoned projects, expensive lessons, or simply interesting afternoons. I rarely knew where they were leading, but each experience added something to a growing understanding of how systems work and what makes them useful.

Understanding the Problem

Over time, I noticed something about the way I approached unfamiliar work. I could enter a business or industry I knew relatively little about, become interested in how it operated, and begin recognizing relationships between its processes and things I'd encountered elsewhere. The vocabulary might be different. The equipment, regulatory environment, customers, and professional conventions certainly were. But beneath those differences were often recognizable problems involving information, incentives, communication, coordination, and human behavior.

A workflow in a recording studio might have something useful to teach us about a manufacturing process. An interactive publishing system might suggest an approach to managing real-estate marketing. Problems that appear to belong to entirely different industries sometimes share the same underlying structure. That doesn't mean expertise in one field automatically transfers to another. The details matter, and the people who work in those environments understand things an outsider cannot immediately see. But asking good questions, recognizing patterns, and listening carefully can be more useful than arriving with a predetermined solution.

When someone comes to me with a problem, my first objective isn't to sell them software. It's to help us understand what's actually happening. Sometimes the solution is an application. Sometimes it's automation, a change in process, or a better way for people to communicate. Sometimes the best advice is not to build anything at all. The important work begins before anyone chooses a tool, and often before we've even agreed on the right question to ask.

Enthusiasm Without Reverence

I've spent a great deal of my life being enthusiastic about technology while making fun of the industry that produces it. In San Francisco during the early internet boom, I worked at Organic Online and built interactive experiences using technologies that were changing almost monthly. At the same time, I started Reactiveware, a satirical T-shirt business that poked fun at the excesses of Silicon Valley. I also created Tamagotchi Smash, an absurd little internet experiment questioning people's growing emotional attachments to simulated companions.

I wasn't opposed to technology. I was fascinated by it. But fascination isn't the same as faith. I admired NeXT computers while publicly criticizing the company's treatment of its university sales channel. In the early 1990s, I argued that ordinary personal computers couldn't realistically replace a studio full of dedicated electronic-music equipment. Today I make electronic music on a PC using software synthesizers that exceed many of the capabilities of the hardware I once defended. I was wrong, or at least the technology changed enough to make my position obsolete, possibly sooner than I cared to admit.

That's fine. Being willing to revise an opinion is considerably more useful than being able to defend it indefinitely. New technologies deserve experimentation, not automatic acceptance or reflexive dismissal. The ability to recognize a useful innovation depends as much on understanding its limitations as appreciating its possibilities.

When the Answers Become Cheap

After years spent working across software, live production, media, and other disciplines, I returned to hands-on software development in 2025, just as AI-assisted programming was becoming remarkably capable. It was a strange experience. Things that once required considerable time and specialized knowledge could suddenly be attempted in an afternoon. The distance between imagining a solution and testing a working version had become dramatically shorter, but that didn't eliminate the need for judgment. In some ways, it made judgment more important.

When producing an answer is expensive, a great deal of effort goes into the mechanics of producing it. When answers become cheap, we can generate enormous quantities of them, including answers to questions we should never have asked. The difficult work moves toward defining the problem, understanding its context, evaluating the result, and deciding whether the solution is worth implementing.

That's particularly important for smaller businesses. A business owner may recognize that something isn't working without knowing whether the cause is software, process, communication, or an assumption nobody has thought to question. Adding AI to a poorly understood process doesn't necessarily improve it; it may simply make the wrong thing happen faster.

This is the thinking behind Auth/Technic. I'm interested in building useful systems, certainly, but I'm more interested in understanding what would make them useful in the first place. The growing power of our tools makes it easier to create solutions, but it also increases our responsibility to understand the problems we're attempting to solve.

The Future Isn't Finished

I've always been attracted to optimistic visions of the future. Not because I believe technology inevitably makes things better, but because I believe we have some responsibility for deciding what better looks like. The future isn't a destination waiting for us to arrive, nor is it something we can completely design in advance. It's something we discover through observation, experimentation, failure, imagination, and the exercise of human judgment. We can't know exactly where our efforts will lead, but we aren't powerless passengers, either. We can investigate, question, choose, and shape at least some of what comes next.

Looking back, there isn't a neat progression connecting a teenage fascination with synthesizers, a borrowed tuition payment, the early internet, satirical T-shirts, interactive software, and today's AI tools. I certainly didn't plan it that way. What connects them is a persistent curiosity about how things work, a willingness to experiment before knowing everything, and a conviction that understanding a problem matters more than possessing the fashionable tool for solving it.

The technology keeps changing, and I expect it always will. But the tools were never the point. The point was always what we could learn, what we could make possible, and what we might choose to do with it.