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.
Want to learn more?
Check out the Courses, Follow us on LinkedIn, and Explore the Guide
