Most people think the move from junior to mid-level happens with time. Maybe two or three years in, and it just happens on its own.
It does not. Plenty of BAs hit year five still working the exact same way they did in year one, just attending more meetings on their calendar.
Moving up is not about how long you have been in the role. It is about a specific set of skills, and almost nobody teaches them to you directly. You mostly learn them by watching someone else do them well, or by getting it wrong first.
Here’s what to work on;
-
Trusting Your Own Judgment
For example: a stakeholder is unavailable, and you need to move forward on a requirement that isn’t fully clear. The instinct is to stop everything until they respond.
A better approach: make your best, reasonable guess. Write it down clearly, so anyone reading it later knows exactly what you assumed and why. Then keep working. If the guess turns out wrong, you fix it – that’s not a failure, and it’s just part of the job.
-
Holding a Boundary
Imagine this: a stakeholder asks for a new feature to be included into this sprint. The easy answer is “yes” – nobody wants to be the person slowing things down.
The better answer: “This is a good idea. It’s not this sprint’s priority, and here’s why.” Then explain what it would push out and what it would cost, instead of just saying no with no reason.
Stakeholders remember the BA who protected the team’s time far more than the one who said yes to everything and then missed the deadline.
-
Connecting Requirements to What the Business Cares About
Here’s a scenario: “Add a filter to the search results page” is a requirement.
“Add a filter because customers are giving up after three failed searches, and it’s costing us sales” is something a manager can actually act on.
Try adding one line under every requirement you write: “These matters because ___.” If you can’t fill in the blank, you probably haven’t gotten to the root of the problem yet.
-
Bringing Answers, Not Just Questions
Instead of this: “What should I work on next?” hands the decision to someone else.
Better approach: “I think we should fix the checkout bug before building the new filter, because it’s affecting the revenue right now” makes the decision yourself and puts it on the table.
You might get NO as an answer. That’s fine. What people notice is that you are already thinking about what matters before you walk into the room, not waiting for someone else to figure it out for you.
-
Guiding a Meeting, Not Just Taking Notes
You have probably been in a meeting that went in circles for twenty minutes without anyone saying what was actually going on. The move that changes the room: “It sounds like the real question is this – can we settle that first?”
The first few times might feel awkward, especially with people more senior than you in the room. Watch how the people who are good at this say it and borrow their words until they start to feel like your own.
-
Choosing What Not to Do
Every team has more requests than time to build them. Helping the team decide what actually gets built this quarter and what waits is one of the clearest signs that you have grown.
That means asking simple questions out clearly: how much effort does this take versus how much it helps? Is this a quick win or a long-term bet? What are we willing to say no to, so we can say yes to this? It’s a decision you make in front of the stakeholders it affects, not one you make quietly on your own.
Closing Reflection
None of this shows up as a new title. It shows up at a specific moment that your manager stops checking every decision you make and starts asking what you think instead. That doesn’t happen on its own. Pick one of these skills and start working on it.
Which one are you already building? Which one do you still need to start on?
Drop a comment – I would love to hear where you are focusing.