The Most Certified Business Analyst I Ever Worked With Was Also the Worst
Certifications don’t make you good at requirements, stakeholder management, or reading code. Skills do. Here’s why the industry has it…
The Most Certified Business Analyst I Ever Worked With Was Also the Worst

Certifications don’t make you good at requirements, stakeholder management, or reading code. Skills do. Here’s why the industry has it backwards.
I once joined a project where the lead BA had every certification you could name. CBAP, CCBA, PMI-PBA, ITIL, a couple of Agile ones I’d never even heard of. His email signature was longer than most of my user stories.
And he was terrible.
Not terrible as a person. Terrible as a business analyst. He couldn’t write a functional requirement that a developer could actually build from. He’d sit in a workshop with a payments architect discussing ISO 20022 message flows and nod along without asking a single clarifying question. When the dev team pushed back on scope, he folded every time because he didn’t understand the technical tradeoffs well enough to hold his ground.
Meanwhile, the best BA on that same team had zero certifications. None. She had five years of hands-on work in banking integrations, she could read a Kafka consumer log, she knew how to write a cURL command to test an API, and she could translate a compliance requirement into a data mapping that actually made sense to the downstream team. She never felt the need to prove herself with letters after her name because her deliverables did that for her.
I’ve seen this pattern repeat across every bank and fintech I’ve worked in over the past decade. And it forced me to ask a question that the BA community doesn’t love hearing: are certifications actually useful, or are they just expensive comfort blankets?
The Certification Industry Sells Confidence, Not Competence
Let’s be honest about what certifications actually are. They’re standardized knowledge tests. You study a body of knowledge, you memorize frameworks and terminology, you pass an exam. That proves you can retain information and perform under test conditions. It does not prove you can elicit requirements from a difficult stakeholder, debug a failed API integration, or write a BRD that doesn’t make developers want to quit.
The certification bodies know this. That’s why they keep creating new certifications, new levels, new specializations. It’s a business model built on the anxiety of professionals who feel like they need external validation to be taken seriously.
I’m not saying the knowledge itself is useless. Understanding the BABOK is fine. Knowing Agile frameworks is fine. But the gap between “I studied this” and “I can do this under pressure on a real project” is enormous. And certifications don’t bridge that gap. Practice does. I built The Technical Skills Guide for BAs specifically to focus on the skills that actually move the needle on real projects, not exam prep material, but the things you need to do the job well.
What Actually Makes a Business Analyst Good
Think about the best BA you’ve ever worked with. I’d bet money they weren’t the most certified person on the team. They were probably the person who could do three things really well.
They understood the domain deeply. Not at a surface level. They knew why a SWIFT MT103 message has specific fields, not just that it exists. They understood why a payment rail matters for settlement timing, not just that there are different payment types. Domain knowledge isn’t something you get from a textbook. You get it from sitting in rooms with operations teams, reading production logs, and asking dumb questions for long enough that they stop being dumb questions.
If you’re trying to break into banking or fintech, this kind of deep domain fluency is what separates you from every other BA applying for the same role. I mapped out exactly how to build this knowledge from scratch in Break Into Banking — The Complete BA Guide, including the terminology, the systems, the regulatory landscape, and the interview questions you’ll actually face.
They could go technical when it mattered. They didn’t need to write production code. But they could read an API contract and spot that a required field was missing. They could look at a sequence diagram and ask why the authentication call was happening after the data fetch instead of before. They could open Postman, hit an endpoint, and show a developer exactly what response they were getting versus what the spec said they should get.
This is the skill set that makes teams trust you. Not a certificate on your wall, but the ability to sit in a technical design session and actually contribute. This is also the skill set that’s hardest to find guidance on, because most BA training assumes you’re allergic to anything that looks like code. I built API Documentation from Scratch for BAs who want to close that gap without needing a computer science degree.
They produced deliverables that moved the project forward. Not 40-page BRDs that nobody reads. Concise, structured documents that developers could build from, testers could validate against, and stakeholders could sign off on without a three-hour walkthrough. The deliverable is the proof of competence. Not the certification.
The Hiring Problem: Certifications as a Lazy Filter
Here’s where it gets frustrating. A lot of job postings list certifications as requirements. “CBAP required.” “PMI-PBA preferred.” And I get why hiring managers do this. It’s a shortcut. When you’re reviewing 200 resumes, a certification is a quick signal that this person at least invested time in the profession.
But it’s a terrible filter. It screens out experienced practitioners who never bothered with exams because they were too busy shipping projects. And it lets in people who are great at studying but have never written a requirement that survived contact with a development team.
If you’re a BA who doesn’t have certifications and you’re worried about getting filtered out, here’s what I’d tell you: build a portfolio of skills that makes the certification question irrelevant. When you can walk into an interview and explain how you validated a SWIFT message transformation using Postman, or how you wrote acceptance criteria that caught an edge case in a Kafka event stream, nobody’s going to ask about your CBAP status.
The BA & TBA Interview Guide is built around this exact approach, real scenario-based questions and answers that demonstrate hands-on competence, not memorized definitions.
“But My Company Pays for Certifications”
Good. Take the training. Learn the material. If someone else is footing the bill, there’s no reason to say no to structured learning.
But don’t confuse the training with the skill. The training is input. The skill is output. After you take a CBAP prep course, you know what a stakeholder analysis is. After you’ve done 50 stakeholder analyses on real projects across payments, lending, and compliance, you know how to actually do one. Those are very different things.
The real investment isn’t the certification fee. It’s the time you spend after the course practicing, building, and applying what you learned. That’s where growth happens. Not in the exam room.
The Skills That Actually Differentiate You in 2026
The BA market is shifting. Five years ago, you could get by with strong communication skills and a solid understanding of Agile ceremonies. That’s table stakes now. What separates a senior BA from a mid-level one today is technical fluency.
Can you read a REST API spec and write meaningful acceptance criteria from it? Can you query a database to validate that a data migration actually worked? Can you look at a microservices architecture diagram and identify where a new requirement creates an integration dependency? Can you test an endpoint yourself instead of waiting three days for a QA resource to become available?
These aren’t developer skills. They’re modern BA skills. And they’re not covered in any certification exam I’ve ever seen.
If you want to build this entire skill stack in one shot, The Complete Tech BA Bundle packages everything together, from technical fundamentals to domain knowledge to deliverable templates. It’s designed for BAs who want to stop being the person who “just writes requirements” and start being the person the team can’t function without.
Certifications Aren’t Bad. They’re Just Not Enough.
I want to be clear: I’m not telling anyone to burn their CBAP study guide. Certifications have their place. They provide structure for early-career analysts who don’t know where to start. They give you vocabulary. They signal a baseline of professional commitment.
But they are not a substitute for doing the work. They are not proof that you can perform under pressure. And they are definitely not the reason the best BAs I’ve worked with were the best.
The best BAs I’ve worked with were the ones who built real skills, shipped real deliverables, and earned trust by being useful in rooms where the problems were hard. That’s the standard. Everything else is decoration.
If you’re ready to invest in the skills that actually matter, start at The Tech BA Toolkit. Everything I build is based on what I’ve seen work in real banking and payments projects over the last decade.
Ahmed is a Senior Technical Business Analyst with 10+ years in banking and payments. He builds practical guides and tools for analysts at The Tech BA Toolkit.
메타데이터
- post_id
- 58a5ed511e88
- slug
- the-most-certified-business-analyst-i-ever-worked-with-was-also-the-worst-58a5ed511e88
- url
- https://medium.com/@squalliahmed/the-most-certified-business-analyst-i-ever-worked-with-was-also-the-worst-58a5ed511e88
- canonical_url
- https://medium.com/@squalliahmed/the-most-certified-business-analyst-i-ever-worked-with-was-also-the-worst-58a5ed511e88
- author_url
- https://medium.com/@squalliahmed
- status
- ok
- fetched_at
- 2026-07-12 02:56:06