Business Analyst

The most ambiguous title in the market

Business Analyst covers more distinct jobs than almost any other title, and the versions have so little in common that experience in one is sometimes a liability in another.

In banking and insurance it usually means requirements: sitting between business stakeholders and a delivery team, writing specifications, and shepherding change through a governance process. In technology companies it often means data: writing queries, building reports, and answering questions with numbers. In consulting it means process mapping and improvement work. In some organisations it is a project management role with a different label.

A candidate from the requirements version applying to the data version is competing against people who have written SQL every day for three years. The reverse is equally mismatched. Neither is a weak candidate. They are simply in the wrong queue.

Working out which one a posting means

Three signals, and they rarely disagree.

The verbs. Elicit, document, specify and validate point at requirements work. Query, analyse, model and report point at data work. Map, simplify and optimise point at process work.

The tools. Jira, Confluence and a modelling notation such as BPMN mean requirements and process. SQL, Excel and a business intelligence tool mean data. SAP, Salesforce or a named core system means you will be a specialist in that system, which is its own career and a durable one.

Who you sit with. Reporting into a technology or change function means delivery-facing work. Reporting into a business unit means you serve that unit and your value is domain knowledge as much as method.

If you cannot tell, the interview will be a mismatch in one direction or the other, so ask in the screening call. "Is this role closer to requirements and process, or closer to analysis and reporting" is a normal question and the answer costs you nothing.

Domain knowledge is the asset, not the method

The methods in this field are learnable in months. What takes years is knowing how a particular industry actually works, and that is what employers are paying for even when the posting does not say so.

A Business Analyst who understands mortgage origination, or claims handling, or clinical trial data, is valuable in a way that does not transfer. That is why moving between industries at the same level is harder here than in most professions, and why the same person can be a strong candidate in one sector and unremarkable in another.

Use this deliberately. Apply into the industry you know first, and lead with the domain rather than the toolkit. "Six years in general insurance, three of them on claims systems" is a stronger opening than a list of methodologies, because it answers the question the hiring manager cares about.

If you are changing industries on purpose, expect to take a step sideways or down in scope, and expect the process to be slower. It is doable. It is not a lateral move, whatever the title says.

What a strong requirements resume looks like

Requirements work produces artefacts, and candidates list them: user stories, process maps, functional specifications, traceability matrices. Everyone lists those.

What distinguishes a resume is showing you affected the outcome rather than documenting it. The analyst who found that two departments had incompatible definitions of the same field before it reached development saved a rebuild. The analyst who pushed back on a requested feature and proposed a smaller change that solved the same problem saved a quarter.

Write those. Scope, what you found, what changed because of it. It is the difference between a scribe and someone with judgment, and only one of those gets promoted.

Volume helps as context. How many stakeholders, how many systems touched, how large the programme. An analyst on a two-person change and one on a regulatory programme across eight systems are doing different jobs, and the reader cannot tell unless you say.

The data version has a harder gate

If you are applying to the analytics flavour, there is a technical screen and it is usually SQL. This surprises people who have held the Business Analyst title for years in a requirements role.

The questions are not exotic: joins, aggregation, window functions, and enough care to notice when a join has duplicated rows. What catches people out is that reading SQL and writing it under observation are different skills.

Excel matters more than candidates expect and dismissing it is a tell. A great deal of real business analysis still happens in spreadsheets, and being genuinely good at them, meaning models other people can follow and audit, is worth naming.

If you want to move from requirements to data, the fastest evidence is not a certificate. It is one piece of real analysis on data from the business you already know, ending in a recommendation rather than a chart.

Contract work, and what it does to a career here

Business analysis has a larger contract market than most professions, particularly in financial services, government and large change programmes. It is worth understanding what taking that route does to the shape of your career.

Contract work usually pays more per day and buys you exposure to many organisations quickly. Analysts who have worked across six banks have seen more variations of a process than a permanent analyst sees in a decade, and that breadth is genuinely valuable.

The cost is that contractors are hired to deliver a defined piece of work, so the roles rarely include the parts that build a case for promotion. You are seldom given people to manage, rarely present to executives, and almost never own something long enough to see whether it worked.

If you plan to return to permanent work later, collect the evidence deliberately while contracting. Ask to present at steering meetings. Take the piece of work that spans several teams. Note down outcomes after you leave, because a contractor's resume that lists engagements without results reads as a series of tasks.

If a posting is ambiguous about permanent or contract, ask early. The interview process, the questions, and what they are willing to invest in you differ considerably.

Certifications, honestly

There are several in this field. Some employers filter on them, particularly large enterprises, government, and consultancies with formal grading structures. Most technology companies do not care at all.

The realistic position is that a certification is worth having if you are targeting the kind of employer that lists it, and close to worthless otherwise. It signals familiarity with vocabulary rather than capability, and interviewers who have seen many certified analysts know this.

If you are choosing between spending three months on a certification or three months getting genuinely good at SQL, and you do not know which employers you are targeting, choose the SQL. It is testable in an interview, which the certificate is not.

The stakeholder question you will be asked

Expect a question about a difficult stakeholder, a disagreement between departments, or a requirement that changed late.

The answer that fails describes how you managed the person, in a slightly superior tone. Analysts who talk about stakeholders as obstacles are a known problem and interviewers listen for it.

The answer that works treats the disagreement as information. Two departments wanting incompatible things usually means the underlying process is genuinely contested, and the analyst's job is to surface that rather than to broker a compromise that satisfies nobody. Say what the actual conflict was, how you made it visible to the people who could decide, and what they chose.

Have one where you were wrong, too. An analyst who has never misunderstood a requirement has not done much of this work.

Where the title pays and where it does not

We do not print salary figures, because a number from London means nothing in Toronto, Bangalore or Nairobi.

The pattern worth knowing is that this title has one of the widest bands in the market, and position within it depends less on years than on two things: the industry you sit in and whether your work touches money directly.

Financial services and regulated industries pay analysts more than most sectors, and specialists in a core platform such as a major enterprise resource planning or customer system sit above generalists. Analysts attached to revenue or regulatory work sit above those attached to internal process improvement.

The moves that reprice you: from generalist into a named system specialism, from internal process work to customer or revenue-facing work, and from a local company to a multinational in the same city.

For what the role pays where you live, our salary calculator takes your city and your years of experience.

The one thing to settle first

Decide which version of this job you are applying for, and write a version of your resume that answers that question in the first three lines. Analysts who try to cover all three read as unfocused to every one of them.

Our job search builder searches every board you trust at once, and the ATS scanner shows what a filter reads first.