Debates about what an IT business analyst needs — beyond the ability to work with information and people — show no sign of slowing down. On the contrary, the line between “this is absolutely essential” and “why bother, let’s just write some code” is becoming increasingly blurred. This shift can partly be attributed to the dominance of Agile. At the same time, the widespread digitization of industries is drawing in professionals from all backgrounds. A common sentiment nowadays is: “I have no technical knowledge or skills, but I want to be a business analyst because development is hard, and BA work doesn’t seem to require being a full-fledged IT specialist.” This trend isn’t inherently negative, but the way it’s unfolding can be disheartening. The consequences? a) We see an influx of poorly executed software products trying (and failing) to digitize our lives. b) Teams hire continuously, yet still struggle to move the train forward. This article isn’t a secret formula for becoming a “true” IT specialist as a BA — it’s more of a personal reflection on some key BA attributes that are often overlooked. Let’s begin with the technical foundation: the IT background.
Does an IT business analyst need an IT background (i.e., broad and deep knowledge of information technologies)?
There’s no clear consensus. This debate has been around for years and will likely continue. Why? Because the role of an IT business analyst varies significantly across companies and projects. Take, for example, a random tester or developer job posting: aside from describing the project, testing types, or programming languages and frameworks, there’s not much ambiguity. But analyst job postings? Unless they’re written by someone who truly understands the role, they’re often vague. You’re likely to be left wondering: what kind of analyst are they looking for (requirements, BI, business processes); what will I be doing (solving client problems, managing requirements, analyzing processes, creating prototypes, sipping cocktails with clients); what’s my actual title — and does it even matter (business analyst, systems analyst, requirements analyst)? Even the BABOK (our main body of knowledge) is so broad that it isn’t IT-specific and doesn't answer these questions clearly. If we truly had to master everything in the BABOK, some might ask: “Why aren’t we billionaires already?” Ultimately, a BA’s role is shaped by two things: 1. The IT domain in question. 2. The specific company, department, or team — and how they define the BA’s responsibilities.
As a result, some analysts design databases, while others transcribe client input and pass it along to the dev team with minimal processing. The former group knows they need technical expertise. The latter may wonder why they need to understand databases at all — aren’t they just passing along clients' and user's needs? Here’s the thing: everyone’s right. Outside of specific corporate bubbles, IT business analysis lacks standardization. Sure, there’s common theory most of us study, but there’s no one-size-fits-all framework for BA responsibilities in IT vs. non-IT environments. And that’s perfectly fine. Every company needs its own layer between clients and developers — one that fits its service model.
So what should aspiring BAs do? One approach is to build a broad, high-level knowledge base — making yourself adaptable across a variety of tasks. Let me give a non-technical example. I’ve interviewed analysts who considered themselves highly valuable, but in the context of a new role, brought almost nothing to the table. Why? They had solved complex problems at their previous company and assumed that success automatically translated elsewhere. Unfortunately, they never studied anything else. Imagine a candidate who believes nothing exists beyond user stories. They’ve mastered splitting and merging stories like a Jedi, know Jira and Confluence like the back of their hand, and can recite INVEST principles if woken up at night. But then they enter an environment requiring detailed requirements, formal artifacts — and their mindset collapses. “I thought specs were obsolete.” Apparently, the world only consists of Waterfall and Agile, which is light and darkness, and user stories work everywhere, right? And that’s a best-case scenario. Sometimes, candidates have worked on such narrow tasks that they’re essentially unemployable outside their former company.
Applying this to the IT background: possessing it significantly enhances your value as an IT business analyst — regardless of company-specific nuances. I’d even go as far as to say: teams developing IT solutions shouldn’t hire BAs who lack an IT foundation. While some projects may function without it, they rarely do so efficiently. Here’s an analogy I like to use: imagine a BA as a consultant at a car repair shop — serving as a bridge between clients and mechanics. Their job is to ensure a smooth experience for the client. The client shouldn’t need to deal with tough mechanics who lack communication skills. Now imagine that this “bridge” is polite and offers coffee to clients and nothing else: their role is to extract the "pain" from the client and pass it to the mechanics; then they decode the mechanics’ jargon and relay it back to the client, hopefully with minimal distortion. Sure, that works. But wouldn’t it be more effective to teach the mechanic to offer coffee? Now imagine Consultant 2.0 — they’re not a mechanic, but they understand how cars work, recognize common issues and can explain symptoms clearly. This version of the BA can analyze the problem upfront; discuss possible solutions in layman’s terms; estimate the scale of work involved; communicate clearly with both mechanics and clients; interpret feedback through a lens of professional competence.
What are the signs that a BA on the team is, to put it bluntly, not really an IT person?
The person works as an analyst but regularly asks questions like “How do I write requirements for X?”. This often reflects a wider team issue — companies reach out to external BA consultants with requests like: "Our analysts are struggling — they don’t know how to write requirements for UI/integrations/algorithms/data/etc." (Um, but isn’t that the core of the job? How did it happen that your analysts can’t actually do their job?)
The rest of the team firmly believes that BAs are unnecessary on the project (they get paid for nothing, hinder real work, aren’t worthy of any respect — choose your line).
This BA’s requirements are the stuff of a mad scientist’s fever dream. “When the button is clicked, it should burst into flames, scream at the user, and initiate an antivirus scan on their machine.” This includes not just feasibility issues, but a general disregard for fundamental qualities of good requirements. For instance: when asked to describe integration with an external system — here’s some random info for you ("I don’t know what an API is or why it matters here"). When describing UI elements — here are the font and color specs ("Wait, you needed something else? Validations? Events? Data? What are you even talking about? I just thought this looked cute.")
When talking to the client, the BA is unable to answer independently and constantly replies with “I’ll check with the dev team and get back to you.” While this can sometimes be the right approach, it shouldn't be the default mode. Even worse — the BA can’t lead a conversation without developers present. Their role boils down to dragging the devs into every meeting and whispering in their ears what English term the client just used.
At internal meetings and events, the BA wears a serious “thinking face” but clearly doesn’t understand the team’s technical discussions. To compensate, they smile a lot and bring coffee to the team. The team appreciates the BA’s communication skills and appearance, but is increasingly leaning toward point 2 above.
There can be many reasons behind these symptoms, and I’ll explore one of them in a future post. But very often, the root cause is the analyst’s weak connection to the IT world. The result is what I described at the beginning: frustrating products and teams that don’t work well as a unit. The effects may not be immediate, but they’re inevitable.
What can we do about it?
Let’s set aside companies with their internal processes and decision-making criteria, and focus instead on what you can do if you want to enter the wonderful world of IT through the “IT Business Analyst” door.
Question one: Do you need an IT background? Short answer: yes, absolutely.
Question two: How much IT knowledge do you need? Short answer: who the hell knows... If a single book could fill all tech gaps for all analysts, it would be a masterpiece. The challenge is that the scope of an analyst’s work varies widely. Today you might be learning about APIs, tomorrow it’s iOS UI guidelines, and the day after that — a complex IT system with a lot of hardware-software integrations. Still, every technical domain is built on a core set of principles. And there’s also a frequency factor — for example, you’re far more likely to encounter a relational database than a non-relational one. That’s how most IT education is structured: years of foundational, broadly applicable knowledge first, followed by specialization.Your goal, then, is to define the scope of this foundational knowledge — in both breadth and depth. This isn’t a trivial task, and everyone has their own opinion. Based on my experience working with analysts — teaching and collaborating — here’s what I consider a solid IT foundation:
Basics of computer science (what information is, how it’s measured, and how we work with it digitally)
Fundamentals of hardware and software (what software is, and its main types)
Principles of computer networks
How software is developed (architectural components, algorithms, common languages/technologies, software types)
The basics of working with databases
Question Three: How do you acquire this foundation? Short answer: study — ideally, with hands-on immersion. Hello, Captain Obvious. If you're just starting your life path and higher education is still ahead of you, consider choosing an IT-related major. When you spend years on the foundational topics listed earlier, you begin to think like an IT professional — and speak like one, too. Personally, I’d much prefer someone with a technical background and decent communication-level English than a silver-tongued communicator fluent in idioms and Shakespeare, but lacking technical foundation. If you already work in IT — as a developer, QA engineer, designer, etc. — and want to transition into a BA role, congratulations: you’re in an ideal position. You already have the technical foundation, so let’s move on. If you already have a degree (not in IT) and want to switch fields, that’s a tougher path — but entirely doable. First and foremost, accept that you will need to become an IT specialist. Allocate time, be patient, and create a learning roadmap — a proper level-up plan for your character.
Here are some resources and tips:
1. Start with Vinay Trivedi’s How to Speak Tech. Many people recommend this book, and I agree — it’s an excellent starting point. It is concise, so approach it with thoroughness. Never skip confusing parts just to keep reading. Rule of thumb #1: if something isn’t clear — look it up, research it online, ask IT-savvy friends. Do everything you can to truly understand the topic. Rule of thumb #2:try explaining what you’ve learned to an imaginary curious child. They're not in IT either, and they’ll only understand it if you break it down to the “building blocks” level. This approach worked wonders for me back in university exam prep days — I’d walk around explaining concepts out loud to some invisible audience like a madman. It not only strengthens your technical foundation but also improves two other essential skills: (1) quickly and effectively learning new domains, and (2) communicating complex ideas clearly. And of course, good old notes, plans, and mind maps are always helpful.
You will earn a mental medal and +100 confidence points, putting you ahead of 90% of other candidates.
3. A piece of advice I’ve always followed myself: Whenever possible, do IT-related things with your own hands. Books don’t replace real experience — and the bumps you get along the way are worth it. Yes, they’ll sting at first, but soon you’ll toughen up and learn faster. Some examples:
Your OS is glitching or won’t boot? Fix it yourself — even if that means reinstalling it. You might think it’s rocket science, but it’s basic stuff for an IT person. Dig into the registry, flash a bootable OS image to a USB drive. If you constantly run to your team lead crying about “viruses” or “the mouse isn’t moving,” don’t be surprised if your colleagues quietly laugh behind your back. You don’t need to learn how to change your CPU’s thermal paste — just master the software side of things.
Something in your workflow is repetitive? Automate it. Write scripts to automate startup tasks, or create VBA macros for office apps. You’ll not only make your life easier, but you’ll also get a huge confidence boost — like you’ve become a real developer. A business analyst who manually repeats boring tasks without thinking of optimization is a strange creature.
App not working? Diagnose it, reinstall it, replace it. Learn to troubleshoot software problems on your own. Some painful real-life examples: a BA-to-be who can’t fix a muted mic or handle other Google Meet issues. Trust me — nearly 100% of such issues are solvable with a bit of tinkering, searching, or (as a last resort) asking for help. If software still feels like “magic” to you — or like something dangerous that might explode if clicked the wrong way — you’re likely in the wrong field.
Learn how to use the web and Google properly. Most of the above can be solved with just these two tools. Remember: one of the key BA skills is problem-solving. And Google, plus analytical thinking (you are an analyst, right?), is the foundation of that skill. With these two, you can write code, deploy systems, and troubleshoot your PC without destroying it.
4. Advanced practice: build something with your own hands. This one is advanced, but once you’re ready — do it. Try stepping into developer’s shoes and build something that works. A simple example I often suggest: create a basic web app — a homepage or a product list with photos, descriptions, and the ability to add/edit/delete items. Use whatever tools you find — e.g., HTML + CSS + JavaScript + MySQL. Build all the components, test them thoroughly, and deploy it online. Google is enough to guide you through this if you’ve completed the theory from earlier steps. If you have a mentor to guide you through it step by step — even better. You don’t need to memorize what you did — you just need to learn how to do it and get your hands dirty. Your understanding of what “developer in the next room” actually does — and why he sometimes swears — will grow dramatically.
That’s pretty much it. A BA who's an IT guy is an asset. This impacts how “true” tech folks see the BA role, the speed at which a BA can grow, and the effectiveness of teams and their solutions.
Ideally, companies would understand this and stop chasing only short-term hiring goals. But realistically, we may see the opposite. Either way, if you’re looking for something to dive into — whether you're just getting started with business analysis or already writing user stories and smiling on daily standups — this is it. Go for it.