Termbases and style guides can be designed with total rigor and still fail to change a single habit in the field. To understand why, and what separates the rollouts that take hold from the ones that quietly stall, we sat down with Jerry Bartlett of Content Pro Tech Ltd, Firehead’s partner for The Content Forge consulting offer. Jerry has spent years in the trenches of terminology programs, working directly with the writers, translators, and reviewers who are asked to actually use them. Here’s what he had to say.

On the human side of a rollout
Firehead: You’ve said that even a technically excellent termbase can stall out. Where does that disconnect usually come from?
“The most technically rigorous termbase rollout can stall completely if the writers, translators, and reviewers who are expected to use it don’t feel ownership over it. Terminology management asks people to change habits that, in many cases, they didn’t know they had. The writer who’s been using ‘initialize’ and ‘initiate’ interchangeably for three years isn’t careless; they simply haven’t been given a clear reason to choose one over the other. The change management challenge isn’t getting people to understand the termbase. It’s getting them to use it consistently under deadline pressure, when the temptation to reach for whatever label comes to mind is highest.”
Firehead: So what actually separates the rollouts that take hold from the ones that don’t?
“Two patterns consistently distinguish successful rollouts from stalled ones. The first is the presence of internal champions: colleagues who believe in the value of the program and are willing to advocate for it in team meetings, in review conversations, and in the informal exchanges where organizational culture actually lives. Champions are rarely manufactured; they’re identified and supported. The second pattern is visible feedback loops: showing writers and translators the before-and-after data from the pilot, so that the effort of changing their habits is connected to an outcome they can see and point to.”
Jerry illustrated the champion dynamic with a story from early in his own career:
“I suspect, in a lot of cases, ‘champions,’ or even a single advocate, must choose themselves. I once joined an established team of writers who had a separate, dedicated group of localization experts. It was a new field to me, with a lot of unfamiliar terms and concepts to absorb. My job was split between supporting UX on a new product and re-writing a reference guide to how scripts and commands were to be used. I kept asking the ‘stupid’ questions: ‘Is that even a word?’ ‘Why are we using that term when there’s a perfectly good one already?'”
That instinct to keep asking the “stupid” questions is what a champion actually looks like in practice — not an evangelist with a mandate, but someone willing to surface the friction everyone else has learned to work around. Paired with a visible feedback loop, that’s the same dynamic Jerry saw play out on a specific project, where the theory met the reality of a complex software environment.
Case study: when a terminology program takes hold
Firehead: Can you walk us through a case where this played out concretely?
“A mid-sized software company had already put in the design and workflow work to build a termbase. The termbase was well-structured. The TBX export was integrated into the TMS. And six weeks into the rollout, term suggestion acceptance rates from translators were sitting below forty percent.
This was a mid-sized software company that had structured and crewed its teams in a way that served the product and company’s aims to be innovative and nice to work for. They had dictionaries in use by the writers, but there was no certainty that terms were used globally. This was frustrating for localization, and frustrating — because of the costs — for product management. I took it upon myself to unite things.
What seemed to work was befriending people, backed up with my genuine interest in making the thing work. It wasn’t just me, right, versus devs and UX, wrong. This was building trust and understanding over weeks. I suggested meetings specifically to discuss term usage: ‘Oh, I see — this is the chance to establish and own a new term that will be forever associated with this product.’ The upshot was I became a real bridge between the writers, the UX team, the localization team, and product management. The dictionaries became global, and the tools team wrote rules to make sure usage was universal. When the terms came to be submitted to the localization team, they made a point of remarking how easy it was to implement them as a termbase. So it got used!”
Firehead: What’s the one thing you’d want a team starting this work today to take away from that?
“Managing terms can seem daunting when it’s been ad hoc at best in an organization, historically. My best advice is to take the decision to do it properly and start somewhere, even if it’s one product or one area. It involves people with very different aims and skillsets. When I say that making friends with them works, you have to find what it is that drives people to make the term choices they do, whether that’s in UX, UI, marketing, or with other tech writers. Be interested and be willing to change. But also stand up for yourself. In effect, terminology management requires a shift in culture and attitude, and it needs you to be diligent.”
Ready to make your content AI-friendly?
The Content Forge, Firehead’s consulting offer in partnership with Content Pro Tech, helps small and medium-sized businesses structure their technical, marketing, and localization content so AI works reliably — not randomly — without the enterprise price tag. If the challenges Jerry described sound familiar, visit The Content Forge to see how we can help.

