Engineering thinks I’m design. Design thinks I’m engineering. And account teams think I’m expensive, because whatever I am, their budgets didn’t have a line for it.
None of them are wrong, which is what took me a while to sit with. The work is real and it’s needed and it still doesn’t map to any rung on the ladder I’m standing on. I’ve mostly stopped trying to give it a clean name, because every time I try, I end up back at the same problem, which is that the thing I do all day is made of pieces that belong to other people’s jobs.
I found that out the slow way, by trying to hire for it.
The instinct is to go find the people who already do this. And you can, sort of. Look across most creative teams and you’ll find pieces of it scattered around: someone in design who thinks in systems, someone in dev who cares about the creative, a QC mind who’s really doing governance without the word for it. The raw material is usually there.
But “sort of” is where it gets hard, and the reason is more subtle than just “the skill is spread out.”
Take someone already doing part of this work, say a designer who’s built real systems thinking into their practice. They’re good. They’re genuinely doing a version of the job. What they’re often missing is the new technical layer sitting underneath all of it now: how the tokens actually resolve, how the thing gets consumed by code and AI, where the system stops being a design artifact and starts being infrastructure. That layer is new enough that most people who’ve grown into the systems mindset haven’t grown into it yet.
So now you’re not looking at one role. You’re looking at two people who appear, to anyone reading a budget, to be doing the same job. One’s been doing “design systems” for years. One’s doing the technical architecture underneath. On paper it reads like redundancy. In practice it’s two different disciplines that happen to share a vocabulary. Try explaining that distinction to a resourcing conversation that just sees two line items pointed at the same deliverable.
That’s the real staffing problem. Not that the skill is hard to find. It’s that the field hasn’t drawn the line yet between the person who designs the system and the person who engineers the layer beneath it, so every attempt to staff it correctly looks, from the outside, like paying twice for one thing.
This has happened before
Anyone who was around for the UX/UI split will recognize the shape of this.
There was a stretch where “web designer” meant everything: layout, interaction, research, the visual, the flow, sometimes the front-end code. Then the work got complicated enough that one title couldn’t hold it, and it fractured. UX went one way, UI went another, and for a few years everyone argued about where the line was and who owned what. Job postings were a mess. Nobody could agree what to call anyone.
And then it settled. Not because someone published the definitive org chart, but because enough people did the work that the shape became obvious in hindsight. The titles caught up to the reality. These days the two have even started drifting back toward each other, because it turns out the split was a phase, not a destination.
I think design systems and creative engineering are in the messy middle of exactly that kind of split right now. The work has outgrown the titles we have for it, and we’re in the confusing part where nobody can quite agree what the new ones should be. That confusion isn’t a sign something’s broken. It’s what the beginning of a discipline looks like.
The part that actually excites me
I’ve always been a systems thinker with a code curiosity. The thing that lit me up was never the big creative idea on its own. It was what the system could do. How much you could make possible, how creative you could get inside a set of constraints you built yourself. Give me a clever restriction and a rule to design against and I’m happier than I am with a blank canvas.
For most of my career that was a slightly odd thing to be, in a field that rewards the blank canvas. It read as the supporting act. What’s changed is that the constraint layer is now the thing that determines whether any of it works at scale. The rules aren’t the boring part underneath the creativity anymore. They’re the thing that lets the creativity survive contact with volume.
Which is why I’ve become insistent about being in it start to finish. Not parachuting in to build a system and handing it off. Not getting handed a finished creative direction and told to make it reproducible. Both of those fail. The value is in the whole arc, from the first strategic decision to the last shipped asset, because the system decisions and the creative decisions are the same decisions, and splitting them is how you get something that’s technically clean and creatively dead, or beautiful and impossible to build.
Designers need rules. This is not an insult.
There’s a reflex in creative fields to treat constraint as the enemy of creativity. I understand where it comes from and I think it’s backwards.
The best creative work I’ve seen inside a system wasn’t limited by the rules. It was freed by them. When you’re not re-litigating the base color or the spacing scale on every project, you get to spend your actual attention on the thing that matters. Constraints move the creativity up the stack. They don’t kill it; they relocate it to where it’s worth more.
But here’s the part I never want to lose: rules with no vision on top of them are just tidy nothing. The system isn’t the point. The system is what protects the point. You still need the big vision thinking, the taste, the person who knows why one direction is better than another. What I’m arguing for isn’t replacing that with structure. It’s giving that a foundation strong enough that it can actually scale past one hero project.
Structure without vision is sterile. Vision without structure doesn’t survive its own success. The role that’s emerging is the one that refuses to pick.
So what do we call it
I don’t have the clean answer, and I’m suspicious of anyone who says they do this early.
What I know is that pretending the role doesn’t exist has real costs, and I watch them land every week. You can’t staff it, so you burn out the handful of people holding it together. You can’t budget for it, so it reads as overhead until the timeline it saved becomes visible. You can’t promote into it, so the people who are best at it eventually leave to find somewhere that has a word for what they are.
The field will sort out the titles the same way it sorted out UX and UI: by enough of us doing the work, out loud, until the shape is undeniable. That’s part of why I’m writing these at all.
If you’re in the same gap, too technical for design, too design-minded for engineering, you’re not miscategorized; you’re early. The name is coming the way it always does, a few years after the job it describes.