
The real ask
- Enterprise architecture , Strategy , People
- July 27, 2025
One of my mentors, Steven Caus, always taught me the concept of “the question behind the question”: The question we receive is not always the problem we need to solve.
The concept is very easy. When someone comes to you with a question to do something, instead of blindly doing the ask, take a step back and try to understand what they actually want to achieve. Often this task might actually not be the best way to achieve the goal they are set out to do.
What Is the Real Ask?
So let’s start with an example story.
A project team comes to you with the ask for a new project management tool. They’d already narrowed it down to three shiny options, each with slick demos and long feature lists. All they want is your take: which one fits best with our architecture and strategy?
Before you dive into the selection process, you ask: “What’s wrong with the one you have now?”
Their answer comes fast: “It’s old, it’s slow, and everything is manual. We’re already drowning, this tool is just dragging us down further.”
In this case, the tool is not really the issue. The real issue is that the team is overworked and/or understaffed for the current workload. Sure, the tool might be old and slow, but the real pain point is not going to go away with a new shiny tool. In fact, new tools bring migrations. Setups. Training. And none of that helps when you’re already gasping for air.
Instead, we can look upstream: Could we ease the pressure on their pipeline? Automate the worst manual steps? Give them breathing room without introducing a six-month, and figure, rollout?
They won’t be thrilled at first. No shiny new toy. But we saved serious money, dodged a risky project, and actually helped fix the real problem.
All because we paused to ask the question behind the question.
Why does this happen?
We as architects have the benefit of a bird’s eye vision of an organization. This is a luxury that not a lot of teams have. We sit where we can trace lines across systems and spot patterns that others might miss.
But the project team in our story? They were deep in the reeds, overworked, short on time, and grinding through manual tasks that drained their energy. From their vantage point, the tool looked like the enemy. And who could blame them? When you’re underwater, you sometimes dream of better scuba gear instead of the shore.
These conversations aren’t about proving someone wrong. They’re about collaboration. You’re not trying to be the smartest guy in the room, you’re trying to help. They know the grind, the details, the day-to-day. You bring the context and the different lens.
They might not be aware of what’s possible or what other teams are doing, and you are not aware of the processes they are using.
The question behind the question isn’t a challenge. It’s a sanity check. A way to align intent with action.
Why architects keep falling for the trap
We all want to be helpful, especially to a team that seems to be struggling. If they come to you with what looks like a silver-bullet solution, it’s hard to say no.
Telling them they can’t have the new tool, or that their idea might not fix the real issue, feels like letting them down.
It is, however, your job.
Our role isn’t to rubber-stamp requests. It’s to protect the long-term health of the organization. And that means recognizing when a “solution” might actually add more weight to a system that’s already strained.
A quick fix that doesn’t solve the root cause becomes baggage. And that baggage sticks around for years.
Do the hard thing now, so you don’t have to dig yourself out later.
How to surface the question behind the question.
Getting to the real ask takes finesse.
If you come in swinging with, “What are you really trying to achieve?”, people get defensive. It sounds like a challenge. Like you’re poking holes in their thinking.
Same goes for, “It sounds like what you actually want is…” That reads as smug, even if you mean well.
So take a different tack. Ask about their pain points. What’s frustrating? What’s taking time? What feels like it should be easier?
Look for patterns. Oddities. Things that don’t line up. Compare their setup with how other teams work. Look at the rest of the organization.
And when you’ve gathered enough threads, step back and hold them up. _“So the tool’s slow and the work is tedious, and you’re already stretched thin. Would switching tools really fix that, or just add another burden?”
It’s a little like a detective story. You’re not here to interrogate. You’re here to investigate. To ask the quiet questions that lead to real answers.
And you’re not doing it alone. You’re on the same side of the table. Solving the same mystery.
Beneath the Surface
People don’t always ask for what they really need. They ask for what they think will stop the bleeding as fast as possible. That’s human.
Your job is to listen, poke gently at the edges, and find the story underneath… That’s what separates an architect from an administrator.
Sometimes that means you’ll disappoint them in the short term. But if you’ve done your job right, you’ll be solving real issues and not introduce future ones. Because in architecture, the easy answer rarely ages well.