A few days ago, a childhood friend texted me out of the blue to tell me about a pork tenderloin sandwich.

Now, if you haven’t spent much time in Indiana, you’d probably think that was weird, but Indiana pork tenderloin sandwiches are a thing of legends. The secret is taking an entire 9 pound tenderloin, pounding it flat until it wouldn’t fit into the trunk of your car without folding it first, then deep frying it in what I imagine is a hot tub-sized fryer.

You serve it on one of those tiny hamburger buns with a tomato and some lettuce, just to pretend that this is a sandwich and not an endurance challenge.

Then we started talking about what’s been going on the last few years. He’s in quality management at a manufacturing company now. I joked that as a former tech writing teacher, I’m also sort of the QA/QC guy of marketing teams I work on, especially when we’re all seeing so much work farmed out to AI agents.

He said something that stuck with me, the kind of little aphorism that keeps ringing every time it’s relevant. Compliance guy is important guy.

QA, Compliance, Writing

I’ve posted about some of my process documentation and onboarding strategies before. A lot of that comes from teaching and assignment design strategies. Generally, an assignment is split into two cognitive loads: the thing you want to assess and the other stuff.

For instance, my tech writing classes would often do a post-mortem or redesign of documents that existed on campus. I was assessing their understanding of document design, rhetorical strategies, and written language. I was not assessing their ability to find documents or submit the assignment using whatever tool the university had subscribed to that year. The project instructions were very detailed on the processes I wasn’t grading, so the cognitive load of the assignment would be focused entirely on what I was grading.

QA in document and marketing communication management is similar. Teams have a lot of members with different specialties. The cognitive load of getting work done is spread across the group. But, since everyone has their own list of separate things to work on, it isn’t always possible to have every specialist touch a project.

That’s too abstract. What do I mean?

A good example is the <br> tag in html—or the various <h*> tags, <blockquote>, and <b> vs. <strong>. If you aren’t a web person, these might just be different ways of making text look the way you want. <br> adds empty space above or below something. <h1> is large and bold, while <h7> is regular-size and sort-of-bold. <blockquote> will indent your text.

Or, at least, those are the rules on most browsers. Those tags all mean something, and the visualization is just a holdover from the ancient days of html, before we relied on css.

Why does it matter?

Well, if you’re not a web person and you just want text to look a certain way, you might end up writing a heading that looks like

That might get you a look that you want, but it’s extremely difficult to maintain, especially when one person formats their headings that way, while another uses <p style="font-weight: 500; font-size: unset; margin-left: 3rem;"> and another uses <h2 class="pre-cta-heading">. They might all look the same (or nearly the same), but doing a site-wide audit involving those headings or styles becomes a nightmare very quickly.

Why does this matter?

I’m always thinking about the big picture over the long term. That’s a teacher thing. You think of your assignment sheets as part of a course-long sequence, which might be anywhere from eight to sixteen weeks. You create a full content strategy to cover every course you teach, whether you’re doing five technical writing courses a term or a mix of subjects. You plan every contact point as part of some larger narrative that students will experience over a defined amount of time.

And, you audit your work. When you realize some language is unclear or some processes are missing steps, you revise content. When your institution changes the tools it uses for content management and grading, you revise content.

But revision isn’t just opening up each document, making changes, and hitting “save.” At OIT, I taught a dozen different courses, several of them on both 8- and 10-week timeframes, and all of them had to plan around holidays and major events in the fall, winter, spring, and summer. So, a dozen courses with four variants each. Each had three to five major projects. Back of the envelope, we’re talking about {12 x 4 x [3, 4, 5]} project sheets to revise whenever one of those major changes were necessary, so ensuring conformance to some technical and design standard was very important.

The same is true outside of academia. I manage the pages for 70 or so products, and a few hundred knowledgebase resources. A common element on all of those pages recently quit working and needed to be changed on every single one. (Yes, this is an ideal place for a shortcode or reusable block or something else, but that decision is above my paygrade.) Thanks to some QC efforts over the last year, we could just do a global find/replace across the website database and change all of the affected elements but not similar elements on other pages. A task that would have taken weeks to do manually took less than ten minutes thanks to a little extra effort and regular audits.

There’s still a mountain of other stuff to standardize from before my time here, but at least now we’ve got a business case for explaining why it’s worth insisting that folks pay attention to minor details like html tag structure.