Architects are often hired for their technical judgment. But the key moments that determine whether a project succeeds are often not technical in nature. Success can depend on whether a stakeholder trusts you enough to hear “here’s something better than what you asked for” without feeling dismissed.

Once the requirements have been discovered, they can be worked through as what, how, and why. That final why is the architect’s why: the rationale for how you decided to meet the requirement, and it comes last. At this stage, however, you don’t have a decision yet. The why you’re looking for here is the stakeholder’s why, the reason they’re asking for a change at all, and that why comes first. You need to understand that why so that you can empathize with your stakeholders, understand their needs, and ensure your proposal serves their why. Once you get into serious design mode, your proposals get their own why, along with a record of what you decided and the reasoning behind it.

If you’ve worked in a more formal systems engineering environment, this maps onto a familiar hierarchy: the why aligns with the business or stakeholder requirement, the what with the high-level requirements, and the how with the low-level requirements. In this kind of formal systems-engineering process, multiple teams are involved in the careful decomposition of the business requirement into high- and low-level requirements. When all three arrive jumbled together, however, it falls to the architect to perform that decomposition. In less formal contexts, many stakeholders do exactly that: hand you their whys and whats tangled into a single ask, sometimes with a lot of how mixed in as well.

Pulling them apart helps you read a requirement clearly. Putting them back together in the right order can help you pitch your approach. 

Read for the why

Every requirement you’re handed started as a problem or a need. But by the time the requirement reaches you, the underlying problem or need has often already been translated into something more concrete. This is a common pattern, perhaps because a concrete requirement asking for something tangible feels like the language a technical team will respond to. Remember that your stakeholder is trying to help you understand what they need, rather than deliberately making it harder for you to help them.

Imagine a request for proposal (RFP) for a vendor certification compliance solution. The requirements section reads like a set of solid specifications: store certification records, notify someone before a certification lapses, let staff check status. But hidden in the background section is a detail that tells a different story: an internal audit has flagged vendor engagements that continued under lapsed certifications, and nobody caught it before the audit did. 

That sentence sits a whole section away from the actual requirements, yet it is the reason the RFP exists: to prevent the next audit finding. Finding a sentence like that in a document is different from asking “why?” out loud in a room. Nobody answers you while you’re reading, so you have to look for the answer in the document itself.

Use language clues to find the why 

Requirements often describe an action the system should take: store this, notify that, let someone check something. A why, in contrast, describes a consequence for the business, something that already happened or something the stakeholder is trying to avoid, independent of any particular system. 

Causal language is one clue. Phrases like “because,” “in order to,” or “so that” often introduce a why because they’re the language of justification. Consequences are another clue. An audit finding is a consequence that has already happened. A risk of compliance exposure is a potential future consequence that the customer wants to prevent.

As you read, ask why each sentence is there. Does it describe what the system does or should do, or is it about what happens to the business if a problem isn’t solved? If it’s the first, you’re likely in requirements territory. When a justification shows up, you’re looking at a clue to the why. 

Once you’re in the room, you can ask directly. Part three of Lilith Van Biesen’s Talk Like an Architect series is a helpful resource for preparing for this conversation: active listening, the 5 Whys technique, and the questioning discipline that draws out context a stakeholder hasn’t volunteered. Essential Skills for Business Analysts Uncovered on Trailhead covers the same ground if you’re new to this practice.

Separate the what from the how

Once you have the why, go back through the stated requirements with a question in mind: is this a what, or is it a how dressed up as one?

Imagine you’re reading through the requirements for a vendor certification compliance RFP, and you find this: “the solution shall include a new custom data object.” Even if this is requirements language on the surface because of the “shall,” that sentence is really asking for a specific how before you have confirmed that the requirement calls for a new object at all. 

The requirement only needs to specify the following details: store this data, with these attributes, tied to the vendor. Whether that lives on a custom object, a standard object, or a related list of files is your decision to make once you know the shape of the data, not the business’s to make for you.

A few lines later, you find this: “the solution shall generate an automated notification to the assigned vendor manager.” A notification request is rarely just a notification request. Asking for a notification is often asking for the smallest possible fix: automate the one step someone’s tired of doing by hand, without stepping back to ask whether that step should exist at all. Make a note to ask questions about who this person is, why they’re the one who needs to know, and, most importantly, what they actually do once they have been notified. That last question is the one you’ll come back to.

It’s also worth reading for what’s absent. Say the same document is specific about who gets notified before a certification lapses, and specific about how much advance warning they get. Now imagine there is absolutely no mention of what happens after one actually lapses. Is the vendor blocked from new work? Flagged for review? When you tie back to the why, you will notice this as a gap the requirements don’t address. This lets you proactively propose a solution to your stakeholder, one they didn’t ask for and may not have considered. 

