Architecture Process: Who Is the Stakeholder and How to Find One
Who Really Holds the Stakes? Navigating the Human Side of Architecture
We hear about "working with stakeholders," "managing stakeholders," and "addressing stakeholder concerns" all the time. These phrases show up in every job description for managers and architects. But what does it actually mean? Who are these stakeholders, and how do you find them?
Let's dig in.
What Is a Stakeholder, Really?
Start with the basics. The word "stakeholder" is everywhere, but let's break it down:
Stakeholder (noun)
A person or group with a stake—a share, an interest, or responsibility—in a business or organization's success.
Anyone who is involved with or affected by what the organization does, from employees and customers to investors and, in many cases, even society at large.
In practice, a stakeholder is anyone with a genuine interest in the success (or failure) of the business. In a modern company—whether you're building SaaS, manufacturing cars, or running a bank—technology is a significant part of that success. And that means software architecture isn't just a technical concern; it's central to business outcomes.
So, who are the stakeholders in software architecture? Let's go through them, from the obvious to the less obvious.
The First Stakeholder: Other Architects
This might sound self-serving, but it's true. If your organization is bigger than a couple of engineering teams, chances are you're not the only architect. The other architects are your first stakeholders. You share responsibilities, often overlap on decisions, and depend on each other for feedback, challenge, and support.
Engineering Teams—And Their Managers
Next up: the engineering teams. Not just developers and testers, but especially the managers of those teams. There's a common misconception that architects are just senior engineers making "technical decisions." In reality, architects make structural decisions: What should live in which service? What parts belong together in a monolith? These choices directly impact team boundaries, ownership, and delivery, making engineering managers critical stakeholders.
If you're only talking to engineers and ignoring their managers, you're missing half the picture. Managers have their own set of priorities and constraints, and they're the ones who make decisions about team boundaries, ownership, and delivery cadence—decisions that often shape (or constrain) your architecture as much as any technical choice. Meanwhile, as an architect, you'll sometimes make recommendations that run straight into the reality of the current organizational structure—hello, Conway's Law. If you don't engage managers early, you risk designing systems that appear great on paper but fail to align with how the organization actually works.
Product Management—Your Virtual Boss
Now, the product manager. Or, more broadly, whoever owns business-side prioritization. In practice, this is the person whose priorities should shape much of your own, even if you don't report to them.
Why does this matter? Because product management defines what's important now, what's coming next, and what will actually make a business impact. Their vision determines which problems are worth solving and when they should be addressed. Suppose you're not regularly aligned with the product. In that case, your architecture decisions will drift, and you'll end up prioritizing technical "improvements" that nobody asked for—while the business is caught off-guard by the actual cost of every new feature.
Here's what usually happens when you don't work hand-in-hand with the product:
Features are requested and prioritized without input from architecture.
You're suddenly asked to provide a timeline for a capability that the system isn't yet ready for.
You reply, "We need six months to do this right, since the architecture doesn't support it."
The business says, "We don't have six months. Is there a shortcut?"
You offer a workaround. It creates tech debt.
Everyone shrugs, promising to fix it "later." That day rarely comes.
People often blame the business for tech debt, but in reality, the architect who fails to look ahead and make the case for technical enablers is the one primarily responsible. If you haven't prepared the system for what's coming—and haven't explained the why to the product—you're not doing your job.
Good architecture means looking ahead, understanding what the product needs, and making sure the system is ready before the "urgent" request arrives.
Operations—The Overlooked Stakeholders
Here's a group that's often overlooked: operational teams. Support, infrastructure, IT, and platform operations—these people are the primary consumers of your architecture. If you want to know what's broken, don't just ask engineering; ask support or infrastructure. They'll give you a list of pain points that's ten miles long.
Product managers often skip these teams when gathering requirements, focusing more on sales, marketing, or customer feedback. I make it a point to represent these voices, mapping operational needs to business objectives and helping build a case for their priorities.
Sales and Marketing—Reading the Room
You might not think of sales and marketing as stakeholders in architecture, but I always keep an eye on them. Even just monitoring deal announcements in Slack or a mailing list can reveal a lot about business momentum. If you see deals closing fast and at high value, maybe now's a good time to propose that modernization project. If things are slow, focus on features that help close more business.
Your Manager—Depending on the Org Structure
The role your manager plays as a stakeholder is closely tied to how the architecture function is positioned within the organization. There are two main scenarios, each with its own dynamic and pitfalls.
Scenario 1: Architecture Is Separate from Engineering
In this setup, architecture is recognized as its own discipline. You typically report to a Head of Architecture or a Chief Architect. This manager usually understands what architecture actually is—and, just as importantly, what it isn't.
Here, you're assigned a domain or area to own. You're expected to work closely with engineering managers and product managers, but your reporting line stays within architecture. Your job is to evaluate the current state, compare it to business objectives, and establish a technical direction that will guide the business toward its desired goals.
One important thing to note: in this structure, your manager expects you to be autonomous. They don't want (or need) endless status reports or to be involved in every technical decision. Bring them problems and recommendations only when you genuinely need their input or organizational support. The less you distract your manager with noise, the better—make sure you're always prepared with details in case you're asked. You're accountable for both representing your domain to the architecture function and feeding key information back to the rest of the business.
Scenario 2: Architecture Integrated into Engineering
This is a very different world. Here, the architect is embedded within the engineering function and usually reports to an engineering manager or CTO. This setup is widespread in smaller companies or in organizations that see architecture as a "senior engineering" role.
In practice, your manager may have a limited understanding of architecture, which is often why you were hired. Your mandate becomes: close the gap, lead the way, and even educate your own manager and peers about what architecture is supposed to deliver. This isn't always easy. Your manager's expectations will be shaped by feedback from their other reports and the engineering teams themselves, so your influence depends on your ability to solve real problems, earn trust, and demonstrate value.
If the architecture function is too deeply buried in engineering, you risk losing perspective. You can't design a building if you never step outside and look at the whole structure; you can't design a system if you're just another member of one dev team. This is also where you often need to help your manager communicate with higher-ups, such as when they're asked to prepare technical presentations or explain their technology strategy to executives. Step up—make your manager look good.
A Note on Reporting Lines
Depending on the company's size and maturity, you may find yourself somewhere between these scenarios, or shifting between them as the business evolves. Sometimes, the "only architect" reports directly to a CTO, but the dynamics above still apply.
Regardless of the scenario, recognize that your manager is always a stakeholder. Their perception of your impact, your ability to deliver on what the organization actually needs, and your skill in bridging gaps between business and tech—all of that will determine whether you're set up for success or struggle to get buy-in.
The Executive Stakeholder
Sometimes, you'll find yourself presenting to executives, C-level, or VPs.
This happens in two cases:
Things are going bad, and you need to explain the way out of a mess.
Things are going well, and you have a chance to pitch a bold architectural vision.
Either way, prepare thoroughly. You'll have a couple of minutes at best to get their attention and keep it. Remember, these people are ultimate stakeholders: their vision and money set the boundaries for what's possible, even if you're not taking direct requirements from them.
Why Stakeholder Work Dominates the Architect's Job
As The Architect Elevator puts it, the architect's primary function is to collect information from one group of stakeholders, process it, and provide it to another. In an ideal organization with perfect communication, architects wouldn't be needed. If you ever come across such a company, please let me know—I'm genuinely curious about how it works.
For the rest of us, identifying stakeholders and bridging communication gaps is the job. That's why architects are hired.
What Does It All Mean in Practice?
At its core, your job is to create a bi-directional flow of information:
Understand the business and explain it to the engineering team.
Understand the technology and its key pain points, and clearly explain them to the business.
It really is that simple—and that difficult.
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