Business Analyst Levels: What Do Those Familiar Labels Actually Mean?

Hello, folks!

Below I’ll share my view of how business analyst levels (or grades) work in IT. Let me immediately explain why I call it my view: this is not some universally obvious framework. Companies either have their own grade/competency matrix (and more often than not, it’s inherited from whoever introduced the concept first after doing some diligent Googling or talking to colleagues), or they don’t, in which case people are evaluated by gut feeling (for example, when an employee asks for more money and you can get away with the path of least resistance — slap a fancy new label on them so they can feel more confident). There are also sometimes government-level standards, but almost everyone happily ignores those.

The main thing we’ll be working from:

Junior — an employee who is rather limited in their ability to work independently:

• Mistakes are to be expected.
• Can handle simple tasks. More complex/risky tasks (this is however interpreted differently everywhere) are beyond them.
• Receives tasks in a heavily fleshed-out, almost step-by-step form.

Important: a junior is not someone who can’t do the job — such an employee is of little use outside an internship. They know how to do their thing, but someone needs to actively (or, more precisely, proactively — we’ll get to that later) keep an eye on them: correct them, guide them, occasionally feed them treats and slap their wrists.

Middle (Staff) — works independently with a reasonably acceptable number of screw-ups; turns to a sensei for help in difficult situations. Accordingly, a middle can handle most tasks except the most challenging ones, and can work with tasks of a higher level of abstraction.

Senior — fully independent and capable of handling complex situations. Naturally, makes fewer mistakes than a middle, can handle tasks of any kind, and — importantly — can formulate or accept tasks at any level of abstraction and propose solutions.

Lead — organizes (plans, distributes, monitors, evaluates, feeds treats and slaps wrists) the work of the team, including specialists at all levels. As a rule, they are also capable of rolling up their sleeves and working as a senior when necessary.

I like this example I came across a long time ago:

What determines a grade and drives growth?

1. Production experience

In my view, this is the key factor — without real-world experience, you simply won’t progress to the next level. You cannot successfully navigate real situations without a history of practice to draw on when looking for solutions. Theory, unfortunately, is not enough, no matter how well-read you are.

That’s why a course that magically produces middles straight out of the box (yes, I’ve seen such claims on the Internet) is bullshit — unless the course actually throws you into internships on real projects for a year or two.
And that’s also why practical training projects (if they are part of the training or run alongside it) are useful: even if they’re simulations, they are where you’ll step on a whole pile of rakes and build at least some empirical foundation. They won’t turn a junior into a middle, but they can move them along the growth scale.

