If you spend enough time working in enough environments, you’ll eventually learn a thing or two… maybe even three. Here’s the one that's mattered most in my career.

Over the years, I held the 'Creative Director' title at enough places that I had to finally confront an uncomfortable question I couldn’t shake: What does my job title actually mean? Even as I’ve progressed beyond that title, the question has lingered, and (spoiler alert) seniority doesn't make it any easier to answer.

My first official CD role was at a small, scrappy place, where I had to solve a number of small, scrappy-place challenges. After this, I worked in much bigger settings where I found myself solving many of those same challenges, but on a grander scale. I've done client-facing, pitch-heavy work where you're juggling five brand voices at once. I've done in-house work where it's one brand, all-day/errday, along with the organizational complexity that comes attached. Different stops, different titles, different challenges…different everything.

At some point it started to feel less like a career arc and more like the parable of the blind men and the elephant: everyone touching a different part of the animal, arriving at a completely different description. None of them technically wrong. None of them entirely correct.

And really, that’s the "Creative Director" title in a nutshell. Same words in the email sig. Completely different job depending on where you stand.

After I’d moved through enough environments, I found that the people who struggle — like really struggle, not just had-a-rough-quarter struggle — tend to have a fixed picture of what the job is supposed to look like. A playbook from their last place, maybe, or a strong attachment to a specific kind of work; a specific way of doing things. When the context doesn't match that template, they spend their energy trying to force the fit, instead of reconsidering their approach.

The question that travels

Eventually, I learned to stop walking into new engagements thinking first about what the brand needed, or what the campaign should feel like, or what the output calendar looked like. Instead, I started with one simple question (two sides of the same coin, really): What are we actually trying to fix, and how will we know if it worked? Not one or the other. Both. Together. Before anything else.

This sounds almost embarrassingly simple, but unfortunately it’s not.

Most teams skip at least one of these two interrelated questions… sometimes both. They'll have a vague sense of the problem, like ”our brand feels dated" or "we're not breaking through in market,” but nothing with enough specificity and organizational alignment to make it solvable. Or, they'll dive straight into execution with a clear-enough problem statement, but no agreed-upon criteria for what “right” actually looks like. When the work comes back, everyone has a different read on whether or not it succeeded. The review goes sideways. The revisions pile up. Nobody's technically wrong. But nobody’s entirely correct.

Getting alignment on both things — the problem and the proof — before anyone ever opens a design file is what transfers across every environment I've worked in. Not design preferences or a specific tool stack. Not even a particular management style. Just those two questions, asked early enough to actually shape the work.

Where it gets more interesting

The most surprising thing about this approach is that it doesn't just travel across job titles; it transcends entire team boundaries.

At both Givelify and Celigo, I worked in environments where brand/marketing and the product design function were organizationally separate. Different leaders, different priorities… at times, radically different ideas about what the company was trying to be. That structural separation has a predictable tendency to create friction. The brand team produces guidelines the product team quietly ignores. The product team ships things the brand team finds out about after the fact. Neither side is trying to be difficult. They're just operating from different frames, and nobody's done the work to reconcile them.

What I’ve found is that this same foundational question can serve as common ground between different camps. What are you trying to fix, and how will you know if it worked? When you can sit with a product designer or UX lead and ask that question (not as a brand-policing exercise, but an actual, earnest inquiry), the conversation shifts. It stops being about whose preferences win, or whose team is higher up in the pecking order, and starts being about the underlying problem you're both trying to solve. More often than not, everyone starts to realize it’s actually the same problem, just approached from different angles.

These conversations, and the collaborative relationships that grow from them, have resulted in some of the feedback I’m most proud to have received in my career: feedback that’s actually come from people outside of my core team. Product designers, UX leaders, and customer enablement folks who have all said things like: I didn't realize at first that we were solving the same problem, but once I did, it changed everything.

That's not a brand win. That's a systems win. And it only happens when everyone's oriented around the same goal.

What this actually requires

This kind of approach requires letting go of the idea that your title gives you authority over a particular slice of the work.

Brand people who treat "brand" as territory to protect, rather than as a capability they bring to a shared problem, tend to create exactly the dynamic they're trying to avoid. Same with design. Same with product. When any function treats its domain as something to be defended rather than contributed, the organization fragments along those lines. The work gets worse. First slowly, then everything all at once.

The alternative is to hold the attachment to your discipline loosely, but maintain a tight grip on your thinking and skillset. Know your craft deeply (that depth is real and it matters), but lead with the problem. Ask the upstream questions. Be wise enough to accept that having no pride of authorship is very different from not caring. Build things that other people can actually use and build upon. Not work that only you can produce or interpret.

I’m particularly proud of the rebrand I led at Celigo, even though I don’t think of it as being primarily a brand project. Before a single concept was sketched, we had to answer two things: what problem are we actually solving (repositioning for enterprise without abandoning mid-market), and what would tell us we'd solved it (internal alignment, external perception shift, ability of the new positioning to penetrate an upmarket audience and net new logos). Those weren't easy questions to get agreement on. But once we had them, every creative decision had a clear filter. The work followed from that. It didn't precede it.

This is true of pretty much everything I've done that actually worked, even if I only realized it in hindsight for some of my earlier projects. The title changed. The industry changed. The team size, budgets, timelines, and tools all looked different. What didn't change was the usefulness of knowing what problem you're solving, and making sure everyone agrees on what the right answer looks like before the work starts.

That question, asked consistently and early enough, is the closest thing I've found to a job description that actually travels.

The title is what's on the door. The job is what's on the other side of it.