Naming the Work

For most of my career, I've been answering a question nobody asked me to answer.

Not officially. The job titles said other things — IT Manager, Technical Advisor, the guy who kept the edit suites running on a TV production. But underneath whatever the org chart said I was doing, the actual work was the same: find the people who are dependent on technology they don't fully control or understand, help them figure out what they actually need, and navigate whatever stands between them and a better situation.

Twenty-five years. Film and television production. A property management company with 2,500 units. The federal government. Different organizations, different scales, different politics. The same work.

The technology changes. The work doesn't.

I never had a name for it. Or maybe I had too many — IT guy, Apple guy, the person you call when the thing stops working. Those names were accurate but wrong. They described the tools, not the job. For a long time, I let that slide.

Something shifted in the last year.

Part of it was watching the companies that built their identity on being on the human side of technology — the ones who said the tools should serve the people, not the other way around — become something else. Rent-seekers. Platform landlords. Think Different became Think Same. If the companies that were supposed to be the alternative have become the thing they were alternatives to, then the question of who actually controls the technology you depend on has a different weight than it used to.

Part of it was a specific project. I ran something that worked — the technology held up, the people adopted it, the support model was solid. It got dismantled by an upstream organizational decision that had nothing to do with any of that. That outcome cost more than I expected. It also made something clear: technical success and organizational adoption are not the same thing, and the gap between them is where most of the real work happens. I already knew that. But I knew it differently after.

You reach a point where the choice is between continuing to do the work without naming it, or deciding to say out loud what it actually is.

This is me saying it out loud.

The work is about helping people stay in control of the technology they depend on. Not the platform. Not the vendor relationship. Not the procurement cycle. The people on the other side of the tools — the analyst who needs to run the report, the service agent who needs to help the client, the creative who needs the technology to stay out of the way of the work they actually care about.

When technology is done right, it disappears. People do what they came to do. That's the win. It's also the standard that almost everything in enterprise technology is not optimized to meet.

That's what Technology Change Navigator is about. Two audiences — individuals navigating technology decisions that feel bigger than they should, and organizations facing transitions that are equal parts technical, political, and cultural. The same question underneath both: what are you actually trying to do, and how does technology help you do it better?

This site publishes twice a month — first and third Thursday. Four streams: Sovereignty (why the control question matters now and what it costs), Navigation (how technology change actually works), Trusted Guide (practical help for individuals, low jargon), and The Long Game — which is this. Honest reflection on what it means to build something deliberately, in a world that rewards speed.

I'm not building this fast. I'm building it carefully. The cadence is what I can sustain without turning it into a new pressure system. The goal is a body of work that holds together over time — not a feed, not a content calendar, not a personal brand.

The goal is to leave people more capable than I found them.

That's been the job for twenty-five years. Now it has a name.