On one of my first projects, a colleague dropped a phrase that stuck with me for years: ‘You’re not a business analyst, you’re a technical writer.’ I had just left banking – over ten years in leadership roles, head of department, head of division – and had recently completed a six-month full-stack course to finally speak the same language as development. On paper, I was a business analyst by job title. In reality – no, and my colleague noticed it before I did.

I didn’t get offended immediately. First, I got angry. Then I sat down to figure out why it was true – and that’s when the real transition began. Not the one that happened on paper when I changed jobs, but the one that took the following years.

This is personal experience, not abstract advice. If you’re currently thinking it’s too late to start, you’ll find it useful to know how many years such a transition actually takes, and what truly felt hard about it, not just ‘a little unusual’.

Lacking Arguments, Not Knowledge

In the bank, I was close to BA functions – process modeling, analysis – it just wasn’t called that. The real problem emerged not in terms, but in arguments. I tried to push for more user-friendly features – convenience, UX. IT always responded the same way: “we can do with less.” I wasn’t afraid to argue. I lacked the vocabulary. I didn’t know what alternative implementation methods existed to say: ‘Let’s do it this way’ – specifically, rather than just ‘make it more convenient’.

It wasn’t that I didn’t know how to defend the business’s position. I didn’t know what to defend it with.

What Training Teaches, And What It Doesn’t

Six months of full-stack training provided exactly what was missing in those arguments: an understanding of architecture. What frontend, backend, and services are, and how they relate. SQL fundamentals, database structure, class diagrams. Agile terms – sprint, backlog, ceremonies. All of this truly came in handy, and not just in words – I started to understand what development was even arguing about.

What the course didn’t provide was the practice of the role itself. How exactly a business analyst works day-to-day. What questions to ask first. Where the line is between ‘clarifying with the client’ and ‘deciding it myself’. The training was closer to programming than to business analysis. I knew the details superficially. Hence the comment about being a technical writer – I could describe a requirement. Fighting for it – not yet.

Waterfall and Agile — Two Different Worlds, Not Two Processes

In the bank, a decision on a new feature went like this: first a committee, then the board of directors, then another round table – before anyone even opened the technical specification. While approval was underway, the document would become outdated and had to be rewritten, sometimes more than once. Correcting a single requirement took weeks, not hours. In an IT product, everything was the opposite: a two-week sprint, planning on Monday, demo on Friday, and the next iteration already incorporating feedback – what was a six-month approval cycle in the bank, here fit into a single sprint.

My first role at an outsourced product company was BA only in job title. Essentially, it was a transitional position between two logics: banking and product. It was hard precisely because I was standing at the boundary, rather than fully on one side.

The Money Upfront — To Be Honest

Often you stay in a job not because it suits you, but because it pays enough that you don’t feel the need to move. And that’s exactly the moment IT looks too good to pass up: more interesting work, a clear path to grow — and the money looks fine too. That’s where the catch is.

There was a dip in salary. Right at the beginning. From department head, I started out as a junior at the very bottom of the hierarchy — and for a while, the status hit harder than the number on the paycheck. And that’s normal: you can’t transition from a difficult or disliked job directly to the same pay you had before, let alone more. Anyone who promises otherwise is either selling a course or hasn’t gone through it themselves.

Ten Years Later

Ten years have passed since the transition. During this time – BA, Business Analyst Team Lead, Senior BA, and eventually Operations Director at a neobank. Domains – from classic banking and crypto to gambling and HR systems. None of these steps happened in six months of training. Training opened the door. The rest – years of practical experience.

If I had to condense it into one piece of advice: find a practical foundation and a good mentor, and consult with them constantly – not someone who just criticizes, but someone who genuinely teaches. And don’t be afraid to ask questions, even seemingly obvious ones. The ability to ask the right question is one of a BA’s key skills, not a sign that you’re unprepared.

Want to start without a BA diploma

470 real questions from actual Middle BA interviews — free in our Telegram bot

▶ Open the bot

Next in the blog, I’ll break down the tools a junior BA should actually start with – SQL, Miro, Jira – without bloating the list with software you won’t need in your first year.

Frequently asked questions

Is it too late to transition into business analysis at 30-40 years old?

No. An initial dip in salary and status is normal, not a sign that your choice was wrong. Growth takes years, not just one course: in this case, ten years of practice passed from the first BA role to Chief Operating Officer.

Is it essential to learn programming to become a BA?

Not directly, but understanding architecture – frontend, backend, SQL, database structure – greatly helps in debating with development on equal terms. This was the most useful part of the technical training before the transition, not the code itself.

Why might you be 'not quite a BA' in your first role?

Courses usually provide architectural knowledge but don't offer practical experience in the role itself—how to ask questions, where to draw the line of responsibility. This only comes with experience on real projects, not from training.