Back in 1962, Everett Rogers spelled out a theory of how new ideas are adopted. I have leaned on this for years as a fundamental truth of my job. The image below breaks it down.

Most internal platforms get designed for innovators. Teams get excited when new technology gets introduced and engineers who are pushing the leading edge spend a lot of late nights and weekends learning the nuances of the new thing. It happened with early data warehousing. With cloud. With blockchain. These days with AI. The rules for the "new thing" are defined by the capabilities of the hardest of hard core engineers.

The issues is that the innovators and early adopters are a small slice of any population, roughly 16% on Rogers' diffusion curve. The other 84%, the early majority, late majority, and laggards, are the people who actually run the enterprise day to day. If we design for the 16%, we've built something most of the company may not fully understand but will use for the next few years.

The pattern is familiar to anyone who's led a platform team. A group of strong engineers builds something for engineers like themselves. They are curious, comfortable with rough edges, happy to dig through source code when the docs run out. We make so many decisions based on their ability to keep it running.

But what happens when they leave the room?

Folks who make up the majority (early or late) are the life blood of enterprises. They are the ones who deliver day in and day out. It's easy to get distracted by the shiny new penny, but we still have work that needs to be done, and these teams are the ones who do it.

The challenge is that, despite the high-value work these teams deliver, they don't always have the skill set to counter an incomplete platform that was designed for a diferent type of engineer. These are the people who focus on business value every day. Chasing the latest tech is not their priority. We need to build platforms for this group.

So what does it actually take to design for the majority? A few things I've come to believe matter more than almost anything else:

Make it opinionated. One clear path with minimized flexibility and a focus on the basics. Flexibility sounds like a feature, but for most users it's a tax they can't afford to pay. Focus on minimizing low-value choices that innovators would call "flexibility" but the majority would see as toil.

Some recommendations:

• Make it boring. If it takes a conference talk to explain whats going on, it's probably not ready for a broad audience yet.

• Build in guardrails instead of relying on documentation. Most people won't read the manual, and that's fine. Make the safe path the easy path.

• Lead with proof. The late majority adopts because their peers already did and nothing broke. A few trusted teams inside your own company using something successfully is all the evidence you need.

• Measure adoption. Use data to help you understand what is and isn't working.

None of this means we stop innovating. Early adopters still need room to experiment. That's how the next good idea gets found. But the platform you scale across a whole company is a different thing than the one you prototype with, and treating them the same is how you end up with something that never quite meets your expectations.

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