Built in the field. Proven at scale.
Introduction
I live in Katy, Texas. I have spent my working life around systems that other people depend on without ever thinking about them — networks, stores, crews, trucks, registers.
The job has had a lot of titles. Underneath them it has always been the same job: understand what is actually happening, decide what it is worth fixing, and stay responsible for the answer afterward.
Why I keep building
Questions do not go away when you ignore them. Most of what I have made started as something somebody asked me that I could not answer in one sitting — how a trust actually works, whether an aging network should be replaced now or in three years, what changes when a good engineer starts managing people.
The honest answer usually took longer than a conversation. So it became a book, or a design, or a piece of software. That has not changed. I still work out what I think by building the thing.
Before the résumé
My mother worked for Cellular One back when cellular was still something you had to explain to people. I grew up around installations, coverage problems, and the particular quiet that settles over a room when a system is down and customers are waiting. Telecommunications was the family trade before it was my career.
My father serviced and repaired heavy equipment. From him I learned what things cost when they break under load, and that maintenance is not what you do instead of the real work — it is the work. Between the two of them I had a fairly clear picture of consequence before I had a clear picture of much else.
There was ranch work in there as well: cattle, horses, and equipment that had to run tomorrow whether or not it felt like it. Later a job at Dairy Queen turned into running three of them, which is where I first found out that the schedule, the money, and the people are the same problem. And as a teenager I worked with the Debian project, where I learned early that a system built by strangers has to be operable by strangers.
None of that belongs on a résumé. All of it is in how I run an infrastructure organization.
How I work
- Truth over dashboards. Verify actual state rather than trusting the indicator. A green light is a claim, not a fact, and the gap between the two is where outages live.
- Customer fit before commission. Solve the customer’s actual problem first. The deal that was wrong for them is going to come back as a support burden, a renewal fight, or a reputation you have to rebuild.
- Don’t count money that isn’t there. Pipeline and expected revenue are not cash. Neither are projected savings. A number becomes real when it shows up in the account or leaves the invoice.
- Design for the person who comes next. A system that only its creator understands is not finished. If the reasoning lives in one person’s head, the organization has not bought an architecture; it has rented one.
- Know the blast radius. Understand what a change can affect before making it. Most of the serious failures I have seen were not caused by a hard decision made badly, but by an easy one made without looking.
Why the range
From outside, the work looks scattered: enterprise infrastructure, a telecommunications business, books on faith and money, songs, and research into governed AI. It is not five interests. It is one habit applied in five places.
All of it started with a real problem somebody had, and the method does not change with the subject. Understand what is actually wrong rather than what is being reported. Make the constraints visible so people can argue about the right thing. Build deliberately. Measure what matters. Finish it. Keep responsibility attached to the outcome after the interesting part is over.
That is the same discipline whether what comes out is a network, a book, or a business.
Beyond the résumé
- Doleman Enterprises dolemanenterprises.com A majority woman-owned telecommunications business founded in 2018. My wife, Marjie, is the majority owner and I serve as a partner. Carrier-agnostic brokerage for commercial customers across Texas, Louisiana, Oklahoma, and Arkansas — requirements, carrier selection, contract negotiation, circuit delivery, and the operational follow-through after the order is signed. It is also the other side of the table from the enterprise work, which has made me better at both.
- Revelation Recording revelationrecording.com The independent publishing and creative home the books and the music come out of. The book catalogue is Journey2Knowledge; the songwriting is The Pines and Wires.
- StashYourStudio private beta A workspace for independent musicians and self-published authors — catalogue, metadata, royalties, collaborators, release tasks, and files in one place instead of six. Built because we needed it.
- EMILY in development Enterprise Management, Intelligence, Lifecycle & Yield — active research into governed AI for business operations and continuity. The question I am working on is how a capable system can do useful operational work while staying inside owner authority, evidence, financial control, and explicit limits on what it is permitted to do. It is research, not a product, and it does not run a company by itself.
What I am working on now
- Focus Infrastructure and IT operations leadership at Director or VP level, and principal architecture work in multi-site, operationally complex environments.
- Writing Four long-form pieces on infrastructure economics, resilience, and large-scale migration. Read them.
- Learning Generative AI and large language model coursework through Google Skills, with more technical certification work planned.
- Building Governed AI research — how an operational system stays inside owner authority and verifiable limits.
Updated October 2026