🧠 Understand the System, Not the People: The Mindset That Changes How You Work and Lead
🧠 Understand the System, Not the People: The Mindset That Changes How You Work and Lead
Why workplace problems are rarely solved by blaming individuals, and how understanding processes, incentives, communication, and organisational behaviour can make you a better professional.
Have you ever worked with a team where the same mistakes happen repeatedly?
A deployment fails, and everyone blames the engineer. A deadline slips, and the manager blames the developer. A customer complains, and the support team blames the product team. Meetings become longer, frustration increases, and everyone starts defending themselves.
Then, a few weeks later, the same problem happens again.
Sound familiar? 🤔
Here is the uncomfortable truth: when the same problem keeps appearing, the problem may not be the people. It may be the system in which those people are working.
A system includes the processes, incentives, responsibilities, tools, communication channels, policies, and constraints that shape people’s decisions.
Think about it this way. If several engineers repeatedly deploy the wrong configuration, you could conclude that your engineers are careless. Or you could investigate why the deployment process allows an incorrect configuration to reach production.
One approach creates blame. The other creates an opportunity to improve.
This principle applies to software engineering, DevOps, management, business, relationships, and everyday life. Understanding the system does not mean ignoring personal responsibility. It means looking beyond the most obvious explanation before deciding what needs to change.
Let’s explore how this mindset works in the real world. 🚀
PART 1: Why Understanding the System Is More Powerful Than Blaming People
1. Repeated Problems Usually Deserve a Deeper Investigation
Imagine that a company experiences five production incidents in one month.
The immediate reaction is to ask:
Who made the mistake?
Who approved the deployment?
Why did the engineer not check the configuration?
Who should be held responsible?
These questions might be relevant, but they do not explain the entire problem.
A better investigation asks:
Why could the incorrect configuration reach production?
Was there an automated validation step?
Were deployment responsibilities clear?
Could the engineer safely stop the release?
Did monitoring identify the problem quickly?
Was the rollback procedure documented and tested?
The difference is important.
If an engineer makes a mistake because a process is confusing, fixing the process may prevent similar mistakes across the entire team. If the problem is caused by inadequate training, the solution may involve training and better documentation. If the engineer deliberately bypassed an agreed safety control, accountability is also necessary.
The goal is not to protect everyone from responsibility. The goal is to identify the actual causes rather than settling for the easiest person to blame.
A simple example
Imagine a developer accidentally deletes a production resource.
In one organisation, the response is immediate punishment.
In another, the team investigates why the developer had permission to delete the resource, whether approval was required, whether the action was logged, and whether recovery was possible.
The second organisation can introduce safeguards that protect the environment even when someone makes an honest mistake.
The lesson: A good investigation does not stop when it finds the person involved. It continues until it understands why the failure was possible.
2. People Respond to the Incentives Around Them
People do not make decisions in isolation. They respond to the expectations and rewards of their environment.
Consider a company that measures developers primarily by the number of features delivered.
What behaviour might this encourage?
Developers may prioritise speed over testing, documentation, maintainability, or security. They are not necessarily careless. They may simply be optimising for the outcome their organisation rewards.
Now imagine a company that measures delivery speed alongside reliability, customer impact, security, and change failure rate.
The incentives are different, so the decisions may be different too.
This is why organisational behaviour matters.
If management demands rapid delivery but punishes every failure, teams may become reluctant to experiment or report problems. If leaders reward transparency and disciplined experimentation, teams may become more willing to identify risks early.
A practical question to ask
Instead of asking, “Why are people behaving this way?” also ask:
“What does the current system encourage people to do?”
This question is useful in management, engineering, sales, customer service, and leadership.
Sometimes the behaviour you dislike is a predictable response to the rules you created.
3. Processes Shape Outcomes
Imagine a restaurant where customers regularly receive incorrect orders.
Blaming individual employees may not solve the issue if the ordering system sends incomplete information to the kitchen.
The underlying problem could involve confusing menus, unclear order tickets, poor communication, or an overloaded workflow.
The same principle applies to software delivery.
A developer may repeatedly forget to update a configuration file because the deployment checklist is incomplete. A support engineer may escalate incidents late because ownership is unclear. A release manager may approve risky changes because there is no consistent risk-assessment process.
When outcomes depend entirely on individual memory, the process is fragile.
Good systems make the correct action easier, the risky action harder, and failures easier to detect.
That is the real value of standardisation, automation, documentation, and clear ownership.
PART 2: Applying the System Mindset in DevOps, Engineering, and Leadership
4. DevOps: Stop Blaming Engineers for Every Deployment Failure
Let’s use a familiar production scenario.
A team deploys a new application version. Within minutes, users start receiving HTTP 500 errors.
The team rolls back the release, restores service, and begins investigating.
A blame-driven response asks:
“Who deployed this version?”
A systems-driven response asks:
“What allowed this version to fail in production, and how can we detect or prevent the same failure next time?”
The investigation might reveal that:
The CI/CD pipeline did not run integration tests.
Configuration differences between staging and production were not detected.
The deployment had no automated health checks.
Monitoring alerted the team only after customers reported the issue.
The rollback procedure depended on manual steps.
Each finding suggests a practical improvement.
Build safeguards into the delivery process
A mature deployment pipeline can include:
Automated unit and integration tests.
Static analysis and security scanning.
Configuration validation.
Approval controls for high-risk changes.
Health checks after deployment.
Automated rollback or a documented recovery process.
Monitoring and alerting based on user impact.
The objective is not to eliminate every possible mistake. That is unrealistic.
The objective is to build a delivery system that reduces preventable failures, detects problems quickly, and limits their impact.
Example: Kubernetes deployment failures
Suppose a Kubernetes application repeatedly enters CrashLoopBackOff.
Instead of immediately blaming the developer, investigate the evidence:
kubectl get pods
kubectl describe pod <pod-name>
kubectl logs <pod-name>
kubectl logs <pod-name> --previous
kubectl get events --sort-by=.metadata.creationTimestampThese commands help reveal container errors, previous termination logs, scheduling events, and other useful clues.
The root cause might be a missing environment variable, an invalid configuration, a failed dependency, an incorrect command, or a resource constraint.
Once the cause is understood, improve the relevant part of the system. That might mean configuration validation, stronger health checks, better resource settings, or clearer deployment documentation.
A mature DevOps engineer does not just fix the broken deployment. They look for ways to prevent the next one. ☸️
5. Leadership: Build an Environment Where Problems Surface Early
One of the most expensive mistakes a leader can make is creating an environment where employees are afraid to report problems.
Imagine an engineer discovers a serious security issue shortly before a release.
If the organisation responds to bad news with humiliation, the engineer may hesitate to raise concerns next time. If the organisation treats the report as useful information and handles it responsibly, the risk is more likely to surface early.
This does not mean every action should be excused.
Leaders must distinguish between:
An honest mistake made despite reasonable precautions.
A process that repeatedly creates the same failure.
A lack of training or unclear expectations.
Deliberate misconduct or repeated disregard for agreed controls.
Each situation requires a different response.
A healthy engineering culture combines psychological safety with accountability. People should be able to report mistakes honestly, while teams still investigate what happened and take appropriate action.
What effective leaders do
They clarify responsibilities, set realistic expectations, listen to the people closest to the work, and improve processes when evidence shows that something is broken.
They also avoid assuming that one person’s behaviour explains every organisational problem.
A team that consistently misses deadlines may need better planning, fewer competing priorities, clearer dependencies, or more realistic estimates. Repeatedly telling people to “work harder” is not a substitute for fixing those constraints.
6. Communication: Many Conflicts Begin With Unclear Expectations
Not every problem is caused by a complicated process.
Sometimes, people simply have different assumptions.
A manager expects a task to be completed by Friday. The developer believes Friday is the date for the first review, not final delivery. Neither person clarifies the difference until Thursday afternoon.
Now both believe the other person has failed.
The system here includes how work is assigned, how deadlines are communicated, and how completion is defined.
Simple practices can prevent this kind of conflict:
Write down the expected outcome.
Confirm the deadline and its meaning.
Identify dependencies and blockers.
Agree on who owns the next action.
Share progress before a deadline becomes a crisis.
These habits are not bureaucratic overhead when used thoughtfully. They reduce ambiguity and prevent avoidable rework.
The same principle applies to technical documentation, incident handovers, project planning, and customer communication.
7. Measure the System, Not Just Individual Activity
A team can look busy while producing poor outcomes.
Developers may complete many tasks, attend endless meetings, and close numerous tickets without improving customer experience or product reliability.
This happens when the organisation measures activity instead of outcomes.
For engineering teams, useful measures might include:
Deployment frequency.
Lead time for changes.
Change failure rate.
Time to restore service.
Availability and latency.
Repeated incident patterns.
Customer-reported defects.
These metrics need context. For example, deployment frequency is not automatically a measure of quality, and a low incident count may reflect under-reporting rather than excellent reliability.
Metrics should help teams understand the system, identify bottlenecks, and make better decisions. They should not become weapons used to rank employees without understanding the work involved.
PART 3: A Practical Framework for Changing the Way You Think
8. The Five-Question Method
When a problem occurs, use these five questions to move beyond assumptions.
Question 1: What actually happened?
Start with observable facts.
Avoid beginning with statements such as “The developer was careless” or “The manager never communicates.”
Instead, describe the event: the deployment failed because the application could not load a required configuration value.
Facts give the investigation a solid starting point.
Question 2: What conditions made the problem possible?
Investigate the surrounding process, tools, permissions, workload, communication, and constraints.
Was there a missing validation step? Was ownership unclear? Did the system provide enough information to make the right decision?
Question 3: Why did existing safeguards not work?
A safeguard might be missing, poorly designed, incorrectly configured, or bypassed.
If the process already contains a control, understand why it failed before adding another one.
More process does not automatically mean better process. Sometimes the solution is to simplify an awkward workflow.
Question 4: What change would reduce the chance or impact of recurrence?
Choose an improvement that addresses the actual cause.
Examples include automated tests, safer permissions, clearer ownership, improved alerts, better documentation, or targeted training.
Question 5: How will we know the change worked?
Define a way to verify the improvement.
For example, after introducing automated configuration validation, track whether configuration-related deployment failures decrease.
Without verification, teams can end up implementing improvements that look impressive in a meeting but have little practical effect.
9. Common Mistakes to Avoid
Mistake 1: Assuming the system is always at fault
People make choices, and those choices matter. A systems perspective helps explain behaviour; it does not remove individual responsibility.
Mistake 2: Blaming individuals before collecting evidence
Early blame can narrow an investigation and discourage people from sharing useful information.
Mistake 3: Adding process without solving the problem
A new checklist will not fix every failure. If the underlying issue is poor automation, adding more manual steps may increase the risk of error.
Mistake 4: Measuring the wrong outcomes
Rewarding speed alone can undermine reliability. Rewarding low incident counts alone can discourage reporting.
Mistake 5: Treating every mistake as a learning opportunity without taking action
Learning is valuable only when it leads to meaningful changes where needed. Repeatedly documenting the same incident without addressing its causes is not continuous improvement.
10. Put the Mindset Into Practice This Week
You do not need to redesign an entire organisation to begin.
Choose one recurring problem in your team or daily work.
It could be missed deadlines, repeated configuration errors, unclear handovers, customer complaints, or unnecessary meetings.
Then:
Describe the problem using facts.
Look for patterns across multiple occurrences.
Speak with the people who experience the process directly.
Identify one change that addresses a likely contributing factor.
Measure whether the change improves the outcome.
Review what you learned and adjust where necessary.
Keep the experiment small enough to evaluate and meaningful enough to matter.
Over time, this approach helps replace repeated firefighting with continuous improvement.
Final Thoughts: Fix the Conditions That Keep Creating the Problem 🧠
Understanding the system is not about pretending that people never make mistakes.
It is about recognising that outcomes are shaped by more than individual decisions. Processes, incentives, tools, expectations, communication, and leadership all influence how people work.
When something goes wrong, blaming a person may provide a quick explanation. Understanding the conditions behind the failure can provide a lasting solution.
In DevOps, this means improving deployment pipelines instead of repeatedly blaming whoever released the code. In leadership, it means clarifying expectations and creating accountability without discouraging honest communication. In business, it means examining incentives and workflows rather than assuming every poor outcome comes from a lack of effort.
The next time the same problem appears for the third or fourth time, pause before asking who is responsible.
Ask what made the problem possible, why existing safeguards did not work, and what could change the outcome next time.
People matter. Accountability matters. But the system determines how consistently people can succeed.
The strongest professionals are not merely good at solving today’s problems. They learn to recognise patterns, improve the conditions around their work, and make tomorrow’s problems less likely. 🚀
Hashtags
#Leadership #SystemsThinking #DevOps #EngineeringCulture #ContinuousImprovement #ProblemSolving #Management #SoftwareEngineering #PlatformEngineering #SRE #Teamwork #CareerGrowth #EngineeringLeadership
Follow Me
If you enjoyed this article and would like more practical DevOps, Cloud, Kubernetes, AWS, Terraform, CI/CD, and Software Engineering content, feel free to connect with me on LinkedIn.
Arvind Verma is free today. But if you enjoyed this post, you can tell Arvind Verma that their writing is valuable by pledging a future subscription. You won't be charged unless they enable payments.
© 2026 Arvind Verma
548 Market Street PMB 72296, San Francisco, CA 94104