This one is a little different. It is less about frameworks and more about something I see happening in the BA community that I think deserves an honest conversation.
A lot of BAs right now are defending. Defending the requirements process. Defending the value of documentation. Defending the need for discovery phases and sign-off cycles and structured elicitation. Defending the way things have been done, against a tide of change that feels fast and disorienting and, in some cases, genuinely unfair.
And I understand it. I do. When you have spent years building expertise in something, when you have gotten genuinely good at it, when you have seen the damage that happens when teams skip the analysis work you know how to do, it is natural to push back. It feels like you are defending quality and rigor and the right way to work. And sometimes you are.
But sometimes, defending is just defending. And the most honest, useful thing I can offer right now is this: you cannot defend and adapt at the same time. You have to choose. And the choice you make in the next few years will shape your career in ways that are hard to overstate.
What Defending Actually Looks Like
Defending does not show up as “I refuse to change.” It shows up in subtler ways, and that is what makes it hard to recognize.
It shows up as explaining to a stakeholder why the project needs a proper discovery phase, when the organization has moved past discovery phases and the conversation you actually need to have is how to do discovery differently in the flow of the build.
It shows up as feeling frustrated when AI tools generate a first-draft user story in thirty seconds, and spending mental energy on why that output is not as good as what you would have written, instead of figuring out what your role is now that the first draft is not the hard part anymore.
It shows up as talking about what BAs do in terms of the artifacts they produce, because artifacts are tangible and defensible and have always been the measure of BA work, even though the value of those artifacts is increasingly being questioned.
It shows up as a quiet sense of superiority about teams that move fast without formal analysis, combined with a quiet anxiety about not being invited into the room where the fast work is happening.
It shows up as asking for a phase so you can do your work, rather than collaborating with others to analyze and be part of a build team where you lean into your unique lends and skills as part of that team.
None of these are bad instincts on their own. Some of them reflect real wisdom about what happens when rigor gets skipped. But when they become the primary response to a changing environment, they are defending. And defending does not change the environment. It just puts you at odds with it.
The Dangerous Part: Adapting When You Don’t Know What You’re Adapting To
Recognizing that you need to adapt is one thing. Knowing what to adapt to is another thing entirely. And right now, in this moment, the answer to “what should BA practice look like in an AI-enabled world” is still being worked out. By practitioners. By thought leaders. By organizations that are figuring it out through trial and error. The playbook is being written in real time, and nobody has the complete version.
That means adapting right now requires tolerating a significant amount of uncertainty. This is hard! It means moving toward something that is not fully defined. It means letting go of approaches that worked, without having a complete replacement ready.
That is uncomfortable for almost everyone. And it is especially uncomfortable for people who have built their professional identity around expertise, because expertise implies knowing. Adapting in an uncertain landscape requires being a beginner again, at least in some dimensions, and that is a real ask for someone who has been doing this work for years or decades.
The most dangerous response to that discomfort is to resolve it by defending. To convince yourself that what you already know is sufficient, that the change is overstated, that the fundamentals have not changed even if the tools have. Because that resolves the discomfort without actually doing the work of adapting. And the relief it provides is temporary.
Tip 1: Learn to Recognize When You Are Defending
The first practical step is developing the self-awareness to catch yourself in a defending posture, in real time, before it shapes a conversation or a decision.
The signal is usually a feeling of resistance combined with a justification. Something in your environment is changing, and you are generating reasons why the change is wrong, premature, or missing something important. That feeling is not always wrong. Sometimes the change is genuinely misguided. But the habit of generating resistance and justification as a first response is worth examining.
Ask yourself, in those moments: am I defending because this approach genuinely creates better outcomes, or am I defending because it is familiar and changing it is uncomfortable? Is this resistance based on evidence, or is it based on investment in the way things have been done?
You don’t have to answer those questions in real time. But getting in the habit of asking them creates a pause between the impulse to defend and the decision about whether to act on it. In that pause, you have a choice.
The other signal worth noticing is when your language is backward-looking. When you find yourself explaining BA value in terms of what BAs have always done, rather than in terms of what the current situation requires. When your arguments for involvement are based on process and precedent rather than on the specific analytical value you can bring to the problem at hand.
Defending sounds like: “this is what we should do because this is how analysis works.”
Adapting sounds like: “here is the specific value I can add to this situation, and here is how I will add it.”
The shift in language reflects a shift in posture, and both are learnable.
Tip 2: Name What You Are Adapting Toward, Even If It Is Incomplete
The second step is doing the hard work of defining what adapting actually means for you, even in a landscape that is still being figured out.
This does not require a complete answer. It does require a direction. And direction is built from small, specific choices about what you are moving toward, not from waiting for clarity before you start moving.
What does it mean for you specifically to do analysis in the flow of a build rather than before it? What would it look like for you to bring a draft/guess problem definition into a rapid prototyping session? What would it feel like to measure your success by decision quality and outcome achievement rather than by artifact completion?
Those are not rhetorical questions. They are worth sitting with and answering specifically, because vague adaptation is not really adaptation. It is just discomfort without direction.
It also helps to find other BAs who are working through the same questions. The answers are not going to come from any single source, and they are going to look different across different organizational contexts. But the people who are trying to figure this out, who are honest about the uncertainty and doing the work anyway, are the most useful community to be in right now.
You do not need to know exactly where you are going to start moving. You need to be honest about the direction and take the next step.
Tip 3: Hold the Tightrope — Some of What You Know Still Matters
The most nuanced part of this is that adapting does not mean abandoning everything you know and are skilled at. Some of what BAs know and do is genuinely foundational, and it matters just as much in an AI-enabled environment as it ever did. The ability to define a problem clearly. The ability to align stakeholders around a shared understanding. The ability to think through edge cases and exception paths. The ability to connect the detail of what is being built to the strategic intent behind it.
Those capabilities do not go away. What changes is how they are applied and where they happen in the delivery process.
The tightrope is holding onto the analytical capabilities that are genuinely durable while letting go of the practices that were vehicles for those capabilities in a different context. Formal requirements documents were a vehicle for the durable work of ensuring shared understanding. They helped developers move faster in what used to be the slowest part of the process. They are not the only vehicle, and in many contexts they are no longer the best one.
The environment will keep changing, and the practices will keep evolving. The BAs who stay relevant are the ones who get comfortable with that as an ongoing condition of the work, rather than a temporary disruption to get through.
The Choice Is Available Right Now
I am not suggesting this is easy. Letting go of things you are good at, moving toward something that is not fully defined, tolerating the discomfort of uncertainty without resolving it by retreating to what is familiar — that is real work. It is harder than learning a new tool or earning a new certification.
But it is the work that matters. And it is available to every BA who decides to do it.
You cannot defend and adapt at the same time. But you can choose which one you are doing, and you can make that choice consciously and repeatedly, in the small moments and the large ones, as the environment continues to change around you.
That choice is yours.
Adapt With a Community Around You
The BAs who navigate this transition most successfully are rarely doing it alone. Having a structured learning environment, honest peers working through the same challenges, and a framework for what adapting actually looks like in practice makes a real difference.
My Maven course series is built for exactly this moment in the BA profession. Not just tools and techniques, but the mindset and the capability development that helps BAs lead in changing environments.
Visit www.maven.com/angela-wick to explore current courses and upcoming cohorts.
The choice to adapt is the first step. Having the right community makes the rest of the journey possible.