Understand the business process before you solution

Before you propose anything, make sure you understand the target state business process. Understanding the process and the actors in it helps you spot where the business might be asking you to automate an inefficiency rather than build something optimal. Spending ten minutes sketching out the process based on the document is an investment that pays for itself every time.

In our hypothetical RFP, say you draw the vendor certification process, and it becomes apparent that the notification does nothing more than prompt the vendor manager to check a system and notify the vendor. Clearly this looks like a step that could be automated, cutting out the vendor manager as the intermediary. What drawing the business process can reveal is that no new system is needed at all, or that the goals might be better achieved by changing who’s accountable for a step, in this case the vendor.

Now imagine the process confirms that a system change is the right answer anyway. What the sketch still gives you is a way to structure the questions you have about the process, so you have them in your back pocket for the conversation ahead. It is also a perfect throughline for showing you understand the business when presenting your proposal. 

Propose more than one how

Understanding the why and the whats at this level also lets you do something many requirement responses skip: propose two hows instead of one. The first is the literal how, a solution that satisfies exactly what was asked: notify the vendor manager before a certification lapses, the way the RFP describes it. 

Propose this first version even when you’re confident it isn’t your recommendation. You want to show your stakeholder that you can solve for the literal requirement, and you will. It proves you understood the request, and it becomes the baseline your better idea gets measured against.

The second is the alternative how, and you can create space for it by walking your stakeholder through the process improvement suggestions that follow from your business process. In this case, you can suggest notifying the vendor directly instead of the vendor manager, and checking a system rather than making this a manual effort for the vendor manager. 

The what is the same: someone finds out in time to act. But tweaking it by changing the actor (and aligning an alternative how) will reduce risk when it comes to the why of preventing audit issues as there is less room for error when you cut out the additional actor. 

When you are solutioning and getting into alternatives, make sure that you are able to clearly distinguish which parts of the solution are relevant regardless of the approach selected and which ones are specific to each how. This will help your stakeholders understand which changes in the solution support an alternative way to look at the business process.

Pitch to your stakeholder using this four-step process

When you have completed your analysis, and have a clear idea of the options you see, it is time to pull it all together to prepare for a stakeholder conversation. This is the step where you will use the context you gathered to bring your stakeholder along.

This repeatable process has four steps:

1. Show you understand their why

2. Show you can meet their requirements 

3. Show an alternative that meets their why better

4. Provide a recommendation

Follow these steps to ground your recommendations in the analysis you did in a way that will resonate with your stakeholder.  Let’s see what this would look like for the vendor certification RFP example:

1. Show you understand their why: State it in one sentence before you show anything technical: we understand you want to prevent compliance issues that come from operating with uncertified vendors. 
2. Show you can meet their requirements: Using the process map you created, walk through the literal how, using their own language: we can store this information in Salesforce, notify the vendor manager, and let employees check the status Here’s how we’d solve that. If you skip this step, your alternative could be read as a correction instead of an extension. Worse, your stakeholder may think you are proposing an alternative because you cannot meet their requirements.
3. Show an alternative that meets their why better: Using the process map you created of a possible improved process, propose a better alternative: based on our experience, depending on [insert the key questions you identified], there’s a possibility for process improvement. Here’s what that would look like and how we’d solve that. 
4. Provide a recommendation: This is mandatory; providing options without recommendations is sloppy advisory. That said, without the full context, the most appropriate recommendation often has multiple stages, for example, recommend a process improvement to notify the vendor directly, followed by further automation depending on risk appetite. This approach leaves room for negotiation and opens the conversation, while at the same time it shows your stakeholder that you understand them and want to solve their pain points. From here, if all goes well, you will have laid the foundation for opening up the discussion to address any remaining open questions.

A few things that make this land, regardless of the scenario:

• When someone’s attached to a specific how, don’t argue the how. Find out what they’re measuring success by (cost, time-to-market, risk) and make your case in those terms instead.
• Make your thinking visible, not just your conclusion. What earns trust in the room is that the why, what, and how behind your recommendation are visible enough for someone else to follow, and disagree with, if they need to. In this case, we used a process map as a vehicle, but any artifact can work, including a system landscape.

Next steps

To read more about communication skills for architects, check the full Talk Like an Architect blog series:

1. Part one: Talk Like an Architect: How to Use the Building Blocks of Communication
2. Part two: Talk Like an Architect: How to Use Visual and Nonverbal Communication
3. Part three: Talk Like an Architect: How to Listen and Respond Intentionally

To see the preparation steps for using this framework in action, check the recording of the Think Like an Architect livestream series episode “Navigate Tradeoffs and Say No with Confidence.”