Stances & Transformation

The 5 Communication Stances

In her groundbreaking work on family therapy, Virginia Satir identified five communication stances that people adopt when under stress. These stances represent how we respond to perceived threats, disagreements, or high-stakes situations. While Satir developed this model for therapeutic contexts, it maps directly onto the BA-client relationship — and understanding it is the key to transforming from a scribe to a consultant.

Every BA has a default stance — the communication pattern they fall back on when a client pushes back, when requirements are unclear, or when the project is under pressure. Your default stance determines how you respond to conflict, how you handle ambiguity, and ultimately, how much depth you can reach in discovery conversations.

The five stances are: Placating, Blaming, Super-Reasonable, Irrelevant, and Congruent. The first four are non-congruent stances — they represent ways we sacrifice connection, authenticity, or both in order to feel safe. The fifth stance, Congruent, is the goal: it represents balanced, authentic, and effective communication.

Each stance has a characteristic body posture, speech pattern, and impact on relationships. As you read through the next five sections, notice which stances feel familiar — both in yourself and in stakeholders you work with. Awareness is the first step toward change.

Placating — The People-Pleaser

The Placater's core belief is: "I must make everyone happy, or I am not valuable." Placaters agree with everything, avoid conflict at all costs, and say "yes" to every request — even when they know it's unrealistic. They apologize constantly, even when they haven't done anything wrong.

How Placating Shows Up in BA Work:

The Placating BA accepts every feature request without probing. A stakeholder says "I need a dashboard with 15 KPIs" and the BA nods, writes it down, and says "Absolutely, we can do that." The BA never asks whether those KPIs are actually needed, whether there's a simpler solution, or what problem the dashboard is supposed to solve. The result is scope creep, burnout, and delivering solutions that feel technically correct but miss the mark.

The Placating BA also struggles with saying no to unrealistic timelines. When a project manager asks "Can we deliver this in two weeks?" the Placater says "I'll try my best" instead of "Let me show you what's realistic." They over-promise, under-deliver, and then apologize — perpetuating a cycle that erodes trust rather than building it.

How to Shift from Placating: The shift begins with recognizing that your value as a BA comes from your expertise, not your agreeableness. Practice these micro-shifts:

• Replace "yes" with "help me understand": Before agreeing to a request, ask one probing question. "Help me understand what this feature would solve for you." This buys you time and shifts the dynamic.
• Use "I need to think about that": Instead of immediate agreement, create space. "I need to think about how that fits with the current scope. Let me get back to you by tomorrow."
• Practice the "And" statement: "I hear what you're asking for, and I want to make sure we're solving the right problem. What outcome are you hoping for?"
• Set boundaries explicitly: "I can deliver A and B by the deadline. To add C, we would need to adjust the timeline or reduce scope elsewhere. Which would you prefer?"

The goal is not to become unhelpful or rigid. It is to shift from passive agreement to active partnership. A partner says "yes, and here's what that means" — not "yes" followed by silent resentment.

Blaming — The Finger-Pointer

The Blamer's core belief is: "I must be in control and right, or I am weak." Blamers point fingers, find fault, and externalize responsibility. When something goes wrong — and in complex projects, things always go wrong — the Blamer's instinct is to identify who is responsible rather than what can be learned.

How Blaming Shows Up in BA Work:

The Blaming BA blames clients for unclear requirements ("They can't articulate what they need"), developers for delays ("The dev team is too slow"), and project managers for unrealistic timelines ("This schedule is impossible — whose idea was this?"). While there may be truth in each observation, the Blamer's delivery destroys relationships and psychological safety.

The deeper cost is that blaming prevents learning. When a project fails to deliver value, the Blaming BA focuses on who to blame rather than what to improve. They never ask: "What could I have done differently to uncover that requirement earlier?" or "How might I have communicated the technical constraints more clearly?" Without this reflection, the same patterns repeat project after project.

How to Shift from Blaming: The shift requires moving from who's wrong to what's possible.

• Replace blame with curiosity: Instead of "The client didn't tell us about this requirement," try "I wonder what changed that made this requirement surface now?"
• Use "I" statements: "I feel frustrated when requirements change late in the cycle" instead of "You keep changing requirements."
• Focus on the system, not the person: "What about our discovery process allowed this requirement to be missed?" instead of "Who dropped the ball?"
• Practice owning your part: Even if you're 5% responsible, own it. "I could have probed deeper on that point. Let's figure out how to catch this earlier next time."

Super-Reasonable — The Robot

The Super-Reasonable stance is characterized by extreme detachment from emotions — both your own and others'. The core belief is: "I must be perfectly logical and objective, or I will be seen as incompetent." Super-Reasonable BAs focus exclusively on data, documents, and processes, treating every stakeholder interaction as a transaction of information.

How Super-Reasonable Shows Up in BA Work:

