Engineering Judgement Framework > Ownership > Stakeholder Thinking
ENGINEERING JUDGEMENT FRAMEWORK
LEVEL 2
|
OWNERSHIP
Stakeholder Thinking
The best solutions work for the people who must live with them.
Level 1 was about executing.
Level 2 begins with ownership, and ownership expands the boundary of responsibility.
A good software isn’t just about design and code. It’s about the human ecosystem it’s built for.
Strong engineering doesn’t just ask: “Does this work?”
It asks: “Who does it affect?”
Prefer a video instead of reading? Here it is.
TABLE OF CONTENTS
Understanding the People Around Your System
A software doesn’t exist in isolation. It serves people, and those people have different goals, constraints, and expectations.
A programmer asks: Will my code run 24×7?
A developer asks: Who will support this system at 2 am?
An engineer optimizes for what’s visible in the moment. A mature software developer designs for everyone who will live with the system and be impacted by it over time.
Example
Imagine you’re building an alerting mechanism for production failures. A programmer might focus on ensuring alerts trigger correctly when something go wrong.
A developer thinks further:
- Will on-call engineers get too many alerts and burn out?
- Will alerts be clear enough to act on quickly, or will the responders waste time figuring out what went wrong?
- Will support teams know how to fix the issue by themselves, or will they need to escalate every incident?
- Will future engineers understand why these alert limits were chosen?
A technically brilliant alerting mechanism will still fail if it overwhelms users and confuses responders.
Software development isn’t just about making systems work. It’s about making systems work for the people who live with them.
Identifying Your Stakeholders
Identifying stakeholders early prevents blind spots, reduces friction, and leads to decisions that scale technically and meaningfully.
Start by asking:
- Who are my stakeholders?
- Who is affected by this system directly?
- Who is affected indirectly?
- Who inherits the consequences of my decisions?
The list will be larger than you expect.
Users or Operators
Users are the people who directly operate your system. They log in, configure settings, monitor behavior, and make decisions through it. They care about usability, speed, clarity and control because they live inside the system every day.
A technically brilliant system that frustrates its operators is a failure, no matter how clean the code is.
End Users or Consumers
End users are the people your system ultimately exists to serve. They are the ones who are affected by the system’s outcomes, even if they never see or touch it. They experience the consequences of the choices users make via reliability, performance, fairness, cost and quality of service.
A system that doesn’t create real value for its end users, no matter how elegant, fails its purpose.
Example
In the telecom systems I built, the users were network engineers who configured rules, thresholds, and policies in the system. The product had to support their workflows, reduce errors, and help them make confident decisions.
But the end users were mobile subscribers, real people roaming internationally and using their phones. They never interacted with the system directly, yet their call quality, data speed, and roaming experience depended on it.
Designing only for direct users risks building products that are efficient but harmful downstream. Designing with end users in mind ensures the system serves its real-world purpose, and not just its operators.
But don’t stop here. There are many more stakeholders of your system.
Business Owners
Business owners care about outcomes: revenue, growth, efficiency, cost, and risk. Engineering decisions should support business priorities, not run parallel to them.
Operations & Support
These teams live with the consequences of engineering decisions. If issues are hard to diagnose or reproduce, support cost rises, and you lose customer trust in spite of having a good product.
QA
QA cares about testability, edge cases, reproducibility, and release confidence. Systems that are difficult to test create blind spots, and blind spots create incidents.
Leadership
Leadership cares about predictability, risk exposure, timelines, and long-term sustainability. Clear technical decisions reduce uncertainty and improve strategic confidence.
Engineering
Don’t forget yourself. You and other future engineers inherit today’s decisions. Readable code, clear documentation, sensible architecture, and explicit trade-offs determine whether a system becomes an asset or a burden. Ownership includes respecting future engineers.
Knowing Where the Burden Falls
Ownership means recognizing that:
- Users live with your design decisions every day.
- End users experience the consequences of those decisions in the real world.
- Business teams absorb the financial impact.
- Support bears the operational and diagnostic pain.
- QA absorbs the uncertainty you create.
- Leadership absorbs the strategic risk.
- Future engineers absorb the architectural debt.
Every technical decision redistributes burden somewhere. Ownership is knowing what burden every stakeholder carries and making it manageable.
Stakeholder Behavior & Impact
Understanding stakeholders isn’t just about knowing who uses the system. It’s about anticipating how they will behave, what they will struggle with, and what they will experience when things go wrong. Mature engineering considers human behavior as seriously as technical correctness.
Mature problem framing starts with asking:
- What are my boundaries?
- What is flexible?
- What is not?
Example
Imagine building a tool for customer support agents to help them resolve complaints. A surface-level approach focuses on whether the system functions.
A mature approach goes deeper:
- What will agents see when things work?
- What will they experience when things break?
- What will they do when complaints escalate?
- What short cuts will they take under pressure?
- How much training will they realistically receive?
A system that merely works helps the company operate. A system designed around real user behavior helps people perform better, faster, and with fewer errors.
A software is ultimately a human system wearing a technical interface. Behind every requirement are people making decisions, responding to events, and living with the consequences. When you design with people in mind, a software becomes usable, not just functional.
Technical excellence without human awareness is incomplete. Real engineering serves the people around the system, and not just the system itself.
CONTINUE THE JOURNEY
NEXT ARTICLE
Testing Strategy
What you choose to test reveals what you value most.
Continue Reading
Previous
Disciplined Execution
Next
Testing Strategy
