Image designed by Freepik.

When I hire someone for a lifecycle or CRM role, I have two non-negotiables.

First: experience with any major ESP or CRM platform. Iterable. SFMC. HubSpot. Braze. I genuinely do not care which one. Despite what vendors claim, if you deeply understand one platform, those skills transfer. Data models and interfaces change. The underlying concepts don’t.

Second: basic HTML literacy.

I don’t demand mastery or perfection, but I want my new hires to be able to hand-code a simple HTML email from a blank file using a notebook.

Key Takeaways

• Lifecycle marketers don’t need to be developers, but understanding HTML makes them more self-sufficient when building, testing and troubleshooting campaigns.
• Knowing how email code works makes it easier to diagnose problems instead of relying on a visual editor or waiting for someone else to fix them.
• HTML knowledge is especially useful when working with dynamic content, personalization and reusable email components.
• AI can help write and troubleshoot code, but marketers still need enough technical knowledge to recognize when the output is wrong.
• For lifecycle marketers, HTML is less about writing every email from scratch and more about understanding and controlling the experience they’re sending.

---

What I Actually Expect (and What I Don’t)

What I’m looking for is an understanding of the fundamentals: how HTML is structured, how elements relate to one another, and how that structure affects the way an email renders.

I do not expect:

• Perfect syntax on the doctype tag
• Deep CSS wizardry
• Dark-mode sorcery
• Pixel-perfect rendering across every email client

I do expect:

• Why table-based layouts are still the standard
• Clean, readable nesting
• An understanding of how email HTML is different from web HTML
• The ability to look at code and reason through what’s broken
• Bonus points if you have usable comments throughout.

---

“But We Use Drag-and-Drop Now”

So do I. Drag-and-drop editors are so much better than they were even five years ago, and I’ve grown to really enjoy using them.

The issue is that drag-and-drop has limits.

Eventually:

• The template won’t support the layout you need
• The editor will introduce unnecessary wrappers
• You’ll need to insert a custom HTML block to get the effect you want

And when that moment comes, I want someone on the team who knows what they’re looking at.

---

AI Is Helpful. AI Is Also Wrong. A Lot.

My team uses AI to help with conditional logic, personalization rules, and even layout experiments. That’s not the issue.

AI can:

• Write conditional logic fast
• Scaffold a layout in seconds
• Save time on repetitive patterns

AI can also:

• Close an if statement too early
• Nest tables incorrectly
• Break mobile layouts in subtle ways
• Introduce rendering issues that only show up in Outlook

When that happens, the worst possible position to be in is trying to use AI to debug AI’s own broken code when you don’t understand HTML yourself.

Nine times out of ten, broken code is caused by an unclosed tag. But not knowing this, or how to find the missing tag, is what turns a five-minute fix into a long, painful afternoon.

If you can read the code and say:

• “Oh, this table is closing too early”
• “This conditional is wrapping the wrong element”
• “This nesting is why the layout collapses on mobile”

You’re back in control.

---

HTML Is Not About Coding. It’s About Thinking. 🍎

Basic HTML knowledge isn’t really about code. It’s about:

• Understanding structure
• Spotting patterns
• Debugging logically
• Not being blocked by tooling

HTML literacy teaches/reflects the kind of structural thinking that makes someone better at lifecycle execution.

---

The Bottom Line

I want my hires to know HTML because eventually something will break, the tool won’t do what they need, or the AI-generated code won’t work. When that happens, I want someone who can open the code, figure out what’s wrong, and keep moving.