I am a big fan of using AI as a collaboration tool when writing. Claude and I spent about 20 hours writing and polishing the data strategy at my last company. I also used Claude to write and refine my failure management framework, which ChatGPT and I later spent a few hours editing and reworking. AI has become a critical part of how an increasing number of us write. If you aren't doing this, I highly recommend giving it a try.

Co-authoring with AI also has a downside. There has been a rise in a somewhat homogeneous writing style because authors are outsourcing their voice to AI instead of teaching the AI to write in their own voice. It's making what would otherwise be high-value content sound increasingly alike. You can see it in the syntax (the em dash. Ugh.), in the phrasing, and in the sentence structure. Contrastive phrasing and the constant push to end on a tagline are probably the most obvious examples. If we want our writing to have real impact, we need to fix this.

So here's my recommendation. Have your AI of choice interview you about your writing style and save the results as a Markdown document. You can share that document with other AI platforms and attach it to new projects as needed. I've found that both ChatGPT and Claude apply it fairly consistently from memory, although I occasionally have to remind them.

I think this matters for everyone, but even more for people in technical roles like ours.

- Will

References​

• https://www.theatlantic.com/technology/2026/07/ai-chatbot-writing-tic-negative-parallelism/687892/
• https://substack.com/@ruben/note/c-250465609

I didn't set out to become an enterprise architect. For almost twenty years I was simply solving problems that didn't fit neatly into anyone else's job description. Somewhere along the way, someone I respected put a name to what I had been doing all along.

My career didn't follow a traditional path. I have some college but no degree, and my formal training had little to do with the work that followed. I learned by solving problems. Each new challenge became an excuse to learn another skill.

Early on, I realized I didn't want to specialize. Every new discipline I learned expanded the number of ways I could solve a problem. I wanted options more than expertise in a single technology.

Over time, I spent less time connecting systems and more time connecting people. I learned that the specialists do the real work. My role is to help them succeed by bringing the right people together, helping engineers build things they'll be proud of, and helping the business understand the trade-offs behind their decisions.

That eventually became enterprise architecture.

My definition of the role is pretty simple. Raise the craftsmanship of engineering. Be a trusted business partner. Help the organization understand the difference between what technology makes possible and what is worth doing. Every meaningful decision is a negotiation between value, cost, risk, time, and complexity.

Frameworks are useful. They give us a common vocabulary and preserve the lessons of those who came before us. I use them, and I respect them. At the end of the day, though, architecture is still about helping engineers build better systems and helping the business make better decisions.

- Will