My current job title has “Engineer” in it. It wasn’t always that way.
I started in this industry as a designer. And even as my role shifted, even as the titles changed, that word — designer — never really left. It stayed with me. Interwoven into how I think, how I work, how I solve problems.
But I also knew I was doing more than just design. I was building systems. Refactoring flows. Writing docs. Writing code. Helping teammates reframe the work, not just complete it. So when I landed at Webflow and saw my title — just “Engineer,” no “Designer” attached — it didn’t feel wrong. But it didn’t feel complete either. Because the work I do has never (and will probably never) fit cleanly inside a box. And I know I’m not alone.
Far too often, I see people shrink themselves to fit their job titles. Designers who throw their hands up the moment pixels need to become code. Engineers who instantly back away from anything visual — “I’m not a designer. I can’t draw.”
(Sidenote: To every engineer who’s ever customized their terminal theme, tweaked their syntax colors, or spent half an hour choosing a font for their README: You care about design. You just don’t call it that. You have aesthetic taste! Back to the post).
Boxes and bridges
I’ve always considered myself a designer — regardless of what my title says. Not because I studied graphic design (I didn’t). Not because I’ve mastered the pen tool. But because I solve problems.
Whether I’m adjusting padding or editing copy, naming a variable or renaming a Slack channel — it’s all the same to me. I’m trying to make something clearer, smoother, better.
Titles are boxes. They’re useful until they’re not.
They help set expectations. But they can also set limits — especially when we start to believe we only belong inside one.
Design. Engineering. Product. Management. Most people treat those like separate boxes. I see them as bridges — ways to move between ways of thinking. Different lenses for solving the same problem.
The more bridges I’ve built between those worlds, the more fluently I can move. The more clearly I can see. The more effectively I can help.
The job — whatever the title — isn’t about mastery in one domain. It’s about fluency across many.
And that kind of fluency doesn’t come from doing what’s expected. It comes from doing the work no one asked for. From observing, learning, and filling the gaps — over and over — until one day you look up and realize:
You didn’t just learn the role. You learned how the whole thing works.
Kitchen works
I didn’t learn this in tech. I learned it in kitchens.
My first jobs were in restaurants, where everyone had a lane. Prep cooks in the back — chopping, portioning, getting ahead of the rush. Line cooks in the front — cooking to order, moving fast.
Most people stuck to one lane. But me? I floated. I prepped. I cooked. I cleaned. I jumped in wherever I was needed. It wasn’t a strategy. It wasn’t ambition. It was just… the gap. And somehow, I became the one who filled it.
In doing that, I learned how everything connected. How everyone connected.
I saw how the prep team set the line up for success. How line cooks relied on prep decisions. How timing, trust, and teamwork weren’t just ideals — they were survival.
I learned that being useful meant understanding both worlds. And that filling the gaps wasn’t just about covering shifts — it was about helping carry the weight.
Did those restaurants take advantage of my flexibility? Maybe. Honestly, I don’t care. (Too late for that.)
What I remember is how it felt to be trusted. To be needed. To be the person who helped the team work better — not by being the best at any one thing, but by knowing enough to help with all of it.
Solving problems
When I transitioned into tech, I brought that same mindset with me. I never saw myself as just front-end, or just back-end, or just product-adjacent. I just… helped.
Sometimes that meant adjusting padding in Figma (or... Sketch at the time). Sometimes it meant debugging an API. Sometimes it meant rewriting a kickoff doc so everyone could understand what we were trying to do.
I didn’t always have language for it.
Then one day, I remembered a talk I watched years ago — a designer giving feedback on a sign-up form. (I can't find it anymore, my apologies. It's been over a decade, and I didn't take notes back then).
Most of the feedback was typical: spacing, copy, color contrast, button states.
But then the designer asked something that stopped me in my tracks:
“Do we even need this form in the first place?”
That was it. That was the unlock.
Because design isn’t about making things pretty. It’s about solving problems. And solving problems means stepping outside your role, questioning what’s in front of you, and doing what’s actually needed.
That moment didn’t just give me clarity. It gave me permission.
Toolkit
These days, my toolkit keeps expanding.
I write production code. But I also write meeting notes. I maintain docs. I build timelines. I fix naming conventions. I help people talk to each other.
Some people call that “soft skills.” I don’t. They’re just skills. And they matter. A lot of them show up under other titles — Product Manager, Technical Program Manager, Engineering Manager. (A lot of managers…)
I don’t have those titles. But I borrow the tools anyway. Not to be a jack-of-all-trades. Not to prove anything. But because they help me do the job better — whatever the job is.
Because this isn’t filler work. This isn’t bonus work. This is the work.
I’m a designer
I’m a designer. Not just of pixels — but of process. Of clarity. Of connection.
I’m a maker. I like building things. Fixing things. Tinkering toward something better.
I’m an unconventional, but highly effective, problem solver.
I don’t belong in a box. I’m not here to fit. I’m here to fix. And I don’t need permission to care.
And maybe the reason I’m able to do what I do is because I don’t trap myself in any one identity.
Most people let their title define what they do. I let what I do redefine the title. Because most of us aren’t just our roles. We’re just people — trying to do good work, helping each other out.
So if your title says “Engineer,” or “Designer,” or “Writer,” or “Manager” — great. Just don’t let it be a box. Let it be a starting point.
Because you don’t need permission to solve problems. You just have to care enough to try.