Client calls. “We’re thinking about hiring a BA.”
I ask what’s happening. Developers building the wrong features. Offshore team constantly blocked. Requirements that seemed clear turning into arguments mid-sprint. Rework everywhere.
Me: “Sounds like you could use analytical capability.”
“Right, that’s what I said. A business analyst.”
“Maybe. But first tell me—what’s actually broken?”
That question usually creates a pause.
Most organisations approach hiring a BA the way they approach hiring any role. Job description. Interview. Onboard. Expect results. Then six months later: “Still not seeing value.”
The problem isn’t the BA. The problem is not understanding what you’re actually hiring to solve.
The Agile Lie Nobody Mentions
Agile defers decisions. Detail is delegated. Ambiguity gets resolved through conversation during implementation. Decisions are deferred to the last possible moment, detail delegated to the lowest possible level. Direct action provides feedback rather than interviews.
This works beautifully in the right environment. Co-located team. Direct user access. Shared context. When a developer has a question, they walk over and ask. Answer comes immediately. Code continues.
Most organisations adopted agile assuming this is how it would work for them.
It doesn’t.
Developer in Bangalore. User in Birmingham. Business stakeholder in London. Product owner in New York. Compliance team in Frankfurt. Question arises during development. Which person do you ask? Across which time zone? In which language? What happens when you get contradictory answers from different stakeholders?
I once worked with a client whose offshore team had spent three months “just asking questions” the way agile suggests. Developers messaging stakeholders at 2am UK time. Getting frustrated responses. Receiving contradictory guidance from different people. Features shipping with gaps because nobody could get definitive answers. The challenges of managing software requirements with offshore development teams require deliberate coordination that informal agile practices can’t provide.
They thought they were doing agile. But they were experiencing what happens when you apply practices designed for co-located teams to a distributed reality. The collaboration model that avoids requirements in the first place had been broken, but nobody had adjusted their process to account for it.
Agile assumes disambiguation happens during development. That assumption only holds when developers can actually disambiguate—when they have the access, the language, the domain knowledge, and the organisational understanding to resolve ambiguity themselves.
When they can’t, disambiguation must happen deliberately. Before development starts. Someone needs to do the work that developers can’t do themselves.
That’s often when organisations realise they need a BA. But not always. Sometimes the problem isn’t disambiguation at all.
What Modern Development Actually Broke
In a perfect world, developers interact directly with users. Conversations replace requirements. Code ships. Feedback arrives immediately. Requirements aren’t needed, everyone’s happy, and I’m not working.
Modern software development doesn’t happen like this.
Developers used to sit with users. They saw the work. They understood context. They asked questions and got immediate answers. Requirements emerged through proximity and conversation. You didn’t need someone to “gather requirements” because the knowledge transfer happened naturally.
Then we distributed teams globally. Moved developers offshore to “centres of excellence.” Created organisational layers between technical teams and business users. Introduced complex regulatory environments. Scaled teams beyond the point where informal coordination works.
We told ourselves collaboration would still work. Just use Slack. Schedule calls. Write better user stories. It doesn’t work. Not the same way.
A developer trying to understand “process the payment” needs to know which payment methods, what validations, what happens on failure, what about refunds, what regulatory requirements apply, what the legacy system currently does. In theory: “Just ask the product owner.” In practice: product owner is in a different time zone, doesn’t know the regulatory requirements, has never seen the legacy system work, and gives high-level guidance that turns out incomplete during implementation.
Developer makes assumptions. Some correct. Some not. Features ship with gaps. Stakeholders complain the system doesn’t do what they expected. Developers get blamed for not asking the right questions.
This isn’t a failure of agile or a failure of developers. It’s a failure to recognise when the conditions that make agile work don’t exist. The Better Software Requirements handbook provides a structured approach to capturing this kind of complexity before development begins.
Look at your delivery environment honestly. Do your developers serve a large user base with varied and complex needs? Are they geographically distanced or several layers removed? Do the developers face language, cultural, or time zone barriers? Do they lack business knowledge about your domain or understanding of your legacy systems? Do they lack regulatory knowledge? Can they navigate the complexity and politics of your on-shore organisation?
If several of these apply, your developers face a complex environment. They need access to knowledge they can’t acquire themselves. They need someone who can navigate your organisation, understand your domain, translate business language into technical clarity, and create shared understanding across time zones and cultural boundaries.
That might be a BA. But only if you understand what problem you’re solving.
The Cost You’re Already Paying
“We can’t afford a BA.”
I ask what their current approach costs.
Development team salary: £400K annually. Time spent in clarification meetings because requirements aren’t clear: roughly 20%. Time spent on rework from misunderstood requirements: another 15%. That’s £140K per year, spent on developers doing work that isn’t development.
Plus the features that miss the mark. The bugs nobody can explain. The stakeholder frustration when shipped features don’t match expectations. The technical debt accumulated from rushed implementations of poorly understood requirements.
I reviewed a project once that burned three months and £180K building the wrong thing. Stakeholders and developers both thought they understood the requirement. They didn’t. Nobody had done the analysis to surface the gap before development started. The organisation didn’t hire a BA because it seemed expensive. The rework cost more than a senior BA for eighteen months.
Every organisation pays for business analysis. Either explicitly, by hiring someone competent to do it. Or implicitly, through the costs of not having it: constant rework, developers spending hours in meetings instead of coding, features that work technically but miss business needs, and expensive late discoveries that require redesign.
This isn’t about whether you need analytical capability. You already need it. The question is whether bringing in a BA costs less than what you’re currently paying through their absence.
If your developers build things right first time, your stakeholders are consistently happy, your rework is minimal—you’re either operating in a genuinely simple domain or you’ve somehow solved this problem already through excellent processes, clear documentation, or outstanding technical leadership.
If you’re seeing frequent rework, missed requirements, blocked developers, and features that don’t deliver what stakeholders expected, you’re paying the cost. The only question is whether you’re paying it efficiently.
Making the Decision
Don’t start by asking “Should we hire a BA?”
Start by asking: “Can our developers get what they need to build things right the first time?”
If yes, through direct user access, simple domain, clear organisational knowledge, co-located teams, you probably don’t need a BA. Your developers can handle disambiguation themselves, and adding a BA just creates unnecessary overhead.
If no, they’re probably geographically distant, organisationally isolated, working in complex domains, facing regulatory requirements, lacking business context, or operating at scale where informal coordination breaks down. Someone needs to bridge the gap.
Sometimes that’s fixing organisational problems rather than hiring. Sometimes that’s better documentation. Sometimes that’s process change. But often, it’s recognising that developers need analytical capability they can’t provide themselves, and bringing in someone who can.
Also, be clear about what you’re solving. Are developers blocked because they can’t get answers quickly enough? That’s an access problem. Are they building wrong things because requirements weren’t clear before development? That’s an analysis problem. Are they drowning in clarification meetings instead of coding? That’s a coordination problem. Are they making expensive mistakes because they don’t understand the domain? That’s a knowledge problem.
Different problems need different solutions. A BA solves some of these, but not all of them.
Getting It Right When You Hire
If you do hire, understand what you’re actually hiring. You’re not hiring a note-taker who sits in meetings and writes down what people say. You’re hiring analytical capability—someone who can take ambiguous business needs and create clarity, spot gaps before they become expensive, challenge assumptions, and make complexity comprehensible.
Domain knowledge matters. A lot. A BA in financial services isn’t interchangeable with a BA in healthcare or retail. The analytical techniques transfer. The domain knowledge doesn’t. If you’re in a regulated industry, hire someone who understands your regulations. If you’re replacing legacy systems, hire someone who’s done it before. If you’re supporting offshore teams, hire someone who knows what that requires. Generic “BA experience” isn’t enough. “Deciding between contract or full-time business analysts depends on your specific situation.
Then create the conditions for them to succeed. Give them access to stakeholders, users, and subject matter experts. Give them context about your organisation, your history, and your constraints. Give them autonomy over their working methods: they’re the expert on how to analyse your specific context. Trust their professional judgment about what level of detail different situations require.
Without those conditions, even an excellent BA will deliver mediocre results because they’re operating blind, following arbitrary processes, or being prevented from doing actual analysis. With them, you’ll likely wonder how you managed without one.
The difference between successful and unsuccessful BA engagements isn’t always the BA’s competence. It often comes down to whether you understood the problem you were trying to solve, and whether you created the right conditions for that to happen.