Talk Like an Architect: How to Turn Objections Into Decisions

Objections are not the end of a conversation. They are often the start of a deeper, more reflective conversation leading to better understanding overall.

As architects, we are very used to dealing with objections, but sometimes the reflex to “be right” prevents us from using the opportunity to increase our understanding of our stakeholders and their context. Similarly, we raise objections frequently (they don’t call us “argue-tects” for nothing) with our stakeholders, and that helps us make the right decisions, propose the optimal solutions, and achieve the best results.

If you’ve been following the Talk Like an Architect blog mini-series, you’ve already built a toolkit for this one: the building blocks of communication, visual and nonverbal cues, and intentional listening. In part three, you saw how questions could be objections in disguise and how to handle them with flexibility and openness. 

This post goes one step further, exploring objections as a natural part of the conversation and how to handle both your stakeholders’ objections and your own.

Turn stakeholder objections into architectural decisions

Let’s start with the objections we’re more used to: the ones formulated by our stakeholders. 

Objections often fall into three familiar categories:

• Resistance to change: The current (AS IS) process works, they know it, and a new way of working feels like a risk.
• Cost concerns: Stakeholders may wonder whether the proposed solution will meet their expectations, fit their timeline, and justify their investment, both in terms of immediate and long-term cost. 
• Solution fit: They might doubt that the proposed solution will really work in their context.

None of these are unreasonable. Behind each is a stakeholder protecting something they care about, and our job is to find out what.

The building blocks of communication from part one apply here: who is the receiver (your stakeholder), what matters to them, and how will they decode what you say? The reverse also holds true: when your stakeholder is the sender, understanding their context helps you decode what they are telling you. It helps you listen beyond the words (as covered in part three) so you can work out which objection you are really facing and which strategy fits it.

Let’s look at three strategies for dealing with stakeholder objections:

1. Resistance to change: Separate a legitimate concern from discomfort. A regulatory requirement is an important constraint, whereas discomfort with a new screen is a change management topic. The way to determine which one you are facing is by digging deeper and asking questions. This likely means narrowing in on specific steps of your stakeholder’s process until you find the source of the resistance and are able to distinguish one from the other. Treating one like the other is how you end up breaking a compliance requirement or building a suboptimal solution out of politeness.
2. Cost concerns: Do your homework and speak their language. Calculating return on investment (ROI), time to market (TTM), or total cost of ownership (TCO) can be hard to do on the fly, even for experienced architects. This objection is best anticipated and addressed before it is raised.
   • Be proactive in your preparation by using your understanding of the receiver to build your (business) case in their terms.
   • Document your reasoning as you go, using meeting notes to validate your understanding and architectural decision records (ADRs) to document significant architectural decisions and their rationale.
   • Ground your decisions in best practices and established resources like the Well-Architected Framework to demonstrate feasibility, validity, and credibility and to attain relevant guidance on things like establishing TCO as clarified in the Resource and Cost Optimization pillar.
3. Solution fit: Understand when to hold your ground and when to adapt. A missed requirement is a gap in your design, while a stakeholder who can’t see their process in the solution is a gap in your story. Both can sound like “this won’t work for us.” Exploring their process and preparing proactively works most of the time, but sometimes you’ll need to adapt. The best way to determine whether to stay the course or adapt is by reminding yourself of your stakeholder’s north star: their goals and desired outcomes. If your solution still serves that outcome, explain why. If their idea serves it better, take it. Be honest with yourself, don’t get caught up in ego, and focus on the desired result: value added for everyone.

Separating the why, the what, and the how is a reliable way to find out whether you’re dealing with a real constraint or a preferred solution. Miriam McCabe shows how in Requirements Are Not Marching Orders: Read Them Like an Architect.

All three strategies depend on one thing: being confident in your ability to think on your feet. Part of this confidence grows with experience; part of it is built through preparation. The building blocks of communication make that preparation concrete: know your receiver, anticipate their objections, and treat the ones you hear as feedback on your message. Handled this way, an objection stops being a roadblock and becomes a catalyst for a better decision.

Examine your own objections before you raise them

Stakeholders aren’t the only ones raising objections. As architects, when we sit down with stakeholders to understand their process and discuss requirements, we frequently challenge what we’re told in order to better understand their actual needs. Be especially ready to probe further when what you’re told sounds like:

• A solution disguised as a requirement: If a stakeholder is asking for a “custom object,” the first instinct should be to object and dive deeper to understand what data must be captured, by whom, and for what purpose before determining the actual solution. 
• A process missing steps: Exploring a process in depth with stakeholders can often surface gaps or inaccuracies (like an automation trigger being undefined or notifications being triggered by events that are not captured). This prompts you to push back and explore feasible alternatives.
• The AS IS instead of the real need: When reviewing stakeholders’ needs, you may encounter requirements that originate from the current way they operate rather than from the real need (for example, copying information from one system to another). Just like with the solution disguised as a requirement, you should get to the real need underneath.

Often these objections signal that you’re missing information and should use the skills you learned in part three to ask the right questions and fill in the gaps.

Sometimes, even if you have the full picture, you might still raise objections (for instance, to gauge process flexibility or to introduce improvements or innovations). Even if you are sure your objections are valid, you should still treat them with the same care and critical eye as you would those of your stakeholders.

Just like stakeholder objections, yours might stem from an emotional reaction rather than a legitimate concern. Maybe a requirement or important process detail arrived late, causing you to have to rethink your beautifully prepared solution? Perhaps an overlooked constraint is throwing a wrench in the works? Both could very well fuel frustration and resistance, but being honest with yourself about where the objection is coming from will help you decide whether to raise it, how to phrase it, or whether to let it go.

The same strategy that helps you decide when to hold your ground and when to adapt applies here: your stakeholder’s north star. Will raising this objection help produce the desired outcome? In the end, that is the objective you’re trying to achieve, and you’ll only get there by working together.

Keep collaboration at the center of the conversation

Regardless of who raised the objection, remember that collaboration is key. What matters is that the conversation leads to the right decisions and the desired outcomes.

Four practices help keep the conversation productive:

1. Communicate clearly: Whether you’re proposing a solution or raising a concern or objection, make sure your message is as easy to understand as possible and tailored to your receiver and channel.
2. Practice understanding: Both your stakeholder’s process and point of view should be clearly understood to help you assess solutions as well as objections in their full context. If something isn’t clear: ask, framing the question as a way to understand rather than a challenge.
3. Keep it objective: Your stakeholder’s success metrics and expected outcomes create a clear frame of reference to which your solutions, objections, and questions can be tied.
4. Respond with an open mind: You and your stakeholders both want to deliver a successful solution that adds value. By focusing on this shared goal, it becomes easier to assume positive intent, keep an open mind, and remain constructive.

Practice how you talk like an architect 

Objections are part of the conversation, and like any other communication skill, handling them gets easier with practice.

As you refine your approach, remember these three key takeaways:

1. Welcome objections: They are a natural part of gaining understanding and making the right decisions, so don’t shy away from them.
2. Recognize objections, yours and theirs: Noticing when an objection is happening is the first step to deciding how to handle it.
3. Phrase and handle objections constructively: Say what you mean clearly, and respond in a way that keeps both sides focused on the shared outcome.

Before your next meeting, write down one objection you expect to hear and prepare accordingly. After the meeting, check how close you were. If you’d like a lower-stakes place to practice, bring the exercise to a Trailblazer Community Group meeting.