Let’s talk stereotypes. A stereotype is a preconception based on an image that’s formed for one reason or another. And no, they don’t come out of nowhere — they stick around because, once upon a time, they made sense. Like how IT folk used to paddle along quietly, not daring to question their PM masters. Or because someone loud enough shaped the narrative — “it is written in Father Karl’s holy book, and that’s gospel now.” Or simply because it’s profitable — “Come study with us and become a superhuman in three months.”
I’ve worn many hats in the business analysis world: hands-on practitioner, process builder, recruiter, trainer, mentor, consultant, stakeholder, developer on the receiving end, and PM assessing project efficiency. The stereotypes I’m about to dive into are ones I regularly hear — but that contradict my experience and understanding of the profession. So, here’s a take — a personal one — on what’s damaging to treat as gospel if you’re looking to get into and grow in IT business analysis. At times, it might sound a bit more blunt than necessary, but hey — who gives a ****.
1. Analysts doesn't really need to be IT-smart.
Let’s define “IT” here as everything from “wow, what’s this box with wires under my desk?” to “I’m a full-stack dev, thank you very much.”
Here’s the backdrop, relevant to most points in this article. For a long while, tech folks were cruising on smoothies and hype, enjoying themselves. But then — boom — crisis hit. Globally, locally. And when belts tighten, companies start asking tougher questions. Suddenly, the analyst who stares at code like it’s alien tech is no longer that necessary.
Theoreticians — especially Western ones — love describing analysts as the client’s advocate, part of their team. In reality, at least in my experience, the analyst belongs to our side — the dev team — and their main function is to set tasks clearly so we don’t burn brain cells deciphering vague demands. Nobody needs an analyst who shows up saying, “I have no clue what you’re doing here, but look how well I transcribe people’s words.”
I’ve written more about how such analysts are perceived by teammates. Business analysis may be where non-tech meets tech, but my strong recommendation is: prep yourself for a serious grind into IT knowledge. If you don’t, chances are you’ll later be lamenting the job market or wondering why your team treats you like dead weight.
There’s been a lot of whining lately about how IT is “crazy now” and expects everyone to be a Swiss army knife. But honestly, IT is just returning to how it was meant to be: specialists who are sharp and versatile. Sure, it’ll relax again someday — but guess who’s first in line to be cut when things go south?
2. Being an analyst is all about communication.
Nope. It’s about analysis and working with information. And yes, communication helps you gather that information — but it’s a means, not the core. A level-12 bard might win you over with charisma, but the analyst’s value lies in what info reaches the team, how it’s structured, and how well it guides the project. I've said a few words about it here.
Love talking to people? Great — business analysis will feel natural within the IT role spectrum. But sales and PMs also love talking. The real question is: do you also enjoy digging into complex problems? Are logic, structure, gap analysis, synthesis, and fixing inconsistencies your thing?
There’s no real global standard for BAs. Companies plug gaps with what they’ve got. Sometimes, the gap is just a buffer between the dev team and the outer world. At first, it all seems perfect — stakeholders are smiling, developers don’t have to stumble through English on Zoom calls. But soon enough, mammoth-era issues start creeping in: messy, incomplete requirements, scope creep, bloated systems, outdated knowledge bases. How did that happen? Well, because we reduced BA work to “good vibes and smiling at meetings.”
Don’t get me wrong — communication is a critical BA skill. But equating business analysis with communication? Come on.
3. Modeling notations are pointless now.
The point of modeling isn’t just about the shape of the arrows. Sure, the era of diagramming UML for UML’s sake is mostly over. But when you study UML, BPMN, IDEF, DFD or BDSM, what are you really learning?
You’re learning:
Even if you end up drawing things your own way, an analyst familiar with proper notations will produce models that are more focused, clear, and effective. Their toolbox is just bigger.
4. Traning courses are a waste — self-study is everything we need.
Why pay for a course? Everything’s online already, right?
I hear this one a lot — and it really gets under my skin, since I design training programs and put a lot of effort into making them useful. And let me be clear: I am talking about quality education here — not scammy info-products.
Learning has always been a go-to way to build skills. You could ask, “Why go to school when there’s a library and the internet?” And sure, in theory, you could self-teach. But in practice:
Also, people undervalue what learning with a offers:
Even if you're a self-study wizard, advice from someone who's lived through real cases beats generic Reddit threads or ChatGPT prompts. Yes, finding a great course isn’t easy. But that doesn’t mean learning through structured education is inherently bad. Honestly, I can usually spot the difference between a self-taught BA and someone who had proper guidance — it shows in the way they think, speak, and connect ideas.
5. Theory is BS — just practice matters.
Let’s clarify: smart words might be for interviews. But understanding theory is how you shape your practice.
I’ve seen two takes:
Here’s the issue: if your experience comes solely from practice, it’s likely narrow, specific, and limited. Without broader context, you’re stuck with “what’s worked for me so far,” even if it’s suboptimal. I’ve talked about this a lot — the less you know about alternatives, the fewer tools you bring to the table. And guess who gets shown the door when projects get tough?
BA isn’t rocket science — but it is complex enough to benefit from a solid theoretical base. That foundation helps you avoid reinventing the wheel or making dumb mistakes just because “you didn’t know better.”
6. Agile is life. Nothing exists beyond it.
Agile simplified a lot of things for analysts — which is great. But also risky. If your experience begins and ends with product owners, backlogs, and user stories, you might be seriously underprepared for anything outside that narrow scope.
I’ve met analysts who only know Agile — and frankly, they often lack depth. The assumption is: BA is simple, agile is standard, everything else is outdated. But here’s the thing:
Agile made things easier. But it also removed a lot of the deeper, “messier” aspects of analysis. What are requirements? Just user stories? Take a look at an SRS or BRD template sometime. Think all that’s obsolete? Think again.
Yes, Agile focuses on what matters most — but it also discards a lot of things that still matter, just less visibly. If you only know Agile, you might completely miss those parts of a project where domain modeling, non-functional requirements, gap analysis, or goal setting are key.
As part of the training, when asked “Why do we start with specs and predictiveness in the 21st century?”, here’s how I explain it: this job is 80% about being a smart, skilled analyst. Once you’ve learned how to handle the hard stuff, switching to the simple stuff (like agile) isn’t a big deal. That remaining 20%? We’ll tackle it together — quickly and painlessly. Honestly, a strong analyst could pick up agile on their own, because they’ve already got the foundational thinking in place. But the reverse doesn’t work: if all you know and do is “simple,” stepping up to more complex work — when it’s suddenly needed — can become a wall you just can’t climb. And sometimes you will need to climb it. And if you fail when the work moves beyond your familiar sandbox — guess who they'll point at first when the White Frost comes knocking? :)
Some other points, briefly:
I recently saw an ad for a revolutionary course: BA from zero to mid in a couple months. Miracles never cease.
Let’s define “IT” here as everything from “wow, what’s this box with wires under my desk?” to “I’m a full-stack dev, thank you very much.”
Here’s the backdrop, relevant to most points in this article. For a long while, tech folks were cruising on smoothies and hype, enjoying themselves. But then — boom — crisis hit. Globally, locally. And when belts tighten, companies start asking tougher questions. Suddenly, the analyst who stares at code like it’s alien tech is no longer that necessary.
Theoreticians — especially Western ones — love describing analysts as the client’s advocate, part of their team. In reality, at least in my experience, the analyst belongs to our side — the dev team — and their main function is to set tasks clearly so we don’t burn brain cells deciphering vague demands. Nobody needs an analyst who shows up saying, “I have no clue what you’re doing here, but look how well I transcribe people’s words.”
I’ve written more about how such analysts are perceived by teammates. Business analysis may be where non-tech meets tech, but my strong recommendation is: prep yourself for a serious grind into IT knowledge. If you don’t, chances are you’ll later be lamenting the job market or wondering why your team treats you like dead weight.
There’s been a lot of whining lately about how IT is “crazy now” and expects everyone to be a Swiss army knife. But honestly, IT is just returning to how it was meant to be: specialists who are sharp and versatile. Sure, it’ll relax again someday — but guess who’s first in line to be cut when things go south?
2. Being an analyst is all about communication.
Nope. It’s about analysis and working with information. And yes, communication helps you gather that information — but it’s a means, not the core. A level-12 bard might win you over with charisma, but the analyst’s value lies in what info reaches the team, how it’s structured, and how well it guides the project. I've said a few words about it here.
Love talking to people? Great — business analysis will feel natural within the IT role spectrum. But sales and PMs also love talking. The real question is: do you also enjoy digging into complex problems? Are logic, structure, gap analysis, synthesis, and fixing inconsistencies your thing?
There’s no real global standard for BAs. Companies plug gaps with what they’ve got. Sometimes, the gap is just a buffer between the dev team and the outer world. At first, it all seems perfect — stakeholders are smiling, developers don’t have to stumble through English on Zoom calls. But soon enough, mammoth-era issues start creeping in: messy, incomplete requirements, scope creep, bloated systems, outdated knowledge bases. How did that happen? Well, because we reduced BA work to “good vibes and smiling at meetings.”
Don’t get me wrong — communication is a critical BA skill. But equating business analysis with communication? Come on.
3. Modeling notations are pointless now.
The point of modeling isn’t just about the shape of the arrows. Sure, the era of diagramming UML for UML’s sake is mostly over. But when you study UML, BPMN, IDEF, DFD or BDSM, what are you really learning?
You’re learning:
- Multiple ways of looking at a problem. UML gives you use cases, architecture, states, data structures. BPMN adds process views. IDEF adds functional breakdowns. DFD — data flows. These aren’t just diagrams — they teach you mental models that you wouldn’t come up with on your own.
- Diagramming as a skill. How to visualize things clearly, completely, efficiently. Notation forces you to be precise — not because it’s rigid, but because smart people spent years shaping those rules.
Even if you end up drawing things your own way, an analyst familiar with proper notations will produce models that are more focused, clear, and effective. Their toolbox is just bigger.
4. Traning courses are a waste — self-study is everything we need.
Why pay for a course? Everything’s online already, right?
I hear this one a lot — and it really gets under my skin, since I design training programs and put a lot of effort into making them useful. And let me be clear: I am talking about quality education here — not scammy info-products.
Learning has always been a go-to way to build skills. You could ask, “Why go to school when there’s a library and the internet?” And sure, in theory, you could self-teach. But in practice:
- You need direction. Instead of wading through 50 blog posts, videos, and Instagram carousels, you get curated, structured, and relevant material — ideally backed by real experience. Honestly, 70% of BA content online is junk. Your “quality filter” might differ from mine, but the noise-to-signal ratio is real.
- You lack context. BA in the US ≠ BA in Eastern Europe. Agile ≠ Waterfall. The author's background matters — otherwise you’re blindly applying tactics that might not even fit your situation.
- You can’t tell motives. Flashy posts promising double salaries and +115% efficiency? Often clickbait to sell you something. Can you always tell the difference between useful advice and influencer fluff?
Also, people undervalue what learning with a offers:
- Feedback. Good courses tell you what you’re doing wrong and how to fix it — your errors, not generic ones.
- In-the-moment insights. The gold is often in tips like “hey, here’s a better way to handle that situation.” You won’t find that in a blog post.
Even if you're a self-study wizard, advice from someone who's lived through real cases beats generic Reddit threads or ChatGPT prompts. Yes, finding a great course isn’t easy. But that doesn’t mean learning through structured education is inherently bad. Honestly, I can usually spot the difference between a self-taught BA and someone who had proper guidance — it shows in the way they think, speak, and connect ideas.
5. Theory is BS — just practice matters.
Let’s clarify: smart words might be for interviews. But understanding theory is how you shape your practice.
I’ve seen two takes:
- “There’s nothing to learn, really. Writing user stories isn’t rocket science.”
- “I learn best by doing — give me work, skip the theory.”
Here’s the issue: if your experience comes solely from practice, it’s likely narrow, specific, and limited. Without broader context, you’re stuck with “what’s worked for me so far,” even if it’s suboptimal. I’ve talked about this a lot — the less you know about alternatives, the fewer tools you bring to the table. And guess who gets shown the door when projects get tough?
BA isn’t rocket science — but it is complex enough to benefit from a solid theoretical base. That foundation helps you avoid reinventing the wheel or making dumb mistakes just because “you didn’t know better.”
6. Agile is life. Nothing exists beyond it.
Agile simplified a lot of things for analysts — which is great. But also risky. If your experience begins and ends with product owners, backlogs, and user stories, you might be seriously underprepared for anything outside that narrow scope.
I’ve met analysts who only know Agile — and frankly, they often lack depth. The assumption is: BA is simple, agile is standard, everything else is outdated. But here’s the thing:
- Tons of companies aren’t Agile — either by context or by choice.
- Some are hybrids or still transitioning.
- Others actively reject Agile — and laugh at story points and Trello boards.
Agile made things easier. But it also removed a lot of the deeper, “messier” aspects of analysis. What are requirements? Just user stories? Take a look at an SRS or BRD template sometime. Think all that’s obsolete? Think again.
Yes, Agile focuses on what matters most — but it also discards a lot of things that still matter, just less visibly. If you only know Agile, you might completely miss those parts of a project where domain modeling, non-functional requirements, gap analysis, or goal setting are key.
As part of the training, when asked “Why do we start with specs and predictiveness in the 21st century?”, here’s how I explain it: this job is 80% about being a smart, skilled analyst. Once you’ve learned how to handle the hard stuff, switching to the simple stuff (like agile) isn’t a big deal. That remaining 20%? We’ll tackle it together — quickly and painlessly. Honestly, a strong analyst could pick up agile on their own, because they’ve already got the foundational thinking in place. But the reverse doesn’t work: if all you know and do is “simple,” stepping up to more complex work — when it’s suddenly needed — can become a wall you just can’t climb. And sometimes you will need to climb it. And if you fail when the work moves beyond your familiar sandbox — guess who they'll point at first when the White Frost comes knocking? :)
Some other points, briefly:
- An analyst’s level is defined by their knowledge. About 50% of that knowledge can be gained through training — assuming it’s quality training and approached seriously. The rest comes with time, as you grow deeper into the same core concepts. But what really separates a junior from a mid or senior analyst is experience. Real, hands-on, in-production experience. That’s what determines how you work: under guidance (junior), independently but with occasional help (mid), or like a boss (senior).
I recently saw an ad for a revolutionary course: BA from zero to mid in a couple months. Miracles never cease.
- Business analysis is easy. Speaking as someone who’s spent years as a developer: nope. BA isn’t easier. Reaching the point where you can solve real-world problems with code takes time — the learning curve is steep. BAs need fewer hard skills to get started, sure, and they can probably start contributing to projects faster. But let’s not forget about soft skills — which are far harder to build — or the nature of the work itself. Easy to learn, hard to master. Yeah, I’m simplifying, but as a developer, you’re given a clearly defined task (if the BA has done their job), and then you put on your headphones and do what you do best. A BA, meanwhile, faces tasks like “dig up the unknown, turn it into knowledge — somehow, with someone — and you’ve got two weeks.” The stress levels can be higher too: presentations, workshops, entertaining clients.
- A BA is about the soluton only. Digging into a client’s motivations and internal processes is useless and even harmful. But have you actually tried? Tried doing it well? Have you seen what happens when the client and the team share a clear understanding of why something is needed and how it’s going to be used? Have you seen the client’s reaction when that happens? Mindless requirement scribes are, in my opinion, slowly becoming extinct. There are many shades of doing IT thoughtfully — with a focus on value for both the client and the users — and even shaping that value through supporting processes. Often, this needs to be done gently, subtly, with care. But if you think digging into SMART business goals is a waste of time, that doesn’t necessarily mean your role starts only at user stories' level.
- Hiring is pretty much the same everywhere and it’s driven by efficiency. First off, there’s still no clear, universal definition of what a BA even is — no industry-wide agreement on what analysts should or shouldn’t do. Companies don’t have a consistent view either (remember: they’re often plugging holes), and when that’s filtered through a recruiter’s lens, it becomes even murkier. Most BA job descriptions are just copy-pasted from other postings or built from buzzwords in books. In this kind of environment, breadth of knowledge and experience is your advantage. I often get asked: “Can you guarantee that what I learn from you will be enough to land a job?” No — and no one can. Unless the training is built for one specific company’s needs, all we can do is help you become what the market sees as an “average BA,” and maximize your chances of hitting that target. The scope of BA responsibilities is huge — so huge that BABOK is basically a high-level abstraction. The real-world variations are endless. Keep that in mind if you’re aiming for this field.
- We spend most of our time talking. That’s the shiny image that attracts people who are “bored of writing code.” But based on everything above, understand this: in about half the roles out there, that’s just not true. If you want to be a BA in IT, ask yourself: will you be okay typing? A lot? BAs type constantly — carefully, clearly, and with structure. Sometimes that’s 90% of the job: documents, emails, guides, specifications. And that’s where I’ve seen people get disappointed — in training and in the role itself. They expected fun conversations and client meetings. What they got was writing a 100-page spec — not exactly a creative joyride. So, to avoid that disappointment, ask yourself a different question: do you enjoy working with information: extracting it (from multiple sources — especially people), analyzing it (spotting gaps, contradictions, dependencies), documenting it carefully and clearly. In short: do you enjoy turning chaos into clarity? Does that resonate with you?