The Super-Reasonable BA is technically excellent — their requirements documents are immaculate, their process maps are flawless, their traceability matrices are complete. But they miss the human context behind every requirement. They don't notice when a stakeholder is frustrated, anxious, or excited. They don't explore the emotions driving a request because they don't see emotions as relevant.

This stance is particularly dangerous because it feels professional. In many organizations, being "Super-Reasonable" is rewarded — you're seen as objective, rigorous, and no-nonsense. But the cost is invisible: solutions that are technically correct but organizationally wrong. A workflow that makes perfect sense on paper but fails because it didn't account for how people actually feel about their work.

How to Shift from Super-Reasonable: The goal is not to abandon logic but to integrate emotion as equally valid data.

• Ask about feelings explicitly: "How does this situation make you feel?" or "What's the most frustrating part of this for you?" These questions feel unnatural at first but open up critical information.
• Mirror emotional cues: If a stakeholder looks frustrated, name it. "I'm sensing some frustration. Can you tell me more about what's causing that?"
• Share appropriate vulnerability: "I'll be honest — I'm not sure what the right solution is here. But I'm committed to figuring it out with you."
• Use warmth in your delivery: Slow down your speech. Use the stakeholder's name. Pause before responding. These micro-behaviors signal presence and care.

Irrelevant — The Distractor

The Irrelevant stance is about avoidance. When faced with conflict, tension, or emotional discomfort, the Irrelevant BA changes the subject, deflects with humor, or disengages entirely. The core belief is: "If I don't engage with the difficulty, it might go away."

How Irrelevant Shows Up in BA Work:

The Irrelevant BA deflects difficult conversations. When a stakeholder raises a sensitive issue — perhaps their team is resistant to change, or they're worried about job security after the system is implemented — the Irrelevant BA changes the subject back to technical specifications. When a developer expresses concern about a timeline, the Irrelevant BA makes a joke and moves on.

This stance is often a survival mechanism. BAs who feel ill-equipped to handle emotional conversations or conflict default to distraction because it feels safer than engagement. But avoidance has a cost: the difficult conversation doesn't go away. It festers. The stakeholder's unspoken concern becomes resistance later. The developer's timeline concern becomes a missed deadline.

How to Shift from Irrelevant: The shift requires building tolerance for discomfort.

• Name the discomfort: "This feels like a difficult conversation. That's okay — let's stay with it."
• Use silence: When you feel the urge to deflect, pause. Count to five before speaking. Let the silence hold the space.
• Practice staying on topic: When you notice yourself deflecting, gently redirect: "Let me make sure I understand what you're saying..."
• Prepare for difficult conversations: Before a meeting where conflict is likely, write down three questions you will ask. Commit to asking them even if it feels uncomfortable.

Congruent — The Integrated Communicator

Congruence is the goal. A Congruent communicator is fully present, authentic, and balanced. They honor their own experience and the other person's experience simultaneously. They don't sacrifice themselves to please (Placating), attack to control (Blaming), detach to feel safe (Super-Reasonable), or avoid to escape discomfort (Irrelevant). They show up as they are and invite others to do the same.

Congruence in BA Practice:

• Deep listening: The Congruent BA doesn't just hear words — they listen for emotion, for what's unsaid, for the story beneath the request. They ask follow-up questions that show they were truly paying attention.
• Respectful probing: They know the difference between probing and interrogating. They use phrases like "Help me understand" and "I'm curious about" rather than "Why?" which can feel accusatory.
• Holding space: When a stakeholder shares something vulnerable — "I'm worried this system will make my team obsolete" — the Congruent BA doesn't rush to reassure or deflect. They sit with the concern and explore it. "Tell me more about that fear. What would make this feel safer for your team?"
• Authentic presence: They admit when they don't know something. They share their own reactions appropriately. They are human, not a requirements-gathering machine.

Self-Diagnosis Quiz

This quiz will help you identify your dominant communication stance in BA contexts. For each scenario, choose the response that feels most natural to you. There are no wrong answers — this is about self-awareness, not judgment.

Stance-Switching Techniques

Knowing your default stance is the first step. The second step is developing the ability to shift intentionally toward congruence. Each non-congruent stance has a characteristic switching technique — a mental and behavioral move that helps you realign.

Question Bank & Scripts

This section contains practical scripts and question banks organized by meeting type. Use these as templates — adapt the language to your natural voice, but keep the underlying stance Congruent.

Rapport-Building Questions

Use these at the beginning of a relationship or when reconnecting after a gap.

• "What's been on your mind lately regarding [project area]?"
• "How are things going for you and your team outside of this project?"
• "What's one thing you wish I knew about your work that I haven't asked about yet?"
• "What's your biggest hope for this project? And your biggest worry?"
• "Who else should I be talking to? Who sees this situation differently?"
• "What's the history here that I should understand?"
• "What does a good day look like for you? What does a frustrating day look like?"
• "If you could wave a magic wand and change one thing about your current workflow, what would it be?"

