No PM on the Team: What Is a Senior Supposed to Do?
I recently passed my probation period, and in a 1-on-1 my manager said, "I'd like you to be more proactive about exploring product issues."
That caught me off guard. I was writing code every day, fixing issues, and pushing projects forward. How was that still not proactive enough? It took me a while to understand what he actually meant.
Everything Running at Once
Passing probation didn't mean less pressure. If anything, it meant juggling even more things at once:
| Item | Nature | What I Can Control |
|---|---|---|
| Issue fixes | Daily work, with output measured partly by volume | Keep a steady pace |
| Project A | A formal project, but the user side is slow to confirm requirements | Limited — mostly waiting for replies |
| Product research | Proactively looking for ways to improve the product | When to deliver, how to present it, how to report it |
When you're switching between three or more things in a single day, the exhausting part isn't the hours. It's the constant context switching.
Then I Realized: We Don't Have a PM
I knew that from day one, but I had never really thought through what it meant.
We have a BA (Business Analyst) who handles requirements analysis, but nobody really owns questions like: Where does this stand? Who's blocked? Should we reprioritize?
At my previous company, the PM or Tech Lead handled all of that. I just had to check the backlog, confirm priorities, clarify product requirements, and focus on writing code. The spec came in, I built it. If I got stuck, I told the PM, and they handled the rest.
Now that role doesn't exist. So who picks it up?
The Senior.
Senior Isn't PM, but You Need Ownership
At first I didn't get it. I'm an engineer, so why should I be chasing users for replies, proactively reporting blockers, or aligning priorities with my manager? Isn't that PM work?
But that doesn't mean a Senior is supposed to replace a PM by owning the team's roadmap, handling cross-functional coordination, or tracking everyone else's progress. The real point is simpler: you can't treat blockers in your own work as if they're someone else's problem.
Once I compared the two, the difference became clearer:
| PM | Senior | |
|---|---|---|
| Whose progress to manage | The whole team | Your own lines of work |
| Deciding what to build | Roadmap, priorities | Don't decide, but do align |
| Chasing stakeholders | Everyone involved | Your own blockers |
| Accountable to | Business goals | The features you own |
A Senior doesn't need to manage other people. You just need to keep your own three or four lines from getting dropped. Report blockers proactively instead of waiting in silence. Have opinions about the features you own instead of just waiting for instructions.
That's called ownership, not PM.
It's Not That My Previous Job Was Too Easy
For a moment, I wondered whether my old company simply had lower expectations for Seniors. But the more I thought about it, the more I realized that wasn't the issue. The environments were just different.
My previous company had a PM shielding me from coordination work, and the product line was simpler. There, "Senior" was defined more in technical terms: if you could solve hard problems, that was enough. In my current environment, part of the job is also pushing product progress forward, because nobody else is going to do it for you.
In a lean team, that's normal. It's not unreasonable. I'm just not used to it yet.
What I Actually Did
Once I figured this out, I made a few changes:
Prioritize and align with the manager. I listed everything by priority and asked, "Does this order look right to you?" It's just one message, but it changes the posture from passively waiting for instructions to actively managing my own work.
When blocked, switch lines, but leave a record. If the user on Project A isn't responding, I ping once a week and leave a paper trail. My manager knows the blocker isn't on my side, and I can use the freed-up time to push product research forward.
Don't context-switch too often. Use priorities to decide what to work on today instead of touching everything a little. Record blocked lines, set them aside, and switch back once they unblock.
Final Thought
All of this sounds basic, but for an engineer who's used to having a PM handle coordination, it takes time to adjust. Under pressure, it can feel like you're doing work that isn't yours. But at least on a team without a PM, this is part of what being a Senior means.
On a side note, I first sorted out the thinking behind this post through conversations with AI, then tracked it through a personal system I built for daily logging and feedback, which I call Pasiv. Vibe coding isn't just about using AI to build projects. It also includes using it to untangle where you currently stand.