Most often, I’ve seen 1 year of experience (if you're gifted) or 2 years (in normal mode) given as the point at which someone reaches a level where they can independently handle most tasks. By the same logic, 3–5 years (depending on the person’s brilliance and how deeply they are engaged with the profession) usually determine the path to senior.

2. Soft-skills development

In my view, soft skills are one of the most important things for progressing through the grades, especially for an analyst.

Soft skills are also developed through experience — preferably experience gained consciously and with se-lf-reflection — but they can also be developed in advance, especially if you have some work experience in general rather than going straight from school into IT.

This is not a comprehensive overview of all the skills and qualities an analyst needs, so I’ll focus on the key ones that signal growth most clearly.

Proactivity. Let’s start with the boring definition: the ability to independently initiate actions and events.

Essentially, it means shifting the focus from “What was I told to do?” to “What result do we need to achieve, and what can I personally do to make that happen?”

A reactive employee lives in the “stimulus → response” paradigm. As we move toward proactivity, we insert conscious choice and responsibility for the final outcome between the stimulus and the response.

A proactive analyst is a do-it-themselves kind of person. For example:

• If the task is unclear, they clarify it until it is sufficiently clear — because they are the one doing the task and the one responsible for its consequences for themselves, the team, and the project.
• If they hit a blocker, they get off their ass and go solve it, poking around in different places instead of merely escalating the fact that there’s a problem and sitting there with their hands folded, waiting for someone else to fix it.
• They think through how requirements should be presented based on how useful the format will be for approvals, development, and testing — rather than because “that’s how we’ve always done it.”
• They dig into the needs of customers and users instead of acting as a glorified messenger for whatever they’ve heard.
• They don’t wait for a stakeholder to bring requirements to them on a silver platter. They ask questions, push people toward decisions, and connect the right people with each other.

Reactivity is an acceptable mode for a junior, but nonsense for a senior. An employer wants middle- and senior-level specialists to handle assigned tasks independently, rather than painstakingly follow instructions. And to do that, you need to take ownership of the task — we don’t sit passively around when something important in our personal lives needs solving, do we?

Responsibility. A responsible specialist is a predictable one. And in my experience as a manager, that is critical.

Imagine you’re a manager and your daily routine involves pinging each of the ten people on your team to ask whether they forgot their deadline, whether they remembered all the tasks you threw at them, whether anything is blocking their work, and so on.

You build yourself a system of reminders and constantly monitor your employees. On top of all the other work you have to do on the project, this piles a very real amount of stress onto your plate.
Now imagine that someone joins the team who gives you peace of mind — someone you don’t have to constantly chase:

• They don’t forget or overlook tasks.
• They keep the deadlines they committed to. If something goes wrong, they either sacrifice some personal time and still get it done (the important thing is not to make this the default operating mode), or they come to you in advance, explain the problem, and propose a solution.
• They acknowledge their mistakes (which is perfectly normal — we’re not robots) and work on them.

A manager’s dream, right?
And the funny thing is, this doesn’t require all that much from us — just paying attention to this aspect and taking seriously how we are perceived by others in this regard.

Working with uncertainty. Another important factor that determines what level of task we can be trusted with.

A junior usually needs to be given solutions rather than problems. This means the person assigning the task should think through the possible solutions, the plan for the chosen solution, and how to handle exceptional situations.

To some extent for a middle, and certainly in full for a senior, it should be enough to provide a problem statement or an abstract task, relying on their independence, accumulated experience, and problem-solving skills:

• “Make sure the team has enough work for the next sprint” (rather than “Write stories 1, 2, and 3 — including titles, acceptance criteria, wireframes, and diagrams A, B, and C; put them into Confluence; bring them to refinement; …”).
• “Run a discovery.”
• “Figure out what the client is complaining about and solve the problem.”
• “The team says they systematically don’t like the requirements — sort it out.”

In other words, as someone’s grade increases, they should become increasingly capable and willing to reduce uncertainty independently. And uncertainty comes in many forms: there may not be enough information; different stakeholders may provide conflicting information; the problem itself may be unclear; and sometimes we don’t even know what outcome we need. A mature specialist does not perceive all of this as a blocker along the lines of “Until someone tells me exactly what to do, I can’t work.” Instead, they build chains of reasoning like this: “Here’s what we know for sure. Here’s what we assume. Here’s what we don’t know yet. Here’s how we can find it out. And here’s a decision we can already make based on the information we have.”

As a separate point, here are a few other soft skills that are less decisive in determining someone’s level but can still serve as growth markers:

Communication skills — delivering the right information to the right people in the right form. Growth can be measured by communication effectiveness: less chaos, more clarity, lower time costs, and choosing the right language for the target audience (so they don’t suffer too much in the process — and ideally actually enjoy what’s happening without losing the meaning).

Critical thinking — not accepting information as truth at face value, but independently assessing its reliability and internal logic.
A client may sincerely believe they need feature X. A user may describe a symptom while mistaking it for the cause. A developer may say something is impossible. A manager may consider a task an absolute top priority.
As we grow, we increasingly question these assumptions, verify information with the right questions, and cross-check it against other sources and our own experience.
Extra respect to ourselves if we also check our own thinking, because we are susceptible to cognitive biases, and critical thinking is one way to neutralize them more and more often.

Working with feedback — rationally processing feedback directed at us, whether positive or negative.

Growth means increasing adequacy and fewer spontaneous emotional reactions: not “Everything is terrible, I’m useless” or “You little turnip, how dare you think that about someone as awesome as me?”, but rather “Okay, I understand what exactly was bad” or “Hmm, I see a pattern here: this is the third time someone has told me the same thing. I probably have a systemic problem, and I need to change my approach.”

Emotional resilience. We often deal with dissatisfied or pushy clients, developers who look at us like something they stepped in, sudden requirement changes, criticism, mistakes and screw-ups, and difficult or unpleasant chunks of work.
Accordingly, one indicator of level can be a lower emotional reaction to such situations — and a willingness not to avoid them: “Oh, this is difficult / scary / I don’t know how to do it... I’d rather go chill with some wireframes.”

3. Breadth and depth of professional and adjacent knowledge

For an analyst, this means everything included into the role in terms of professional knowledge.

The emphasis here is specifically on knowledge, because the ability to apply it in practice is a combination of this factor and production experience. And, naturally, experience beats raw knowledge.

• Hard skills for BA activities. Progression through the grades is determined by how broad our toolkit of techniques is for different situations. Combined with experience, this determines how effectively we apply those techniques — useful output versus effort spent, plus speed of execution.
• Communication language proficiency, such as English.
• Domain knowledge, if relevant to the current position.
• IT fundamentals — how increasingly well we understand what happens in development, testing, and other project activities, and how systems work under the hood. I wrote about this in more detail here.

This part is simple: we need to know how to do the work. Acquiring and expanding knowledge is not always easy, especially in complex areas, but it is easier to grow deliberately than cognitive and behavioral skills.
Imagine you’ve read a mountain of books but never actually applied your knowledge in practice. Will you be able to handle a real-world case skillfully? And what if you’re highly capable and have tons of experience, but you’re difficult to work with, passive, need constant supervision, and snap at everyone around you — are you a great employee? You can know BPMN, BABOK, UML, BDSM, and 25 other acronyms inside out and still be a junior in terms of independence. Conversely, you can have been in the profession for ten years and still be a relatively low-level specialist outside your own project if, throughout all those years, you’ve been solving problems of the same complexity in a familiar context.

What kinds of tasks are assigned at each level?

You often hear things like: “We don’t give this to juniors, but that is definitely middle-level work.”
The problem is that this is not systematized, and every company has its own conventions.
The classification I’ve encountered most often is based on task complexity.

Junior: the focus is on working with information that has already been collected and is relatively well structured.

For example:

• Writing or updating a requirements specification based on a discovery conducted by someone else; creating user stories/use cases.
• Drawing BPMN, UML, and other diagrams based on known processes/structures; creating wireframes under supervision and with review.
• Preparing questions for a meeting when there is a clear understanding of exactly what needs to be discovered; conducting simple information gathering according to a predefined scenario and in relatively low-risk conditions (for example, writing an email to a client).

As we discussed above, it is better not to leave uncertainty to a junior. Practically any relatively algorithmic task that does not require broad practical experience is a perfect fit. That’s why, for example, working through functional requirements using existing templates is a delegable task. Working through non-functional requirements to the same degree is considerably more difficult, because it involves research, creativity, and dancing around with a tambourine.

The same applies to working with clients. A junior can absolutely communicate with them, ask questions, and even conduct simple meetings independently (if their language skills allow it). But they are often limited to written communication because it can be reviewed before being sent.

Sessions that require real-time supervision, correction of unrealistic promises, prevention of inappropriate reactions, conflict resolution, and other similar faceplants are often left to more experienced people.

Middle: the focus shifts from processing information to independently obtaining it, making sense of it, and turning it into a solution.

For example (naturally, this also includes everything described at the junior level):

• Independently conducting interviews and workshops; independently preparing questions and meeting plans (tools, participants, agenda, etc.); resolving contradictions between stakeholders.
• Moderate discovery — understanding what problem we are solving, for whom, why, what options exist, and how much of a solution is actually needed.
• Working through moderately complex NFRs.
• Participating in solution design together with developers and architects; working with QA and development on requirements implementation.
• Participating in UAT and analyzing discrepancies between expectations and reality.

In principle, as I wrote above, this covers most BA work, except for the most complex and strategically important pieces.

Senior: a senior can be given any kind of analytical work, at different scales and levels of risk, with a greater degree of independence (working at the problem level, not just the solution level).

For example (obviously including everything a middle does):

• Full-scale discovery from scratch for projects of varying complexity; working with business needs.
• Complex interviews and workshops involving conflicting stakeholders.
• Working with “advanced” types of requirements (NFRs in close to their full scope, transition requirements, defining business requirements under uncertainty).
• Going beyond IT solutions (for example, participating in discussions of business processes).
• Working with legacy and poorly documented systems.
• Working on projects using different delivery models and adapting techniques accordingly (fixed-price/T&M, waterfall/agile).
• Quickly getting up to speed in new domains and switching domains to the extent required by projects.
• Effective business analysis planning based on accumulated experience.
• Mentoring less experienced specialists.

Lead: since this is a senior plus team/department management (although it’s worth noting that in some companies it simply means the most senior specialist in the department or someone responsible for tuning the processes), the tasks look something like this:

• Planning the work of the BA team; distributing tasks among employees.
• Monitoring workload.
• Building effective interactions between the team and PMs, POs, development, QA, and the business.
• Resolving team conflicts; removing blockers.
• Reviewing analysts’ work; providing feedback.
• Mentoring and development; participating in grade assessments and career growth.
• Participating in hiring.
• Building and improving processes, artifact templates, and tools.

And it’s important to understand that a good lead should retain enough professional depth to jump into a task themselves in a critical situation, figure it out, and show the team where the light at the end of the tunnel is.


If I had to sum up everything above, a grade is not some isolated quantity of knowledge, years of experience, tools mastered, or artifact templates learned.
A grade is determined by the combination of growth across several dimensions in parallel:

• the level of uncertainty, complexity, and responsibility we can independently digest and turn into a result;
• the breadth and depth of knowledge in our field;
• practical experience applying everything we know in different situations and combinations.

As usual, I’ll be happy to discuss all of this in our channel!