Architecture Process: Getting Requirements from Tech Teams
How to Translate Engineering Feedback into Business-Aligned Goals
In my previous article, I talked about getting requirements from Product Managers. Feel free to take a look before we continue.
Product requirements bring in features, priorities, roadmaps—and if we’re lucky, clear business goals. This is the usual front door into the architecture process. But there’s also a back door. And that one opens from the inside.
I’m talking about your own engineering and ops teams.
You see, as systems grow, so does the mess. And no one feels it more than the people who build and run the thing every day. But here’s the challenge: they don’t usually walk up to you and say, “Hey, I’ve got a requirement!” Instead, they drop in something like:
“We should switch from RabbitMQ to Kafka.”
Or:
“Let’s split this service into two.”
These are not requirements. These are ideas. Sometimes they’re symptoms. Sometimes they’re just random technical preferences. Your job is to figure out what’s behind them.
Running Architecture Sessions
Here’s what I do: I run Architecture Sessions.
They’re not just whiteboarding meetings. They’re trust-building rituals. Because when you’re not part of the team—when you’re the “architect” that only joins calls once in a while—people won’t open up. They don’t see you as one of them.
So the goal of these sessions isn’t to design architecture on day one. It’s to listen. Build rapport. Understand where the real pain is.
And once they start talking, the real work begins.
From Tech Complaints to Business-Aligned Requirements
Let me share a story.
I had a team come to me with two problems. First, their search was painfully slow. They were using MySQL to run text searches across millions of rows. You don’t need to be a database guru to see where this is going.
The suggestion? “Let’s switch databases.”
That’s a solution, not a requirement. So we dug deeper.
It turns out that the business was planning to multiply the dataset by 10 times in the coming year. So this wasn’t just a performance issue—it was a scalability risk.
Additionally, search queries had to adhere to a complex permissions model. Every result had to be filtered based on what the user was allowed to see, which meant that even more complex queries were required. More joins. More delays.
Now we were getting somewhere.
Together, we reframed the issues as actual requirements:
The system must support a one billion-record search within 5 seconds.
The permissions model must allow for fast, permission-filtered queries to complete within 5 seconds.
These aren’t tech preferences. These are system-level capabilities aligned with the business need to scale.
One of them (the search speed) was a local issue for our team. The other (permissions) spanned multiple domains and touched almost every other team in the platform. So I took both to the Product Managers.
Luckily, they understood the risk right away. If we couldn’t search fast enough or filter securely, we’d hit a wall. Fast.
I was asked to develop a plan. So I brought in other architects, engaged the affected teams, and started shaping the path forward. It’s still a work in progress—but that’s not the point.
The point is: this is how you extract requirements from tech teams and tie them to business outcomes.
Listening to Ops: The Quiet Source of Pain
Let’s not forget another group that holds key insights: operations.
Support and infrastructure teams see the system from a completely different angle. And when they complain, they’re usually right.
I group their pain into two buckets:
Instability – Systems that constantly break, need babysitting, or cause pagers to go off at 2 a.m.
Manual Labor – Processes that should have been automated years ago.
Instability affects everything: time to market, morale, even retention. If engineering is always putting out fires, they’re not building features. And if ops can’t trust the system, they start blocking deployments and adding manual checks.
Manual labor is a hidden tax. Infrastructure that requires manual provisioning, scripts that need handholding, tickets that go back and forth like ping pong balls—these things burn through time and money.
Your job as an architect? Facilitate the conversations. Help the teams distinguish between quick wins and deeper systemic issues. And when needed, make the case for investment.
Show Me the ROI
When you’re dealing with technical requirements, especially internal ones, you don’t get the luxury of having a Product Manager make the case for you. That’s your job.
So talk in their language. Show the ROI.
If a system causes five production incidents a week, each eating three hours of triage time from engineers and support, multiply that. Show the impact. Then track how it changes when you fix it.
Same with manual effort. Calculate how many hours are being spent today. Compare it to what you’ll save post-automation. Use that to argue for the change.
You’ll be surprised how quickly people come on board when you make the pain visible.
Wrapping Up
Getting requirements from engineering teams isn’t about gathering a backlog. It’s about:
Listening for pain signals, not feature requests
Translating tech talk into business risks
Acting like a Product Manager for internal improvement
Unlike feature work, no one’s going to hand you a Jira ticket that says, “Improve system stability for better customer retention.” You’ll need to write it yourself.
And if you do it well, the business will thank you later.
Want to learn more?
🎓 Check out the course: Modeling, Viewpoints, C4
🌐 Follow us on LinkedIn: Software Architecture Guild
📖 Explore the Free Guide: Jump to Website