English | EN 
Throughout my career, I’ve seen implicit risks on numerous occasions. Many cross-functional teams struggle to identify and articulate risks; in many contexts, risk management should be a core activity. Understanding risk guides cross-functional teams on where to focus development and testing effort. Although teams and individuals often discuss risks, sometimes without realizing, they are inconsistent in identifying, documenting, reviewing, and following up on those risks. I call this unwanted implicit risk behavior.
In this 3-part series, I explore how implicit risks arise within Knowledge Communities, examine the impact on quality and test strategies, and offer practical approaches for teams to deliberately identify and manage risk.
I have had conversations in teams where I asked, “What you just said—that is a risk, right?” The recognition was there, yet people would simply move on, rarely pausing to examine the risk in depth. And even when risks were explicitly identified, teams seldom revisit them, missing valuable opportunities to act at the right moment. Relying solely on intuition in software development is not guaranteed to produce good results. This matters because managing risk explicitly is the most reliable way for teams to minimize potential problems. Moreover, recognizing that software systems become more complex over time, it is unacceptable to keep risks implicit.
During risk identification, I noticed colleagues had difficulty clearly defining and specifying risks. Often, only vague notes are recorded, which leads to lost context and unclear risks. Later, these notes become meaningless, resulting in missed opportunities to refine quality and test strategies.
To establish a shared understanding, I define implicit as something that is implied, hinted at, or understood indirectly, rather than stated explicitly. Implicit describes information that is inherent within a context, an unspoken and undocumented agreement. Common synonyms are implied, tacit, and unstated.
Teams often overlook, or inadequately address, risks due to implicitness. To better understand this behavior, it is important to look at the cognitive causes. In modern software development, like DevOps and Agile, knowledge is shared via so-called Knowledge Communities. Isolated individuals know less than the community. However, cognitive biases can lead team members to confuse their personal understanding with collective expertise, unjustly believing that the community’s knowledge is something they possess and have continuous access to.
This can result in significant blind spots, where risks remain hidden or unaddressed: individuals expect the community to address these. Among other things, teams should bolster cross-functional learning, avoid premature consensus and make fragile decisions.
The impact of risk implicitness on quality and test strategies
Due to risk implicitness, relevant and important risks may be overlooked or neglected, causing teams to be blindfolded during software development and testing. Since responsible quality and test strategies are steered by risk, these strategies suffer directly from risk implicitness.
Ineffective strategies can result in reduced product quality. For example, not knowing that a change has downstream impact is something you would rather know as soon as possible. Preferably before you write any code. To know that you need adequate impact and risk analysis, which leads to a higher chance of getting it right the first time. And more effective test strategies, such as integration and contract tests.
In greater detail, quality strategies are designed to implement appropriate measures for building quality in, provide information about quality and risks, and improve quality. The three fundamental pillars of quality engineering for people, processes, and products. Such quality measures include things like contract-based testing, architectural decision records, monitoring and alerting, workshops, workarounds, version control, and CI/CD. If you don’t look at the risks within the software delivery lifecycle, you might implement the wrong measures or even neglect them entirely.
Test strategies, which are a sub-strategy of the quality strategy, focus primarily on providing comprehensive information about the product being evaluated. These include quality measures such as session-based exploratory testing, performance and regression testing, test design techniques, and automated checks.
It should be noted that quality and test strategies do not assure quality. Rather, they foster quality awareness. Consequently, effective strategies are more likely to deliver the right quality at the right time.
As mentioned, both strategies rely on explicit risks to apply deliberate quality measures. If risks are implicit, teams become blindfolded, focus on the wrong areas, and miss essential actions for software delivery and product evaluation. This can result in missing unexpected edge cases, performance testing as an afterthought, and wasting test effort in less critical areas, while important aspects go untested.
In the next blog, I will look into the cognitive effects causing risk implicitness. I will tie all effects together with the Knowledge Community. In the third and last blog, I will discuss heuristics and quality measures teams can take to move from risk implicitness to risk explicitness.