Problem Exploration Questions

Use these when moving from surface request to deeper need.

• "Help me understand: what problem are you trying to solve?"
• "What happens if we don't solve this? Who feels it most?"
• "Walk me through what happens today. Where do you get stuck?"
• "What have you tried so far? Why didn't that work?"
• "Who else is affected by this problem? How?"
• "What's the most painful part of this process for you personally?"
• "What would need to be true for this to no longer be a problem?"
• "How long has this been going on? What changed?"
• "What's the cost of not fixing this — in time, money, or morale?"
• "If you could describe this problem in one sentence, what would you say?"
• "What keeps you up at night about this?"
• "What's the story behind this request? How did it come to be a priority now?"
• "What's the impact on your team if this doesn't get resolved?"
• "On a scale of 1-10, how urgent is this? What makes it that number?"
• "Is this a symptom of a deeper issue? What do you think the root cause is?"
• "What would your team say if they were in this room? What might they add?"
• "If you solve this perfectly, what else might change as a result?"
• "What have you seen tried before in other organizations? Why didn't it work?"
• "What assumptions are we making about this problem? What if they're wrong?"
• "What's the emotional cost of this problem? How does it affect how people feel about their work?"

Needs Discovery Questions

Use these to surface the deeper yearnings and identity needs behind a request.

• "What would this solution mean for you personally?"
• "How will you know this is successful? What does success look like to you?"
• "What would change in your day-to-day work if this was working perfectly?"
• "Who notices when this works well? Who notices when it doesn't?"
• "What does 'good enough' look like? What does 'amazing' look like?"
• "What would this solution say about you and your team to the rest of the organization?"
• "How does this connect to your team's broader goals? To your personal goals?"
• "What would make you proud to show this off?"
• "When you imagine the ideal solution, what does it feel like to use it?"
• "What would this free you up to do that you can't do now?"
• "How does this align with where you see your team going in the next year?"
• "What recognition would feel meaningful to you if this succeeds?"
• "What would need to happen for you to feel fully confident in this solution?"
• "What's at stake for you personally if this project fails?"
• "What does 'being successful' in your role mean to you? How does this project support that?"

Solution Co-Creation Questions

Use these when moving from problem understanding to solution design.

• "Given what we now know about the problem, what solutions come to mind for you?"
• "What would an ideal solution look like if there were no constraints?"
• "What's the simplest thing that could possibly work?"
• "What trade-offs are you willing to make for speed vs. completeness?"
• "If we could only solve one part of this, which part would deliver the most value?"
• "Who else should be in the room when we design this?"
• "What have you seen work in other contexts that might apply here?"
• "What would you advise a colleague to do if they were facing this same problem?"
• "Let's sketch three possible approaches — what feels right about each one?"
• "What's your intuition telling you about the right path forward?"
• "How would we test whether a solution is working before fully building it?"
• "What would a minimum viable version of this look like? What would it need to prove?"
• "If we build this, what else might break or need to change?"
• "What resources or support would you need to make this successful?"
• "How would we know if we're going in the wrong direction early enough to pivot?"

Closing & Commitment Questions

Use these to ensure alignment and clear next steps.

• "Before we wrap up, is there anything we've missed? Any concern you haven't voiced?"
• "On a scale of 1-10, how confident are you in the path forward? What would make it a 10?"
• "What are your top three priorities from our conversation?"
• "What will you do differently as a result of this conversation?"
• "What will I hold myself accountable to deliver before we meet next?"
• "What would make our next conversation most valuable for you?"
• "Who else needs to hear about what we discussed? How should we bring them in?"
• "What's the one thing you don't want to drop between now and our next check-in?"
• "If something comes up that changes your priorities, how will you let me know?"
• "What would success look like for our next meeting? What outcome would make it worth your time?"
• "Is there anything you're hesitant to commit to? Let's name it so we can address it."
• "What support do you need from me between now and our next milestone?"
• "How do you prefer to handle decisions that come up between our meetings?"
• "What's the best way to reach you if something urgent comes up?"
• "Before we close, let me play back what I heard and check if I've got it right..."

Meeting Scripts

Script 1: Project Kickoff Meeting

Script 2: Discovery Workshop Opening

Script 3: Handling a Difficult Stakeholder

Script 4: Requirements Review with Pushback

Script 5: Post-Mortem / Retrospective

Script 6: Stakeholder check-in (mid-project)

Script 7: Managing scope creep

Script 8: Escalating a concern to leadership

Script 9: Closing a discovery phase

Script 10: Saying no to a feature request

Transformation Roadmap

Changing your default communication stance is not a one-time decision — it is a practice that unfolds over months. This roadmap takes you from self-awareness through mastery, with concrete milestones and checkpoints at each stage.