Invisible Yet Inevitable: The Unseen Forces That Shape Quality
Words from the editor
Quality is often seen, celebrated, or criticized through visible outcomes - green pipelines, pass percentages, defect counts, or user ratings. But the forces that truly shape quality are rarely those that can be captured on dashboards or status reports. They lie beneath the surface, quietly influencing every decision, every compromise, and every standard we claim to uphold.
This edition of Quality Quest lifts the veil on these silent drivers, the invisible yet inevitable forces that steer the ship of software quality, whether we acknowledge them or not.
We’ve become obsessed with numbers such as automation coverage, KPIs, OKRs, and the illusion of control they bring. But how often do we pause to examine the culture we operate in? The biases embedded in our tooling choices? The expectations that never made it into documentation but silently guide decisions? The pressure to deliver fast that subtly redefines what "done" means?
Quality, in its truest sense, is not just the absence of bugs. It's the presence of thoughtful intent, ethical responsibility, user empathy, and resilient systems. And none of these can be achieved by testing alone. They demand awareness, courage, and most importantly, conscious culture shaping.
In our lead article, “Culture Eats Quality for Breakfast: And What Testers Can Do About It,” we explore how organizational culture be it transparent or toxic, inclusive or indifferent seeps into every aspect of quality. From the way feedback is received, to how risk is communicated, and even which bugs get fixed first, culture becomes a silent architect of outcomes. This piece doesn’t just stop at identifying the problem; it offers tangible ways testers can become culture shapers, not just culture followers.
Our second article, “The Shadow Metrics: What You're Not Measuring Is Still Driving Your Product,” delves into the dangers of relying only on what’s easy to measure. While teams obsess over test coverage and story points, they may be blind to user frustration, hidden tech debt, or poor handoffs across roles. This article challenges the idea that metrics are neutral and exposes how they often reflect more about management priorities than product reality. It encourages testers and quality leaders to start surfacing the right unknowns, not just the known knowns.
The goal of this edition isn’t to add more noise to the quality debate. It’s to nudge you to pause, to reflect, and to notice what you’ve been conditioned to ignore.
Because in software, just like in life, it’s rarely the loudest forces that shape the outcome. It’s the quiet ones. The ones hiding in our assumptions, our habits, our unspoken rules.
Quality is everyone’s responsibility, but its shape is molded by what we choose to see—and what we don’t.
Let this edition help you see more.
Culture Eats Quality for Breakfast: And What Testers Can Do About It by Brijesh DEB
It begins quietly. A casual joke in a team meeting about testers being too picky. A release pushed to meet a deadline, even though a few critical bugs still linger. A manager urging the team to "trust the process" while quietly cutting corners to satisfy a stakeholder. Nothing explodes. Nothing falls apart immediately. But over time, these small ripples grow into a cultural undercurrent that begins to shape the quality of the product in ways no test case ever could.
Welcome to the quiet battlefield of culture,the most underestimated, yet most influential, force behind software quality.
The Myth of Process Over Culture
Many organizations believe that if they have the right processes in place, quality will naturally follow. Automated tests, CI/CD pipelines, bug triage boards, testing gates,all meticulously crafted to simulate control. But here's the inconvenient truth: culture can override process at any point.
A culture that values speed over stability will find ways around even the most robust quality gates. A culture that rewards heroics over sustainability will burn out testers and developers alike. A culture where testers are seen as the "last line of defense" rather than embedded partners will relegate quality to the end of the pipeline.
Testers know this all too well. You can build the best test coverage in the world, but if a release manager decides to ship with known critical bugs because "we've made a promise," your quality efforts are overruled by culture, not capability.
The Cultural Iceberg
Culture is often likened to an iceberg,what's visible (rituals, dress codes, company slogans) is only a small part. The real mass lies beneath: assumptions, beliefs, and unspoken rules. In the context of software development, this might look like:
These assumptions are rarely discussed openly, but they manifest in day to-day decisions,which bugs get fixed, which issues get postponed, who gets blamed when something breaks.
Let’s take a real world example. At one fintech startup, the leadership team regularly celebrated rapid deployments and feature launches. The testing team was consistently under pressure to "keep up," and exploratory testing was often skipped to meet delivery targets. Initially, this looked like success,velocity metrics were impressive, and customers received updates frequently. But within a few months, customer complaints skyrocketed due to regressions. The testing team flagged these risks early on, but their concerns were brushed aside. The leadership culture had inadvertently prioritized visibility over stability, resulting in a quality debt that took months to recover from.
Contrast this with another organization,a healthcare product company,where quality was embedded into team rituals. Every planning session began with a review of user pain points, not just velocity metrics. Testers were encouraged to challenge requirements before code was written. Releases were not rushed, even under pressure, because leadership had made it clear: patient trust was non negotiable. Unsurprisingly, customer satisfaction remained consistently high, and production incidents were rare. Culture, in both cases, silently shaped the outcomes.
Let’s take a real world example. At one fintech startup, the leadership team regularly celebrated rapid deployments and feature launches. The testing team was consistently under pressure to "keep up," and exploratory testing was often skipped to meet delivery targets. Initially, this looked like success,velocity metrics were impressive, and customers received updates frequently. But within a few months, customer complaints skyrocketed due to regressions. The testing team flagged these risks early on, but their concerns were brushed aside. The leadership culture had inadvertently prioritized visibility over stability, resulting in a quality debt that took months to recover from.
Contrast this with another organization,a healthcare product company,where quality was embedded into team rituals. Every planning session began with a review of user pain points, not just velocity metrics. Testers were encouraged to challenge requirements before code was written. Releases were not rushed, even under pressure, because leadership had made it clear: patient trust was non negotiable. Unsurprisingly, customer satisfaction remained consistently high, and production incidents were rare. Culture, in both cases, silently shaped the outcomes.
Culture and Quality: An Inseparable Pair
Let’s put it plainly: you cannot separate culture from quality. If your culture tolerates mediocrity, your product will reflect it. If your culture embraces psychological safety, collaboration, and learning, your product will too.
Testers often find themselves trying to raise red flags in environments where those flags are seen as annoyances rather than assets. It’s not that the bugs aren’t valid,it’s that the culture isn’t receptive. The issue is not in the signal, but in the willingness to listen.
This is why so many testing transformations fail,not because the testing techniques are weak, but because they’re operating in a culture that resists transparency, accountability, and change. Culture determines whether red flags are acted upon or buried under layers of indifference.
A good culture doesn’t eliminate bugs,it creates space to learn from them. It encourages postmortems, not witch hunts. It prioritizes the why behind the what. That’s the difference between a reactive team and a resilient one.
So What Can Testers Do?
Here’s where the story turns from grim to empowering. Testers, even without formal authority, are in a unique position to influence culture. Because quality is their lens, they often see the ripple effects of cultural decisions before others do. Here are some actions testers can take:
1. Be Culture Sensors
Testers often act as the early warning systems in a product development process. Don’t ignore those subtle signs,the bug reports that are dismissed too quickly, the mounting pressure to skip exploratory testing, the tendency to avoid tough conversations. Document them. Share patterns. Not as complaints, but as data points that reveal how culture is impacting quality.
Being a culture sensor also means observing beyond the defect count. Are developers defensive during bug triage? Are retrospectives open forums or passive check ins? Are quality goals ever mentioned in OKRs? These qualitative signals reveal how a team truly views quality and testing.
2. Shift from Gatekeepers to Guides
Stop positioning yourself as the final barrier before release. Instead, embed early. Pair with developers. Offer feedback when stories are still being shaped. Help teams understand that quality isn't a phase,it's a principle. When testers act as collaborators, culture starts to shift from reactive to proactive.
One senior tester shared how she began attending grooming sessions,not just to estimate testing effort, but to ask value driven questions. "Who is this feature for? What happens if this fails?" Over time, her team started considering testability and edge cases much earlier in the process. The result? Fewer surprises, and a noticeable drop in escaped defects.
3. Influence Upwards
Don't just talk to peers. Talk to product owners, engineering leads, even business stakeholders. But don’t go in with a list of bugs. Go in with a story. Show how cultural decisions are causing friction. Share how missed testing time led to user complaints. Connect quality issues with business impact. Culture is shaped by those who hold the vision,make sure they’re seeing clearly.
Instead of saying, "we didn't have time to test this thoroughly," reframe it: "We released without validating this behavior, and now 20% of users are affected. What could we have done differently to avoid this?" Turn pain points into learning moments.
4. Celebrate the Good
Culture change isn't just about pointing out what's broken. It's also about amplifying what's working. Did a dev take time to pair with you on a complex test case? Share that in the team retro. Did a PM delay a release to fix a serious bug? Acknowledge that in your demo. Culture is reinforced by what gets celebrated.
Positive reinforcement builds trust. It also sets examples for others to follow. When quality minded behavior is recognized, it spreads. This doesn’t require big gestures,just consistent appreciation and visibility.
Celebrate moments when someone asks a hard question. Highlight stories where a delay prevented a disaster. Champion thoughtful dissent. These micro moments compound into culture shifts.
5. Language Matters
Words carry weight. If testers constantly talk about "blocking" releases or "owning" quality, it creates a wall. Shift the language to "enabling confidence," "partnering for resilience," or "surfacing risk." These aren't just buzzwords,they reshape how people perceive your role.
Consider the difference between saying "We found 15 bugs" versus "We helped the team identify 15 potential risks to user experience." One sounds confrontational. The other sounds collaborative.
Language not only reflects culture,it molds it. Words are tools. Use them with precision.
6. Raise the Bar on Yourself
If you want to influence culture, lead by example. Level up your skills. Broaden your understanding of product strategy. Show curiosity, not just criticism. When others see testers as holistic thinkers, not just bug hunters, respect follows,and so does cultural influence.
Read code. Understand the CI/CD pipeline. Attend user interviews. Learn about analytics. The more context you bring, the more valuable your input becomes. And that raises not just your credibility, but the stature of testing itself.
Offer to mentor junior developers in testing techniques. Volunteer to lead brown bag sessions. Invest in your craft, and others will invest their trust in you.
The Role of Psychological Safety
One of the deepest cultural elements impacting quality is psychological safety. When teams fear judgment, they hide mistakes. When testers fear pushback, they under report risks. But when people feel safe to speak up, question decisions, and admit uncertainty, quality improves.
In psychologically safe environments, testers don’t fear sounding negative. They ask better questions. They explore uncomfortable possibilities. They challenge assumptions without being labeled difficult. And this leads to stronger, more resilient products.
Creating safety isn’t about being soft. It’s about being open. Model vulnerability. Say "I don't know" when you need to. Ask open questions. Invite feedback. Offer yours generously. Safety starts with one person daring to go first.
Take the example of a mid size SaaS company where a senior developer openly admitted in a sprint review that a production bug was due to a missed edge case he hadn’t thought of. Instead of reprimanding him, the team lead thanked him for his honesty, and the team used it as a learning moment to improve their code review checklist. This simple act reinforced a culture where learning trumped blame.
As Google’s Project Aristotle famously found, psychological safety was the most critical factor in determining high performing teams. When people feel safe to speak the truth,even if it’s uncomfortable,quality isn’t just improved, it becomes embedded in every conversation.
Also remember that safety doesn’t mean agreement,it means permission to disagree. Cultures that tolerate respectful dissent are more likely to build software that survives real world chaos.
When Culture Resists
Of course, not all cultural resistance can be overcome. Sometimes, testers work in places where quality is truly seen as an afterthought. In those cases, testers have two options: keep nudging or make a move. Neither is easy, but both are valid.
If you choose to stay, build alliances. Find like minded developers or designers. Start small experiments that show better ways of working. Change rarely happens through revolution,it often starts with a quiet refusal to accept the status quo.
If you choose to leave, do so with clarity and courage. Some cultures are not worth salvaging. But don’t take the scars with you. Carry the lessons. Use them to spot red flags earlier in your next role.
Know that leaving isn’t failure. It’s feedback,evidence that your values and the organization’s aren’t aligned. Sometimes, walking away is the strongest message you can send about the value of quality.
If you're interviewing for a new role, ask culture specific questions: "Can you share how your team handles missed deadlines?" or "What happens when someone raises a red flag close to release?" The answers to those questions reveal more than any company slogan ever will.
To make it easier, here’s a mini checklist you can use to assess cultural fit:
Use these questions not only in interviews but during onboarding, team meetings, and retrospectives. Culture is always talking,you just need to know what to listen for.
Culture Is What You Make It
Culture isn’t a slide deck. It’s not a mission statement. It’s what people do when no one is watching. And that makes it both powerful and changeable.
Testers might not own the org chart, but they do hold a mirror. A mirror that reflects how decisions, assumptions, and behaviors are shaping the user experience.
And sometimes, holding up that mirror,consistently, clearly, and constructively,is exactly what a culture needs to start changing.
So yes, culture eats quality for breakfast. But only if we let it.
Let’s not.
Recommended by LinkedIn
The Shadow Metrics: What You're Not Measuring Is Still Driving Your Product by Brijesh DEB
We love our numbers. From test coverage percentages to velocity charts, defect leakage rates to cycle times, metrics have become the currency of modern software development. Managers quote them in reviews. Dashboards glow with them. Teams chase them. But here’s the uncomfortable truth: the most important drivers of software quality often aren’t visible on any dashboard. They exist in the shadows, unmeasured, unspoken, yet deeply influential.
This article is an exploration of those invisible metrics, the cultural and contextual signals that shape your product whether you track them or not. Because what we choose to measure reveals what we value. And what we ignore? That’s where the surprises, and the risks, often hide.
The Problem with Popular Metrics
Let’s start with the obvious ones: test coverage, bug counts, automation pass rates, story points completed. These are helpful indicators, but only in context. On their own, they create illusions of control.
A team might show 95 percent test coverage, but if the tests are brittle or shallow, coverage becomes a vanity number. Defect counts may go down because testers are under pressure to reduce noise, not because the product is improving. Story points might be closing faster, but only because the team is slicing stories smaller to game velocity.
We cling to these numbers because they’re easy to present and compare. But ease of measurement is not the same as meaningful insight. That’s where shadow metrics come in.
What Are Shadow Metrics?
Shadow metrics are the behaviors, signals, and decisions that affect product quality but aren’t formally tracked. They include:
These don’t show up on dashboards, but they shape your product’s fate. Just because something is hard to measure doesn’t mean it’s unimportant. In fact, it’s often the opposite.
When Metrics Become Manipulated
Here’s the catch: once a metric becomes a target, it loses its value. This idea, known as Goodhart’s Law, explains why so many testing metrics eventually backfire. Teams start optimizing for the number rather than the outcome. They write more automated tests to meet a quota, not because those tests add confidence. They avoid reporting certain bugs because fewer bugs look better on paper.
In one enterprise project, a test team was rewarded for reducing open bugs. Within months, bugs stopped being logged unless absolutely critical. Developers were asked to fix things quietly. The dashboard looked great. The users, not so much.
In another case at a telecom product company, the leadership began using automation pass percentage as a measure of quality. Testers responded by writing hundreds of simplistic tests to boost pass rates. The real risks,complex integration flows,remained untested. When a critical failure hit production, it took weeks to uncover the root cause. The metrics looked green, but the quality was red.
A retail startup faced a similar issue when they linked quarterly bonuses to defect density. Teams responded by reclassifying critical bugs as minor and delaying ticket creation until after release. Their numbers looked fantastic. Their customer churn told a different story.
Metrics should guide inquiry, not replace it. If you aren’t asking what a number means, you’re just dressing up ignorance in data.
The Bias of What's Measured
Metrics often reflect managerial preferences, not product reality. We measure what aligns with our objectives, not what customers experience. We count test cases, not cognitive load. We track defects, not deferred decisions. This creates blind spots.
Testing is particularly vulnerable here. The depth of exploration, the thoughtfulness of risk analysis, the human insight behind test scenarios,none of these fit neatly into a spreadsheet. But they’re what separate shallow testing from meaningful quality assessment.
A startup team once boasted 100 percent test case execution. But testers privately admitted they were re running outdated scripts that no longer reflected the system’s true complexity. Test execution was high; risk coverage was low.
When leaders say, “We want to be data driven,” they rarely ask, “What data are we blind to?” That question is where real quality conversations begin.
Shadow Metrics in Action: A Tale of Two Teams
Let’s contrast two teams.
Team Alpha is metrics rich. They track everything: test cases executed, bugs closed per sprint, automation coverage, test run time, and velocity per engineer. Their dashboard is the pride of leadership. However, testing happens at the end of the sprint. Testers aren’t part of backlog grooming. When problems arise, the finger pointing begins. Despite the wealth of metrics, quality issues regularly make it to production.
Team Beta has fewer dashboards. Instead, they focus on questions. They involve testers early. They conduct risk storming sessions. Their retrospectives explore not only what failed, but why those failures weren’t foreseen. They document decisions, assumptions, and exceptions. Their bug counts aren’t spectacularly low, but their customer complaints are. Team Beta invests in invisible practices that create visible confidence.
The difference? Team Alpha manages to the metric. Team Beta manages to the mission.
Surfacing the Invisible
So how do we bring shadow metrics into the light without turning them into another dashboard?
1. Tell Stories, Not Just Statistics
Encourage testers to pair metrics with context. Don’t just report that 85 percent of tests passed. Share what those tests actually validated and what they didn’t. Use narrative reports in retrospectives. Offer examples of risks found during exploratory testing that weren’t captured in automation.
One team began including a "Quality Digest" in their sprint demo. Instead of numbers, they shared two things they learned, one thing they missed, and one question they still had. It became a cultural artifact that changed how everyone talked about risk.
2. Measure Conversations
Track how often quality is part of the planning conversation. Are testers asking questions during story grooming? Are risks discussed in stand ups? This may not be numerically precise, but even qualitative tracking,such as "we raised four non obvious questions this sprint",signals a culture of awareness.
Some teams keep a lightweight log of "quality questions",the hard questions raised during grooming, demos, or release reviews. Over time, the frequency and depth of these questions become a shadow metric in themselves.
3. Use Shadow Reviews
Every few sprints, conduct a "shadow review" where testers reflect on:
This reflection reveals not only blind spots but cultural patterns. Patterns of silence, patterns of pressure, patterns of compromise.
4. Qualitative Health Checks
Consider introducing a periodic quality health check survey within the team. Ask things like:
These questions prompt honesty, not vanity.
You could use a Likert scale or open text reflections. The goal isn’t to quantify feeling but to surface it.
5. Visualize the Intangible
Use simple visual tools to represent intangibles. For example, a "risk radar" where teams plot features based on uncertainty and impact. Or a "confidence heatmap" showing where testing confidence is high or low. These visuals prompt richer discussion than numeric dashboards ever could.
6. Practice Pre Mortems
Instead of waiting for a retrospective, conduct a pre mortem. Ask the team: "Imagine it’s a month after release and the product has failed. What went wrong?" This exercise unlocks concerns that might otherwise remain hidden.
Pre mortems reveal hidden fears. And fears unspoken can become failures in production.
For Leaders: What You Can Do
If you're in a leadership role, your influence is massive. Here’s how to lead with awareness of shadow metrics:
At one enterprise company, a senior leader began every review meeting by asking, "What do we wish we had more time to test?" It flipped the dynamic from defensiveness to discovery.
Another organization introduced a "cultural KPI" alongside delivery metrics: the number of red flags raised before release. Not to penalize teams, but to normalize early escalation. It became a badge of diligence, not a sign of failure.
Culture is shaped by what gets attention. If you only pay attention to clean metrics, you’ll only see a cleaned up version of reality.
Shadow Metrics: Startups vs Enterprises
Shadow metrics look different depending on the environment. In startups, agility and speed often dominate the culture. Shadow metrics here are usually tied to urgency,unspoken expectations to deliver faster, cut corners, and push through despite quality gaps. Decisions are made in hallway conversations, Slack threads, or last minute calls. Bugs may be tolerated, rationalized with "we'll fix it in the next sprint."
In one early stage startup, the CEO personally reviewed every demo. While this created visibility, it also caused engineers to focus on polishing presentation flows while leaving back end regression testing half done. No one tracked this trade off,it was never spoken, never measured, but it silently eroded quality.
Contrast this with enterprises. Large organizations are often obsessed with formal governance, maturity models, and compliance. Here, shadow metrics hide in bureaucracy: how many test scenarios are signed off to meet audit requirements but never run effectively? How often are reports tailored to avoid uncomfortable scrutiny rather than inform decision making?
In one multinational bank, testing dashboards reported zero high priority defects for three months. Internally, testers joked about the "status green zone",a stretch where bugs were never logged as 'high' because of how quarterly reviews were structured. Risk was managed not in code, but in categorization.
In enterprises, shadow metrics are often about silence. In startups, they’re about speed. In both cases, the absence of explicit conversation drives implicit compromise.
Stakeholder Perspectives: Everyone Has a Blind Spot
Shadow metrics aren’t just a testing concern. Different stakeholders experience them differently,and influence them, knowingly or not.
Product Managers often optimize for delivery velocity. Shadow metrics arise when PMs unknowingly deprioritize technical debt or testing scope to meet business goals. Asking PMs: "What risks are we accepting by skipping this scenario?" opens up space for more informed trade offs.
Developers may feel pressure to finish features without enough time to test deeply. Shadow metrics here show up as invisible bugs, band aid fixes, and knowledge silos. Encouraging devs to log "known unknowns" or areas they feel least confident about during handoff can bring hidden risks into the open.
Executives want clarity and confidence. But over reliance on aggregated charts often filters out the nuance. Executives should ask: "What don’t I see in this report?" or "What’s being softened before it reaches me?"
Customers, though not internal stakeholders, experience the consequences of shadow metrics most directly. Their feedback, complaints, and usage patterns often reveal what was missed internally. Listening to support teams is a valuable way to triangulate hidden gaps in coverage or risk.
Shadow metrics connect everyone. They're not owned by testing,they're shaped by culture.
A New Relationship with Metrics
Metrics are not the enemy. They are necessary. But they should be signals, not scorecards. They should provoke curiosity, not competition. And they should never become substitutes for the deeper, human centered work of testing.
Shadow metrics remind us that software quality isn’t a number. It’s a narrative. A story of how decisions are made, how risks are handled, and how truth is surfaced.
And those stories don’t live in dashboards. They live in conversations, trade offs, and the courage to look beyond what’s easy to measure.
So ask yourself: What are we not seeing? What are we not saying? What are we pretending to control with metrics we barely understand?
Because what you don’t measure can, and often does, drive everything that matters.
And if you want better software, you might start by asking better questions.