The Day Technology Became the Office Scapegoat
If you lead a tech team, you know this imbalance. Hundreds of smooth publishing cycles are seen as normal, but one incident stands out. Reliability is expected, while failure gets extra attention.
If you lead a product or engineering team, you have experienced this.
The organization runs smoothly. The newsroom publishes quickly. Deadlines are met, distribution grows, and nothing crashes during busy times. The system works.
No one mentions it.
But when something goes wrong — a story in the wrong section, a field filled out wrong, a workflow skipped, or a feature misunderstood — the reaction is quick and certain: “The technology failed.”
You realize it is not just about one incident. It is about a pattern.
In many organizations, especially mission-driven ones, product and engineering teams exist in a strange place. When things work, they are considered normal. When something fails, it becomes evidence.
Reliability has a strange effect: it makes itself invisible. The more stable your platform is, the less people notice it. Hundreds of successful publishing cycles seem ordinary. Smooth teamwork across regions is expected. High-traffic events without downtime feel routine. But none of this is actually routine. It is the result of architecture, infrastructure, and careful design decisions made years ago to prevent problems people no longer remember.
Still, reliability is rarely celebrated. People just assume it.
People remember the one failure, not the thousands of problems that were prevented.
There is also a more uncomfortable layer. When users ignore defined workflows, resist tools, misuse permissions, or simply choose convenience over process, it is often easier to blame the system than to confront behavior. Technology becomes the safest target. It does not argue. It does not feel offended. It does not escalate politically.
A subtle but powerful story takes hold: “If the system were designed properly, this wouldn’t have happened.”
There is some truth to this. Good design makes things easier. Strong user experience prevents many mistakes. Permissions and guardrails are important. But expecting technology to fully make up for human behavior is both comforting and unrealistic.
No road system can stop all reckless driving. No email client can prevent every message from going to the wrong person. No CMS can remove all judgment errors or rule-breaking. Technology can guide, but it cannot replace accountability.
If we do not clearly separate these issues, everything gets called a “tech” problem. When that happens, accountability becomes unclear, and the product team ends up bearing all the operational burden.
One simple change can shift the conversation: name the categories. When something goes wrong, separate platform defects from training gaps and from governance violations. Engineering owns defects. Knowledge gaps need training and support. Process violations need managers to step in. These distinctions are not about blame — they are about structure. Without them, stories become the main way people judge what happened.
There is another truth product leaders need to face. Being underappreciated is not always about unfairness. Sometimes it happens because your work isn’t being translated.
If you talk about your work in terms of tickets completed, refactoring, or infrastructure, but leadership cares about mission impact, audience reach, editorial speed, and risk, you are speaking different languages. Stability seems basic unless you show its impact. Saying “We optimized workflows” sounds technical, but “We reduced customer preparation time by nearly twenty percent” sounds strategic.
If you do not link the architecture to the mission, people stop noticing the architecture.
Product leadership also has a political side that many people do not like to talk about. In complex organizations, part of your job is to help people understand what causes problems. You need to define what counts as a system failure and what is a behavior issue. Make trade-offs clear before something goes wrong. Show the value of risk reduction, even if no one asked for it. If you only show up after things go wrong, people will link you to failures. But if you regularly explain how the platform supports the organization’s goals, you start to be seen as a strategic partner, not just a service provider.
Of course, not every organization just misunderstands technology. In some places, technology is always seen as a cost rather than as something that adds value. In these cases, better reporting will not change how people see it. The issue is not about being seen — it is about how people think.
This leads to a tougher, more personal question. Are you in a place that can change how it sees product work, or will it always treat infrastructure as something in the background?
This question matters because cultural debt builds up quietly. If your team keeps getting blamed for things they cannot control, morale drops long before you see it in the numbers. You can fix technical debt with time and money, but cultural debt grows quietly and is harder to fix.
Product leadership is not just about launching features or keeping systems stable. It is also about making sure everyone is clear on what the system does, what people are responsible for, and where accountability lies. If we do not set that clarity ourselves, someone else will do it for us.
And their version of clarity may not be generous.