Summary: This is my case for why senior UX researchers don’t need a management title to lead. By staying close to the work and showing up early with clear questions, ICs are often better positioned to drive strategy, shape roadmaps, and become indispensable partners in decision-making.
Have you ever been in this situation? You join a team, dig into the product, get to know the users and the roadmap. You run research that challenges assumptions, highlights friction and brings clarity to decisions that used to be based on gut feeling. A few months in, maybe a year, someone taps you on the shoulder and asks, “Have you ever thought about managing a team?”
It’s a familiar moment for a lot of us experienced UX researchers. In many orgs, management is framed as the natural next step: the reward for good work, the sign that you're ready for more responsibility. And for some, that’s exactly the right path. But for others, moving into management can feel like a step away from where the real influence lives. In my career, I've learned that not all leadership looks like people management, and not all impact comes from a title change.
As a senior IC researcher, you can absolutely shape strategy without needing headcount. You can influence by clarifying the problem before it's permanently on the roadmap. You can frame user behavior in ways that shift business decisions. You can get invited into high-stakes conversations not because of hierarchy, but because of timing, trust, and your ability to clear up ambiguity. You can do it by staying close to the work, not sitting above it.
I don't know about you all, but I don’t want to manage people out of their blockers. I want to help teams prevent the blockers in the first place.
I want to be embedded in the messiness. I want to be the one helping connect vague business goals to actual user needs. That’s where the impact is. That’s where the leverage is. And for me, that’s what leadership looks like.
In this article, I'm sharing why staying an IC has given me more leverage than management ever could and how senior researchers can lead strategy with our boots on the ground floor.
Some History
UX research has always lived in the tension between being a strategic enabler and an optional support function. Some teams treat us as foundational; others treat us as a nice-to-have.
In the early 2020s, there was a stretch of time I often refer to as the "easy money era," when teams could build freely, fail often, and try again. It was cheap to launch new features, and UX had the space to test and iterate without too much scrutiny. Also, PMs had room to be wrong and pivot without real consequences.
Then the environment changed. Budgets tightened. Teams were expected to do more with less. Leaders wanted certainty, not just speed. And the tolerance for failed experiments dropped fast.
This shift played into the typical PM mindset. It favored confident answers, even when those answers were based on little to no user-centered data. That’s when I started to notice UX researchers getting a bad rap for being bloated or slow. We weren’t always confident without first engaging with actual user behavior. And in that moment, it didn’t matter that we were consistently proven right in the long run. What leaders wanted was speed, not accountability.
UX research functions were hit hard. Hiring freezes. Paused programs. Reduced headcount. And for the teams that kept their researchers around, the ask became simple: deliver answers, fast.
But out of all this transition came a rare kind of opportunity for IC researchers. It was a moment when clarity, insight, and framing were in high demand. The cracks in the product-led, intuition-first mindset began to show. Initiatives stalled, user trust eroded, and solutions missed the mark. If you were close to the work, if you knew how to talk to stakeholders, if you could translate vague asks into sharp research questions, you suddenly had a seat at the table. Not because someone gave it to you, but because the team needed the outcomes UX research could provide.
What Actually Moves the Needle
A lot of companies say they value research, but what I’ve discovered they really value is confidence. And if you’re not careful, research becomes the thing that happens after everyone’s already made up their mind.
Does this sound familiar? You’re handed a solution and asked to “go test it.” Or worse, to “get a quick user quote to support this deck.” Research becomes reactive. A checkbox. A source of bullet points for someone else’s story.
I’ve learned the hard way that if you wait for permission to be strategic, it may never come.
The "Customer Representative” Trap
We all know that when PMs are under pressure to deliver results, they often shortcut the user data. They do things like summarizing Slack messages and report them as insights. They reference something a sales rep said last quarter. They say things like “our users want this,” when what they really mean is “someone important asked for it.”
It’s not that they’re anti-user. They’re just moving fast, and real user research can seem slow unless someone shows them a better way. And the concept of a “proxy user” is possibly the most dangerous idea I've heard in a long time.
That’s where being a senior IC researcher becomes super valuable. You don’t need formal authority to change direction. What you need is access.
Here are some things I’ve done as a senior researcher that have made a huge impact:
Sit in a roadmap planning meeting and say, “Before we commit to that, can I show you what users are actually trying to solve?”
Reframe a feature spec into a hypothesis we can test this week instead of waiting until next quarter.
Take a vague business goal and show how it maps (or doesn’t) to actual user behavior.
Work across teams, not just within a direct report structure.
You don’t have to manage people. You have to manage attention.
Imagine yourself as the person helping everyone focus on what matters most, before they invest in what would never work in a million years. And over time, that influence compounds. People start asking for your input earlier. You get pulled into strategic conversations. You don’t need a team under you to be seen as a leader. You just need to consistently bring clarity to the table. That’s what moves the needle.
Real World Tactics That Work
Being a senior IC researcher means knowing how to shift the conversation quickly, respectfully, and often. You’re not just delivering insights. You’re helping shape decisions.
Here are some things I’ve learned to do that seem to be effective in most scenarios:
1. Ask Reframing Questions
Requests often start with a deliverable like this:
“Can you test this prototype?”
“Can you run a quick survey on this?”
“Can you help us validate our direction?”
If you say yes to these too quickly, you risk reinforcing the idea that research is just another box to check.
I’ve learned to reframe with questions like:
“What are we trying to decide?”
“What’s the risk if we don’t get this right?”
“How will we know this worked?”
This isn’t about saying no. It’s about clarifying the real requirements. Often, the request is a proxy for an uncertainty they don’t know how to name. As researchers, that’s our superpower. To help people name what matters before they invest in the wrong thing.
2. Think Outcomes Over Artifacts
Stakeholders love solutions. But users don’t care about solutions; they care about outcomes. One of the most useful mindsets I’ve adopted comes from Jobs to Be Done. It’s not that I think the framework is uniquely good. It’s that Jobs to Be Done is widely recognized and respected by many MBA types. It acts as a shortcut signal that you’re serious about the business, rather than being seen as just another emotionally driven UX stereotype.
Instead of asking, “How can we improve this feature?” I ask, “What job is the user hiring this product to do?” That shift from feature to function completely changes the conversation.
A stakeholder might ask for a new onboarding flow, but the user’s job might be to feel confident that they won’t break something. The requested feature might be a dashboard, but the real job is to stay informed only when action is needed.
As a lead IC, I don’t just test what’s in front of me. I help the team interrogate whether what we’re building actually serves the job the user is trying to get done. That’s not overstepping. That’s research doing its job.
3. Get Good at Moving Faster
Sometimes you can't run a full study but you still need to bring insight to the table. Its especially important that you do so before the team makes a costly decision based on PM-style assumptions.
In those moments, I look for whatever data we do have. That’s right. Old-school secondary research.
Findings from previous usability studies stored in the research repository
Open-ended responses from relevant past surveys
Notes from stakeholder interviews conducted for a related product launch
Themes pulled from customer support tickets and chat logs over the last quarter
I recommend pulling signal from wherever you can find it, then using quick, discount usability research methods with whatever time remains. This allows you to triangulate and synthesize quickly, define clear themes, and tell the story in a way that is both actionable and grounded in data.
A Quick Case Study
One of the clearest examples of this came when I joined a team supporting a internal tools org focused on pre-sales, technical services, operations, and infrastructure. UX design was well understood, but UX research was not. When I got looped into projects, they were already scoped, deadlines were already set, and I was asked to “validate” things that came out of spreadsheets and strategy decks.
I decided to change the way I showed up.
Instead of asking, “What do you want me to test?” I asked, “What’s the cost if this fails?” Instead of saying, “We need more research,” I said, “We need more confidence before we spend another six figures building this.” That shift in language landed.
I started reframing UX research as a way to de-risk investment. Not just user-centered, but cost-conscious.
I made success measurable in terms stakeholders actually cared about: time saved, rework avoided, progress made, and confidence in direction.
Soon, people were saying things like, “This research protected our roadmap.” That feedback became the clearest sign I was having real impact. And I did not need a management title to make it happen and you don't either.
How to Work Across Titles
One of the most underrated perks of being a senior IC researcher is that you don’t have to stay inside the lines. Your value isn’t limited to a single team. You’re not evaluated by how many 1:1s you hold.
You can move toward impact wherever it shows up in these 2 ways:
1. Prioritize who you support based on opportunity
Every company has teams that just want a green light and teams that are actively wrestling with strategy. I look for the ones that are open to insight, not just focused on delivery. I prioritize my time accordingly.
I ask questions like:
“What problem are you trying to solve this quarter that you’re unsure how to approach?”
“What’s something users do that surprises you?”
“What’s your team’s biggest blind spot right now?”
The teams who love those questions? That’s where I spend time.
2. Build relevance through repeat exposure
The best way to grow influence is to consistently reduce uncertainty for the people who are trying to move things forward.
I stay close to:
PMs trying to hit KPIs they don’t fully understand yet.
Designers second-guessing if a flow really solves the core task.
Engineers quietly wondering if this ticket even makes sense for users.
I show up. I share insights in Slack threads and Figma comments. I talk in terms of tradeoffs, not correctness. I frame things in ways that help decisions happen faster and smarter.
Do that often enough, and you don’t need to claim influence. You become part of how decisions get made by default.
Conclusion
So no, I don’t manage people. I don’t write performance reviews or sit in calibration meetings or build headcount plans. But I’ve helped set strategy. I’ve shaped roadmaps. I’ve reframed entire product directions. And I’ve done it not by climbing up, but by going deeper into the work, into the problem space, and into the questions no one else is asking yet.
Leadership doesn’t have to come from a title change. It can come from being the person who consistently brings clarity when everything else feels messy. The one who helps teams feel smarter, more grounded, and more confident in what they’re building and why, using real data to guide them. That’s the kind of influence I want. And that’s why I’ve stayed an IC.
The longer you wait, the harder it becomes to change direction. Get in early, even if you don’t have a formal project assigned yet. Offer clarity when people are still vague. Ask questions that connect the business goals to user behaviors.
You don’t need to be a manager to be a strategic partner. You just need to help make the next step smarter than the last one.
Love this! I actually think senior ICs are in the one the best positions to drive product strategy. We are customer obsessed but unlike PMs the product isn’t necessarily “our baby” and we can make more logical decisions based on the data.
I love what you said about the integrity of a senior designer. I will read all this again tomorrow. Thanks for sharing this story.